Characteristics and categorization of services in CLOUBI: A CLOud-based UBIquitous architecture

1. Introduction

In 1991, Mark Weiser [77] presented a primary definition of ubiquitous computing or pervasive computing which is described as a sort of distributed computing. This has gained much attention in applications such as domestic, medical, commercial, agricultural, and industrial scopes, as well as crisis management and others [21,22,26]. Although there are various interpretations of this kind of computing, it should be noted that ubiquitous computing is not solely the control of the peripheral environment; rather, a more abroad concept is suggested. Notably, the possibility of any kind of computing in the peripheral environment is proposed. For example, consider the control of a lamp and the potentiality of its being turned on and off by the entrance of a person to a building, which is possible by an ordinary sensor. In this scenario, the concept of ubiquitous computing bares no relation. However, after this person enters the building, if he is identified, his profile can be examined and lighting adjusted based on personal preferences (service based on implicit demand); it can then be suggested that a ubiquitous computing-based environment is in play. This simple example demonstrates the scenario of a single-domain ubiquitous environment, by which it can be inferred that processing in the environment is the main basis of ubiquitous computing.

Based on its functional scope, ubiquitous computing is divided into single-domain and multi-domain ubiquitous computing [14,16]. Single-domain indicates that changes in the environment are only applied based on the local knowledge of the environment (user behavior and characteristics in a local situation) and not on previous information or new data derived from other domains. In contrast, multi-domain ubiquitous computing refers to the exploitation of several ubiquitous contexts which interact with each other; the information derived from each of these is applicable in other domains. To illustrate a multi-domain system, assume that the user in the previous example intends to leave his office (domain 1) and return home (domain 2). On the way, he visits a medical clinic because of a headache (domain 3) and the physician prescribes some medicine based on the examination and the user’s physical condition at work.

The user then visits a drugstore (domain 4), picks up the medicine, and eventually returns home. At this point, after entering his home, he is identified and his profile is examined. It is then that the system recognizes that the user is under the weather. An examination of the type of illness follows which involves referring to the user’s profile where notes from the earlier doctor visit are available. Accordingly, the lighting at home is adjusted to suit the user’s medical condition. In addition, the system performs other tasks, including alerting the user to take his medicine at certain hours (based on access to drugstore data), warning the user to avoid foods that will aggravate his medical condition or requesting sick leave from the user’s employer for the next day. Moreover, the system may prepare a list of do’s and don’ts based on the user’s request and display this on his mobile phone (service based on explicit demand).

Based on the type of processing core, ubiquitous computing systems are divided into pure and hybrid computing [24,72]. Pure computing is solely based on resources and services located in ubiquitous environments. In contrast, hybrid systems are those in which ubiquitous computing is integrated with another type of powerful computing method [28], mostly cloud computing [9,31], so that cloud resources and services can also be utilized along with ubiquitous resources and services. The concept of hybrid cloud-based systems has been utilized in other types of application domains, such as cyber-physical systems [49] and manufacturing systems [79]. The main reason for introducing hybrid systems is to explain the deficiencies and problems of pure systems. These are as follows:

– Limitation of being multi-domain [13,35]

Because of being multi-domain, only a few limited and particular domains can be connected through the ubiquitous system. This results in the incapability of providing special resources and services to users, due to issues such as the limited resources of each domain, the need to access remote resources and services, or even the lack of connection among processing units causing non-recognition of user identities in different domains and the dispersion of data.

– Lack of uniform namespace in the whole ubiquitous system [13,84]

This limitation, which originates from the pure ubiquitous system’s being multi-domain, results in users of various disconnected domains owning different identification data. Moreover, the user profiles of each independent domain (including their behavior and action details in different domains) encompass a series of data which are inconsistent with the data of other domains. This dispersion of data may pose problems with providing users with services that are based on the latest user behavioral status. This may also affect some further applications, such as ubiquitous recommender systems.

– Incapability of users’ ubiquitous mobility [84]

Considering previous issues, the replacement of users according to the expectations of ubiquitous computing is not possible and user mobility remains a function of the number of related ubiquitous domains.

– Restrictions of resources and lack of scalability of a pure ubiquitous system [39,88]

Available devices and equipment in the ubiquitous environment suffer from numerous deficiencies in computation resources, storage, energy and so on. Furthermore, due to similar limitations, the processing core of the ubiquitous system is not capable of providing proper answers to a large volume of requests in the ubiquitous environment. All these limitations affect the scalability of the ubiquitous system, apart from the fact that new devices and equipment of the environment will constantly increase in number.

– Intensive applications [3]

In a ubiquitous environment, there are particular applications with compute-intensive, data-intensive, and energy-intensive features, or a combination of these (resource-intensive). Due to the limitations of resources and a lack of scalability of the pure systems’ processing unit, application functions do not perform properly and their performance with current systems seems to happen unexpectedly. An example in compute-intensive applications is crisis management ubiquitous systems, which [3] provide a cloud-based solution to deal with the limitations of ubiquitous computation resources. An example of data-intensive applications is ubiquitous recommender systems, which [34] introduce a cloud-based approach for the limitations of ubiquitous data resources.

According to these limitation issues, access to an ideal ubiquitous computing system is not possible individually via access to local resources and services. To eliminate the deficiencies of pure ubiquitous systems, one should consider regulation of hybrid systems for offloading some of the requests to powerful computing, such as cloud computing. In this regard, a number of hybrid architectures have been introduced which attempt to solve some of these problems through the capabilities of computational clouds and the offloading technique [8, 14, 16, 18, 19, and 21]. Despite their advantages, the type of services offered by hybrid architectures is not clearly defined. Moreover, none provide categorization to identify all of the offered services to existing requests in a ubiquitous environment (similar to the categorization of services in cloud computing). Although there are other introduced types of hybrid computing, such as mobile cloud computing, whose features and goals are, to some extent, similar to those of ubiquitous cloud computing, the focus of the present study is on ubiquitous cloud computing. Section 4 further explains the reason for this.

Security concerns are important in all computational environments and ubiquitous and cloud computing are no exception. Security issues in ubiquitous computing can include privacy, authentication, access control, secure boot-strapping, confidentiality, and reliability [75]. On the other hand, security concerns in cloud computing may be authorization, identification, authentication, integrity, confidentiality, availability, privacy, and non-repudiation [74]. In both computing environments, designing an architecture must take into account security issues. Particularly with hybrid architectures, security is more critical due to the interaction of cloud and ubiquitous computing with each other.

The main purpose of the present paper is to provide a complete review of services features and their categorization in ubiquitous cloud computing. Hence, there is scrutiny on pure ubiquitous computing features, in particular the input request dimension, specifying the needs of an ideal ubiquitous computing system (requiring a hybrid approach due to the shortages of pure ubiquitous computing), introducing a hybrid ubiquitous architecture based on system needs, and, finally, classifying the architecture services. In addition, the most important security concerns needed in ubiquitous cloud computing architectures are discussed.

Other sections of the current paper are as follows: The second section explores claims by other researchers about hybrid architectures and examines their services and categorization in various ubiquitous environments. In addition, it surveys the security issues in both ubiquitous and cloud environments. Section 3 provides a categorization of different types of ubiquitous system inputs and addresses the nature of requests in different ubiquitous applications. The fourth section explains the reason for focusing on ubiquitous cloud computing. Section 5 reports the expected features of the services and also the security requirements of ubiquitous cloud computing. While discussing the general features of an ideal architecture for ubiquitous cloud computing and examining its interactions, Section 6 introduces a comprehensive categorization of the different types of available services. In order to demonstrate the necessity of applying hybrid systems rather than pure systems, the sixth section also examines the applicability of these categorized services in different ubiquitous environments. At the end, Section 7 presents the conclusion and discussion.

2. Literature review

Various research works have been conducted in the context of hybrid ubiquitous cloud architectures. In [81,82], an ontology-based pervasive middleware is introduced which receives user commands as pervasive. After converting the commands into a suitable format, known as OntoIAS (Ontology-based Information Agent Shell), this middleware sends them to a cloud for processing. The problems faced are the limited range of applications, lack of attention to the available services on the pervasive layer, and the provision of all services by the cloud layer. In [35], an architecture named PlanetCloud is introduced, which is able to increase cloud availability and service pervasiveness by using multiple resource servers as well as a resource search system. The architecture functionality is based on social networks. However, architecture details, types of provided services, and other expected features are not explained.

In [13], due to the limitations of mobile devices as well as network shortcomings, an architecture is presented based on location-based services. By dividing tasks and utilizing outsourcing techniques, these services process requests that require intensive resources within the cloud and those which are lightweight on mobile devices. In this architecture, all communications between users and the cloud are end-to-end and through internet. Hence, when the network is disconnected, users have limited or no access to their intended services, which affects real-time applications. Also, in the description of this architecture, there is no discussion on how to control the environment and provide local services.

In [84], the UbiCloud hybrid architecture is presented. UbiCloud is for intensive applications, such as image processing, data mining, multi-media applications, etc., in which all services are assumed identical in terms of diversity and access type. In this architecture, regardless of failing to introduce architectural subsystems, there was also no discussion on the details of ubiquitous and cloud structures. In addition, since context information is not collected, users cannot influence their surrounding environment nor control it.

In [39], a platform named EUPaaS (Elastic Ubiquitous Platform as a Service) is proposed. Its main purpose is to provide real-time data services to a wide range of ubiquitous applications by utilizing the ability of real-time data processing in the cloud. Although this platform can be used in diverse applications, including the medical field, it must first be noted that its details and subsystems functionality has not yet been well defined. Secondly, the EUPaaS layer communications with the ubiquitous and cloud structures are not clear.

In [3], a four-layer hybrid architecture is presented, in which two inner layers process requests and two outer layers collect and send requests to these inner layers. Although the use of outer layers leads to the consideration of ubiquitous computing in the architecture’s design, several challenges are encountered. Firstly, the architecture communication model creates a high overhead. Secondly, the requests that need intensive data have not been considered. Thirdly, there is a strong relation between comprehensive context-awareness and low-power equipment. As a result, with the development of the context, performance may be impaired due to the resource limitations of this equipment.

Finally, [20] addresses ambient aided living systems and introduces a context-aware architecture named as COCAMAAL, which is based on five different clouds. In addition to managing sensor data and extracting context information, the architecture can monitor user activities and search for and provide appropriate situational services for them. As in most hybrid architectures, all processes are performed on clouds. Also, there is a local station for each user domain that is only responsible for collecting sensor data and sending them to the cloud. These stations play no role in providing local services to users since this would only increase the costs of deployment. Table 1 presents a brief summary of most important characteristics and limitations of above-mentioned architectures.

Various research work has been performed in order to investigate and categorize the ubiquitous services. Dissertation [59] examines a variety of different applications, user interfaces, functional frameworks, and also a number of ubiquitous architectures, such as Active Spaces, Microsoft Easy Living, CMU’s Aura, and Washington’s One World; required services for the execution of some of these cases are also suggested. Nevertheless, [59] does not propose a comprehensive categorization of services which can be utilized in all of the above-mentioned cases.

Based on employing ubiquitous services in physical hypermedia functions, [11] introduces two kinds of significant services: HInformation and Browse. The former, which includes characteristics of things and links, supports common semi-web links, while the latter, which encompasses two sub-services (DigitalBrowse and PhysicalBrowse), supports users so that a target thing is reached. Services introduced in [11] can solely be used in high-perspective architecture, which is featured in the current paper for the physical guidance of things in the real world.

By focusing on the four functional features needed by ubiquitous services, namely identification, notification, monitoring, and tracking, [32] specifies 24 different application services that have all four of the above features. Then, according to the ubiquitous computing specification, which is based on being everybody, everywhere, and at any time, the three criteria of service classification are determined: subject, place, and time.

Finally, the services are classified into different types based on these criteria. The main disadvantage of this classification is the services’ dependency on the type of application. In other words, services are determined based on the type of application and then classified according to three criteria. Another disadvantage of this categorization is the overlapping of the services with each other that results in rewriting many codes for each service.

However, in the European research open-code project PalCom, a ubiquitous computing project for designing computing technologies in things and rendering the surrounding user environment tangible, all services are divided into control services, streaming services, and meta services [68]. In this categorization, control services signify services that can induce change in environmental devices, such as the decrease or increase of a speaker. Streaming services are those which can unilaterally transfer data of a particular type, such as sound or image, between two components, like a service or device. However, meta services are services which cannot be used alone, but can only be employed by other services, such as logging or debugging services. Based on [68], its categorization is solely designed for PalCom. Therefore, regardless of the scenario type, only services which are presented in PalCom can be categorized as such.

In [80], the composition mechanism of ubiquitous services is such that the system using these services can effectively overcome environmental changes and errors. With this in mind, [80] presents a categorization of basic ubiquitous services based on the functionality of services and the role each play, with the services divided into three kinds of abstract service components. According to this categorization, a normal service may include a context provider, context processor, and/or an information deliverer. The context provider’s function is to recover particular sensor data. Based on the data provided by the context provider or the data inside a database, the context processor produces meaning-based information to be utilized in the information deliverer service. The information deliverer service also includes hardware resources which can present the provided information to users. In [80], this categorization is only provided to extract sensor data and to deliver proper results to users via the capability of services composition; there is no discussion about other presentable services in ubiquitous environments.

In contrast, according to the type of user personal information, as well as the expected security of services in ubiquitous applications, the authors of [46] propose a hierarchical classification for services aiming to create a balance between ubiquitous user interactions and the principle of confidentiality. This classification divides services into three types: privacy-based, protection-based, and public-based. According to the expected level of user trust while taking into account three types of information (location-aware, identity-aware, and credit history), [43] presents a category of ubiquitous services for the fixed information of applications, such as the type of application, cost of service usage, and the host executing the application. Both [46] and [43] aim to improve user security and focus more on the security aspects of services, but do not mention other service properties.

[38], on the other hand, deals with the ubiquitous services of an urban environment. Thus, all such ubiquitous services are determined and the services classified into three groups (service operation, city function, and utilization object), while the three criteria of cost, access, and type of application are taken into account. Of course, the three groups are not in conflict with each other and all three can be used for any specific service. The service operation category classifies services into public and commercial types. The public involves free services and the commercial incur costs. Services in the city function category are divided into generality and specialty types. Generality is the basic services and specialty is certain services of an urban application. Finally, the utilization object category divides services based on their application in life and industrial. Life is for services related to people’s personal lives and industrial for services related to industry. Although, an acceptable classification of services is presented in [38], it is based on services for an urban environment. Therefore, this classification cannot be generalized and poses limitations for other environments.

Finally, the authors of [50] survey presentable services in ubiquitous user-centric information systems and offer 17 kinds of services in the form of a particular scenario and based on several user features, such as the role of users, their location and profiles, and also characteristics of the utilized devices by users, such as network type and memory. These services can be allocated to different user requests according to their willingness and concept of context. The provided taxonomy of services in [50] is solely based on the function of ubiquitous information systems and set for a particular scenario. This cannot be utilized for other applications or even other scenarios in the same ubiquitous information systems application.

Various research work has investigated security in ubiquitous architectures. In [66], security issues in ubiquitous computing are explained and categorized through several applied examples. According to this study, the most serious challenges are privacy and authentication, as possible solutions should not affect the usability of the ubiquitous system. [51] investigates some of the security challenges involved in the information and services management of ubiquitous systems. This research shows that the mobile nature of ubiquitous devices is the main reason for developing secure algorithms for ubiquitous information and services management. Ubiquitous applications not only collect a wide range of privacy sensitive information from individuals and their social circles, they also control environmental equipment and so affect the lives of individuals. Therefore, [86] explores the most pressing challenges and noteworthy solutions of security and privacy in the applications of a ubiquitous smart city.

In [4], a context-aware access control model is introduced for ubiquitous environments along with its main features, including decentralization, robustness in the face of context errors, distributed trust, expandability, flexibility, and scalability. The proposed model is evaluated by a smart emergency room scenario. The study conducted in [33] indicates that ubiquitous computing environments require a trust-based secure architecture due to the lack of a central control in ubiquitous computing environments and the non-specification of users in these environments; in contrast, all architectures are based on user authentication and access control. Hence, this secure architecture introduced for ubiquitous computing is based on confidentiality. However, according to [10], protecting privacy in ubiquitous environments is a huge challenge. Therefore, in order to address this, a privacy-based service-oriented architecture is proposed for ubiquitous computing which also provides a classification for offensive attacks on privacy and the categorization of its improved technologies. Since location awareness and privacy are two sides of a coin and conflicting, [7] examines privacy in location-aware ubiquitous applications. A solution is proposed for offering services that can provide the minimum amount of privacy for the users of the environment.

[8], however, investigates information encryption methods that are usable in ubiquitous systems and introduces a block encryption method for ubiquitous computing applications that can perform ubiquitous data encryption with a slight delay. In [12], several encryption approaches are also proposed to solve the security and privacy challenges of ubiquitous computing. In all of these, the two essential features of ubiquitous computing systems are considered, including the diversity of computing resources available to ubiquitous devices and the dynamic nature of this type of computing. [57,71,89] also study the issues and challenges of access control, confidentiality, and the security of wireless communications in ubiquitous computing respectively, in addition to introducing solutions.

Security in the cloud has also been investigated from various aspects. In [60], the security challenges in cloud computing along with provided solutions are explored in general terms. By focusing on the types of cloud data and using the opposing criteria of security and applicability, this research compares four different approaches in order to safeguard confidentiality in the cloud provider. [48] presents a comprehensive categorization of security challenges in cloud computing, in which cloud security is investigated from three viewpoints: communications security, architectural dependence, and contractual concerns. In the context of architectural security, this research categorizes existing issues into four groups: virtual machines, data control, application programming interface, and access control. It has been argued that there is an essential need for a systematic review of cloud security issues based on the type of application (manufacturing systems here), because of the privacy and worthiness of the data on one hand and security risks and harm due to the nature of network systems on the other hand.

In [74], the concept of cloud security is investigated from two perspectives: cloud providers and cloud customers. In this regard, the most important challenges faced by providers and customers are generally categorized. The security challenges include service level agreements, authentication and identity management, protection of data centralization, confidentiality, access control, and accounting. In [87], five different development models are proposed by focusing on various security issues that users may encounter in cloud systems, such that those addressed here. The models are: separation, availability, migration, tunnel, and encryption models. However, in [36], a comprehensive study on various security issues of cloud computing is conducted and the types of issues are categorized into 43 different groups.

While outlining the most important security issues in the cloud and providing a layered framework for an assured cloud, [25] focuses on cloud storage and data concerns. In particular, the approaches to secure processing of data query are explained while data storage methods on external machines and the creation of queries for encrypted data are described. In contrast, [56] addresses data security in the clouds and also proposes solutions while categorizing the most important challenges of data security in the cloud. In [55], cloud security challenges are examined from three perspectives: data storage issues, identity management, and access control. There is also a review of contractual and legal considerations and the solutions proposed by others to address these challenges. While presenting existing security challenges for storing big data in clouds, [41] introduces an efficient security-aware distributed storage approach for the secure storage of big data that intelligently segments files and, after encryption, separately stores each segment’s data into cloud distributed servers. This approach aims to reduce the time of storing big data while considering security.

[15], however, investigates the existing issues and solutions in the area of secure service level agreements in cloud computing. For this purpose, a systematic mapping process is utilized which compares the security performance of various agreements with three steps: design, implementation, and conclusion. Finally, in [64], the issues and challenges of cloud security are fully indicated and categorized as the basic security concepts in cloud computing are explored. The most important threats to cloud security are also investigated. Consequently, the requirements and solutions proposed in research literature are presented for all of the discussed challenges and threats. While there is research that has separately reviewed the most critical security challenges and issues in cloud and ubiquitous computing, there has not yet been any research addressing the challenges and issues in hybrid ubiquitous environments.

In a ubiquitous environment, users connect to the ubiquitous system and provide system inputs or use system outputs through devices and equipment. In general terms, these devices and equipment are categorized as follows: (1) Sensor devices: such as smoke sensors, body sensors or motion detection sensors which enter inputs into the system after being installed in the environment; (2) Smart equipment: such as smart mobile phones, pocket computers or tablets with the capability of both entering inputs and displaying results to users; (3) Non-smart equipment: such as the keyboard, control panel or light keys which are solely capable of entering inputs into the system; and (4) Actuator devices: such as lamps, monitors or blood pressure alarms which solely show the resulting outputs. Apart from actuator devices which display system outputs for users, the first three categories of devices can enter inputs into the system through one of the following methods:

– Explicit method

In this method, inputs are entered into the system directly by the users and through the common input tools, such as the keyboard, mouse, touchscreen, microphone, camera, light keys, and controlling keys on a panel. Generally, these inputs have a certain purpose and should always be stored in the system for the future use. Explicit inputs are generally entered into the system through both smart and non-smart equipment.

– Implicit method

In this method, inputs are entered into the system accidentally through environmental sensors, such as smoke, temperature, pressure, weight, motion, connection, light, and the other sensors. These inputs do not necessarily have a purpose and occasionally require proper filtration before storage. Although implicit inputs are usually entered into the system through environmental sensors, in some cases, one can enter them via sensors embedded inside smart equipment, such as the barometer or accelerometer in most smart phones.

In a ubiquitous system, one can attribute several features to inputs, whether implicit or explicit. These features greatly impact the functioning of a ubiquitous system. For example, one of these features can be the priority of one input over the others. In other words, an input, whether implicit or explicit, may have higher, similar or lower priority than other inputs based on its application. For example, there may be a medical application in which several inputs are entered simultaneously: two explicit inputs, namely a request for turning on a light and a request for the submission of a list of all physicians, along with two implicit inputs, namely an increase of a patient’s blood pressure and a rise in the patient turnover at the hospital. Now, if the priority of different inputs is not specified in a system in advance, the system is incapable of identifying the nature of these inputs and responding properly. In this case, the request for turning on the light might be answered sooner than the request to assist a patient in critical condition. In Table 2, some but not all of the inputs believed to be of the highest importance in a ubiquitous system are given, along with parameters attributable to explicit or implicit cases.

However, a ubiquitous request is defined as follows.

Given the discussion in the previous sections, it is concluded that, based on existing technologies, ubiquitous cloud computing can currently be considered as the ideal ubiquitous type. Therefore, assuming that the main criterion for selecting ubiquitous cloud computing is to access the real capabilities of ubiquitous computing, one should then regulate the service features according to what should be and not according to what is. Next, several expected service features in ubiquitous cloud computing are suggested, which can then be considered as the criteria for service categorization.

However, from a security perspective, ubiquitous cloud computing environments are multi-domain environments in which each domain can have different security requirements and use different security mechanisms and protocols. In general, in a ubiquitous cloud computing architecture, the following concerns should be addressed so as to provide the minimum level of security required from both the cloud point of view and the ubiquitous viewpoint:

All security issues in ubiquitous computing should also be considered in ubiquitous cloud computing and their solution must be found. These concerns include authentication, encryption, access control, secure boot-strapping, privacy, confidentiality, and reliability [4,7,8,10,12,33,51,57,66,71,75,86,89].

6. Categorization of services in ubiquitous cloud computing

Before the categorization of services, the structure of ubiquitous cloud computing should be regulated based on the services provided. To achieve this, according to Section 4’s suggested definition of ubiquitous cloud computing, an architecture called CLOUBI architecture (CLOud-based UBIquitous Architecture) is assumed as the basic architecture (Fig. 1). As evident in this figure, CLOUBI architecture best portrays the suggested definition for ubiquitous cloud computing which demonstrates a connection between ubiquitous domains and the computing cloud by considering the basic architecture of each. This multi-domain hybrid architecture is constituted of three layers: the user layer (the lowest layer), ubiquitous layer (middle layer), and cloud layer (highest layer). The relation between these layers is hierarchical [3,69] and the basis of connection is the ubiquitous layer (equal to the distributor layer in [69]’s definition of layers). Moreover, current domains in the ubiquitous layer are capable of establishing connections with their adjacent domains. The adjacency of two domains results from criteria such as geographical distance, the domains’ inter-dependency, or previous user profiles. Generally, the architecture in each layer is based on the accepted definitions provided in advance for both ubiquitous computing and cloud computing, which might be slightly different in detail. In Fig. 1, m numbers of ubiquitous domains are present in the ubiquitous layer, each of which include a number of users in the user layer and all of which are connected through a cloud in the cloud layer. Of course, there is no limitation on the number of clouds and so various clouds can be considered in the cloud layer.

OPEN IN VIEWER

Fig. 1.

The communication structure of CLOUBI architecture layers based on the proposed definition for ubiquitous cloud computing.

In CLOUBI architecture, each ubiquitous domain is capable of connecting to other components in three methods. In the first simplest method, to receive user requests and send the proper output after their processing, a connection is established with users through the current domain’s local devices and equipment. In this case, the user requests are in need of the local domain’s services. The second type of connection occurs when user input requests require services in one the adjacent domains, and, hence, a connection is established between the current domain and adjacent domains with these kinds of services. In this method, necessary permits must be obtained in advance in order to use services. The third type of connection is established when the current domain is incapable of responding to the request due to a lack of requested services or a lack of proper resources for user input requests and when adjacent domains are unable to process the request as well. In this method, a connection is established between the current domain and the cloud so that the user request is processed there after being sent to the cloud or it is forwarded to a non-adjacent domain via the cloud and processed there. Eventually, the cloud produces the proper results and returns these to the current domain. This connection frees users of any extra charges. Only if there is a need to send user requests to the cloud, non-adjacent domains and, of course, perhaps adjacent domains (based on the type of application and architecture policy), users have to pay the costs.

As shown in Fig. 1, there are a variety of devices and equipment which play the role of a link connecting users to the system. These devices and equipment include what is mentioned in Section 3. Enjoying mobility between domains, users in the lowest layer are capable of connecting to existing devices and equipment and entering their request to receive services. Fig. 2 presents an example of the interaction between users in domain k and the system for sending input requests and receiving output results. As depicted in this figure, user requests are first sent to the ubiquitous management system in domain k. This system will then decide to process the requests locally or send them to the cloud or one of the adjacent domains for processing. One of the notable points in CLOUBI architecture is that users of a domain can make connections to other close by users of the same domain via their own equipment. This feature is believed to decrease the loading volume of the ubiquitous system’s processing core when a connection is regulated with a close by user or there is a need for the services of a nearby user’s equipment.

OPEN IN VIEWER

Fig. 2.

Method of interaction between users of a ubiquitous domain and the ubiquitous management system for sending requests and receiving results.

In regard to the current applications of ubiquitous computing, the expected features of ubiquitous cloud computing, and the regulated architecture for ubiquitous cloud computing, it is appropriate to consider the categorization of ubiquitous cloud computing. The categorization of ubiquitous cloud services in CLOUBI architecture can be viewed from two perspectives: first, categorization based on the nature of services and, second, categorization based on the distance between the requesting and responding entities.

6.2. Categorization based on distance

Based on the distance between the requesting user of a service and the service provider, services can be divided into five groups: near, local, remote, global, and far. This categorization is by no means inconsistent with categorization based on the nature of services (Section 6–1). It can be considered for any type of data, context-aware, software, and hardware services.

6.2.1. Near services

In a ubiquitous environment, if a number of services are provided by the existing devices and equipment in the user layer and these can be provided solely for close by users or the services requested by nearby users, then these services are called near services. Usually, such services are lightweight and not many resources are needed to provide them. Besides, their capabilities depend on the volume of existing services in the devices and equipment. An example of near services may be an application called “food order recommender” installed on a user’s smart phone as user equipment. In a restaurant environment, this application gathers the data of other users’ orders. Based on the number of orders placed by users for a particular menu item, the application suggests the most popular as the meal of choice for the smart phone user. In this example, to operate, this application needs no upper-layer resources (to be introduced later as other services) and solely requires adjacent data as near data services.

6.2.2. Local services

In a ubiquitous environment, if a number of services are provided by the ubiquitous system’s processing core in a specific domain and only for users of that domain, these services are called local services. The capability of these services depends on the assumed ubiquitous domain’s processing core power in terms of the number of presentable resources. Presentable local services may include local data services, local context-aware services, local software services, and local hardware services.

6.2.3. Remote services

Remote services are services in a multi-domain ubiquitous environment which are provided by the processing core of each domain and may be employed by users in other adjacent domains. An adjacent domain is determined based on criteria such as the geographical distance between domains, inter-dependency of domains and/or user profile data. Similar to local services, the capability of these services depends on the processing core power of the service provider domain. Presentable remote services may include remote data services, remote context-aware services, remote software services, and remote hardware services. Generally, remote services cannot be utilized by the users of a single-domain environment with a zero external connection to other domains and, as the result, with their services.

6.2.4. Global services

In a hybrid ubiquitous environment, global services can be employed at all places by users or their requested services. Generally, these services cannot be provided without the usage of clouds. Therefore, unlike previous cases, it can be said that these services have no limitation of resources, are identical in all areas of the ubiquitous environment, and do not differ in their demonstration. Global services may also include global data services (similar to DaaS cloud services [27,76]), global software services (similar to SaaS [5,40], and PaaS [5,73] cloud services), as well as global hardware services (similar to IaaS cloud services [5,18]). As the concept of context is meaningless within the cloud, global services cannot support context-aware services.

6.2.5. Far services

In a hybrid ubiquitous environment, far services refer to the services supplied by the processing core of each non-adjacent domain of the current domain; far services can be provided by a cloud for current domain users or other services requested by them. The non-adjacency of a domain to the current domain refers to the absence of any direct link between the two domains; if domains are not adjacent, they will be certainly non-adjacent. In global services, it is not possible to provide such services without utilizing clouds. The most critical achievement of far services is accessibility to the local services of all domains which are not directly connected to the current domain. Far services can also include far data services, far context-aware services, far software services, and far hardware services.

In the single-domain ubiquitous environment, only near and local services of any kind may be provided; in the multi-domain ubiquitous environment, only near, local, and remote services of any kind are possible. In other words, in single- and multi-domains, global and far services, including data, context-aware (only for far services), software and, hardware services, are not accessible to users; moreover, intensive software services and unlimited hardware services are mostly impossible to provide and, from this perspective, multi-domain environments are very limited. Furthermore, in an integrated method and without further registration, a user is not able to use all of the services provided in any desired domain, which is the main purpose of ubiquitous computing; even with further registration, there will be inconsistency of data, i.e. much of the user information in the previous domain will be completely inefficient in the new domain. Table 5 examines the possibility of using the above categorized services in single- and multi-domain pure ubiquitous environments and offers some explanations for this.

OPEN IN VIEWER

Table 5

Evaluation of the possibility of using categorized services in pure ubiquitous environments

Services		Single-domain Ubiquitous Environment	Multi-domain Ubiquitous Environment	Comments
Data Services	Near	Close user	Close user	Access to near data services in single- and multi-domain ubiquitous environments is possible through the connection with adjacent devices and equipment. The span of these kinds of services is directly related to the capabilities of storage and local sensing of devices and equipment of the user layer.
	Local	Local	Local	With the increase of acquired data from the environment, their processing is difficult and their efficiency and accuracy lower. Whether in single-domain or multi-domain ubiquitous environments, the requesting user of local data services can only use the local services of the domain in which he is settles.
	Remote	N/A	Remote	In single-domain environments, one can only access the local data services of the same domain. In multi-domain environments, the access to data of several related domains is possible; moreover, in this case, the volume of transferred data affects efficiency. In both environments, access to global data services through internet is possible, but vast maintenance and control of these global collections in a local manner is impossible due to the lack of resources.
	Global	N/A	N/A	Access to user profiles is not possible everywhere because multi-domain environments have various limitations and it is not possible to call for user profiles in every domain (a multi-domain environment provides services only to its adjacent domains and not other domains; therefore, multi-domain environments cannot be completely called ubiquitous). In single-domain ubiquitous environments, there is only access to near and local context data. In multi-domain ubiquitous environments, one can only access near, local and remote context data. In neither environment is access to global context information possible.
	Far	N/A	N/A	Due to the lack of communication with the cloud, it is not possible to use data services in non-adjacent domains.
Context-aware Services	Near	Close user	Close user	Near context-aware services can be used in both single-domain and multi-domain environments.
	Local	Local	Local	It is possible to access local context-aware services in all ubiquitous environments.
	Remote	N/A	Remote	Access to remote context-aware services is just possible in multi-domain environments. Due to the lack of communication with other domains in a single-domain environment, it is not possible for the user of the current domain to control its contexts.
	Global	N/A	N/A	As the context concept is meaningless within the cloud, global context-aware services cannot be used even for hybrid ubiquitous environments.
	Far	N/A	N/A	Due to the lack of communication with the cloud, it is not possible to use context-aware services in non-adjacent domains.

OPEN IN VIEWER

Table 5

(Continued)

Services		Single-domain Ubiquitous Environment	Multi-domain Ubiquitous Environment	Comments
Software Services	Near	Lightweight	Lightweight	Access to nearby software services in single- and multi-domain ubiquitous environments is possible. The capability of these services is directly related to the capabilities of devices and equipment of the user layer.
	Local	Lightweight	Lightweight	In this case, the required data of software services is effective in the efficiency of the service. Besides, utilizing heavier services is not possible due to a lack of resources and global inaccessibility of data.
	Remote	N/A	Lightweight	Access to these services is solely possible in multi-domain environments; moreover, due to reasons mentioned in the previous section (lack of resources and global inaccessibility of data), using heavier services is not possible.
	Global	N/A	N/A	Access to global software services in a ubiquitous environment is a requirement in order that everyone can use all software services which are developed in a ubiquitous environment. This access is impossible in single-domain environments and only possible in inter-related domains in multi-domain environments (in fact, access to remote services is possible, but not to global services in their essence).
	Far	N/A	N/A	Due to the lack of communication with the cloud, it is not possible to use software services in non-adjacent domains.
Hardware Services	Near	Very limited	Very limited	Access to near hardware services in single- and multi-domain environments is possible. Nearby hardware services are very limited and depend on the volume of hardware resources available to close devices and equipment.
	Local	Limited to a single domain	Limited to a single domain	Local hardware resources might be used by users of a single- or multi-domain ubiquitous environment. These resources are very limited even for users of multi-domain environments (only access to resources of the same domain).
	Remote	Limited to multi domains	N/A	Utilizing remote resources in a single-domain ubiquitous environment is not even possible; however, using these resources for multi-domain environments is possible but limited and ends in the use of resources of related domains.
	Global	N/A	N/A	In a real ubiquitous domain, users should be able to use all hardware resources of the whole environment, while this is not possible for single-domain environments; for multi-domain environments, users are limited to resources of all inter-related domains. Moreover, for services with intensive resources, using powerful hardware resources is of great significance.
	Far	N/A	N/A	Due to the lack of communication with the cloud, it is not possible to use hardware services in non-adjacent domains.

OPEN IN VIEWER

Fig. 3.

User access to various services in the CLOUBI architecture.

With the increase in the number of domains in a multi-domain environment, however, the efficiency and performance of a multi-domain system will decrease. This is due to a lack of hardware services and resources in the processing core of centralized multi-domain architectures and also a lack of hardware resources of the domains in distributed multi-domain architectures. It should be noted that a multi-domain environment provides services only to its adjacent domains and not to other domains; hence, it cannot be claimed that multi-domain environments are completely ubiquitous. On the other hand, in ubiquitous cloud environments, accessing any kind of near, local, remote, global, and far services is possible. Besides the combination of domains with each other and the increase in the ubiquitous processing core’s capabilities, the usage of ubiquitous cloud computing will make it possible for users to access a vast number of services in an integrated way. Ubiquitous cloud computing can fulfill all requirements by providing unlimited resources; moreover, the scalability of domains and the potential of adding new services are possible. Fig. 3 illustrates the requesting user’s method of access to CLOUBI architecture services.

It should be noted that other factors may also affect the classification of services, such as the type of security protocol, cost of service usage, or type of platform on which the service is provided. However, the present study holds that these and other similar criteria do not alter the nature of the services and can be considered in the form of service properties when defining the service. Therefore, it is not necessary to create a categorization based on these criteria. For example, when defining the service class, a property can be considered for the cost of service and, when defining a particular service, this property can be initialized so the usage cost can be calculated when a service is utilized by the users.

Figure 4, however, shows the communication standards and protocols required to connect the different parts of the proposed architecture when implemented. As a user enters a domain, he/she is able to connect to different parts of the CLOUBI architecture through the ubiquitous devices and mobile equipment in the user layer of the domain and so access different services. As Fig. 4 shows, the communication between ubiquitous devices and mobile equipment in the domain user layer can be established through one of the communication standards, including Bluetooth, Infrared, ZigBee, and RFID; on the other hand, the communication of these devices and equipment with the components in the ubiquitous layer of the domain can be set up via a wired/wireless local network. In the ubiquitous layer of each domain, a component called a cloudlet is employed. A cloudlet is able to communicate with similar components in other adjacent domains and offer remote services while processing user requests and providing local services. The adjacent domains are the domains connected to the current domain via a wired/wireless local area network. The cloudlet component also provides the connection between the ubiquitous layer of the current domain and the clouds in the cloud layer through the Internet so that global and far services can be offered to users in the domain. Cloudlets are, in fact, private clouds that can be placed locally in the user environment, depending on the type of application [6]. In the CLOUBI architecture, if there is no cloudlet in the ubiquitous layer, devices and equipment connect directly to the clouds in the cloud layer over the Internet so that services run consistently and continuously.

The current paper examines the characteristics and categorization of services in ubiquitous cloud computing. With this aim and given the deficiencies of pure ubiquitous computing, the reasons for using hybrid architectures and especially ubiquitous cloud architectures were surveyed. Next, considering the nature of user requests in a ubiquitous environment, the expected requirements of services were suggested, which a hybrid ubiquitous architecture should provide as a desirable ubiquitous architecture. A ubiquitous cloud architecture called CLOUBI was introduced as basic architecture. Based on the requirements expected of desirable ubiquitous computing and the structure of the basic architecture, two kinds of service categorization were proposed for this architecture: one based on the nature of services and the other on the distance between the service requester and the service provider. Considering the lack of regular service categorization in ubiquitous computing, the present work considers these two categorizations to be functional and beneficial for other research.

OPEN IN VIEWER

Fig. 4.

Initial communication standards and protocols needed for implementing the proposed CLOUBI architecture.

From the perspective of ubiquitous services’ applicability, the current study believes these services must be defined and categorized in such a way so as to allow their use in any application. In other words, a general class should be presented to define ubiquitous services so that any type of application can customize and utilize the services based on its particular needs and specifications, instead of utilizing its own exclusive services. This eliminates the services’ dependency on applications and presents a single definition of a service across the ubiquitous environment. The greatest advantage of the present study is its general classification of services; one is based on the nature of the services and the other on the distance between the service requester and the service provider, both of which can be used in any application. These classifications are based on a new hybrid architecture called CLOUBI, whose aim is to achieve an ideal ubiquitous architecture by combining the capabilities of cloud and ubiquitous computing with each other. In addition, due to the importance of security in all computational architectures, the most critical security concerns related to ubiquitous cloud computing architectures are also investigated in the current paper.

The currently proposed architecture is also advantageous when compared with existing architectures. Firstly, the proposed CLOUBI architecture is a three-layer architecture. The current study believes that a hybrid ubiquitous architecture should only have three layers. Thus, while maintaining performance at a satisfactory level, it reduces user costs and, at the same time, overcomes the resource limitations in a pure ubiquitous architecture. By decreasing the number of layers, the user’s dependence on the cloud increases, while the ability to comprehensively use ubiquitous capabilities reduces. Yet, by increasing the number of layers, the user costs of hardware and support for maintaining intermediate layers will greatly rise, while the management process grows more complicated. Secondly, in this comparison with other architectures, the currently proposed architecture is able to provide services in the manner desired by the user and which are independent of the type of resources available to users. In this architecture, according to the type of user request and the location of the service, any service type can be provided due to the classification of services. Additionally, while allowing the user to control all the aspects of peripheral sensors and actuators, the cloud presence overcomes all the limitations of pure ubiquitous architectures.

Follow-up work to the present research on ubiquitous cloud computing may encompass a variety of areas. One is the precise compilation of hybrid architecture details in such a way that the expected features of an ideal ubiquitous computing pattern may be fulfilled. The next work can be devising a generic model for symbolically defining the service that enables modeling services for different applications by focusing on the quality of service criteria. The development of various algorithms for hybrid architecture is another potential research area; this is highly important in view of the ever-increasing number of ubiquitous devices and equipment. Among these algorithms are context-based, scheduling, resource allocation, offloading, security, and data management algorithms. Furthermore, this computational pattern requires the implementation of a simulator to evaluate the efficiency of various algorithms. Another significant implication that should be addressed in ubiquitous cloud computing is the concept of security in different dimensions, whereas the current study only briefly addresses some of the security concerns in a hybrid architecture as further consideration is out of the scope of the present research.