A smart city [1]-[4] attempts to make the best use of innovative ICT solutions to manage urban issues related to mobility, people, economy, security, public health, environment and resource management, etc. With continuous increase in urban population, the need to plan and implement smart city solutions for better urban governance is becoming more evident. These solutions are driven, on the one hand, by innovations in ICT and, on the other hand, to increase the capability and capacity of cities to mitigate environmental, social inclusion, economic growth and sustainable development challenges. In this respect, citizens’ science or public participation provides a key input for informed and intelligent planning decision and policy-making. However, the challenge here is to facilitate public in acquiring the right contextual information in order to be more productive, innovative and be able to make appropriate decisions which impact on their well being, in particular, and economic and environmental sustainability in general. Meeting such a challenge requires contemporary ICT solutions, such as using Cloud computing. Use of elastic Cloud resources enable these solutions to store and process significant amount of data and produce intelligent contextual information with high quality of service. However, processing, utilising and visualising contextual information in a Cloud environment require tailored mechanisms for user profiling and contextual segregation of data that could be used in different applications of a smart city.

Smart cities include several applications where socio-technical interaction between citizens and pervasive devices a.k.a. Internet of Things (IoT) is often needed [5]-[7]. A continuous monitoring of these interactions can provide: i) evidence based urban planning, policy-making and collaborative decision making support, and ii) raise situational and environmental awareness that can eventually result in behavioural change based on the information of citizens daily life usage of these interconnected devices. Furthermore, these IoT can also facilitate environmental data gathering in order to mitigate environmental challenges. For instance, environmental sensors can pervasively collect data from the environment e.g. noise and air quality. Similarly, citizens can participate in environmental data collection and dissemination using smart phones or through social networking sites, resulting in promoting the concept of citizen science. Other crowd sourcing applications can be highly useful in emergency response (e.g. flood, accident), traffic management (e.g. gridlock on a busy motorway), quality of life surveys etc. However, such monitoring, citizen’s engagement, information processing, visualisation and decision making require sufficient computing infrastructures and attached resources for data storage and real-time processing.

The need for such resources becomes more evident when a city is considered as a single unit dealing collectively with challenges related to environment, socio-economic, security, health and well-being of citizens, education and public services. These multi-spectrum challenges necessitate cross-thematic data harmonisation, integration and coordination between various departmental boundaries in order to monitor and model future smart cities. For instance, cities face challenges of urbanisation, and it is expected that by 2020 up to 80% of population will be living in cities [8], that puts enormous pressure on the limited municipal resources. It also becomes challenging for ICT to manage such monitoring, support smart planning and facilitate better governance for socio-economic growth and sustainable urban development. Such a system requires large storage and processing power in order to capture, store, process and generate required necessary real-time information to end users. Cloud computing [9] has the potential to manage this monitoring challenge and can provide the necessary storage and computing facilities at comparable costs [10]. For example, Komninos et al. [11] review technologies for smart cities by introducing a short to long-term roadmap towards smart cities. In addition to Cloud computing, other complementary technologies include future internet, analysis and visualisation tools, sensors, RFIDs, semantic web, linked data and ontologies for smart cities [11].

Figure 1 illustrates an information perspective within smart cities. It highlights the dependencies between citizens, data, ICT tools, utilisation and provisioning of municipal services, and effectively supporting participatory governance. Figure 2 illustrates a number of pertinent smart cities issues that affect sustainable development of the city. With respect to public participation, citizens can perform two roles: i) act as information recipients for better awareness of their surroundings, and ii) data collectors. As information recipients, context-aware information availability can help citizens to make informed decisions in their daily life. For example, knowing the air quality at a specific location can be useful for taking necessary precautions for citizens with respiratory issues. As data collectors, participatory sensing can help in collecting environmental or other data (e.g. quality of surroundings such as offices and parks) that otherwise is either difficult or expensive to collect and manage. Citizens may not need to collect the data all the time and at different locations (e.g. when travelling) and only need to receive information that is more related to their profile and situational needs. Such a requirement, on the one hand, reduces the amount of data to be captured and processed. On the other hand, new filtering and computational services need to be developed in order to fulfil this requirement. In this regard, smart city based context-aware services [12] for citizens can help them to better use their environment by getting awareness about their surroundings and available services. However, using Clouds and developing context-aware user services for participatory monitoring to support better decision making is not straightforward and raises several research, development, deployment and adoption related challenges such as user profiling and security, data and information segregation, processing and storage.

Figure 1
figure 1

Smart cities - Information perspective. The dependencies between citizens, data, ICT tools, utilisation and provisioning of municipal services in order to support participatory governance.

Figure 2
figure 2

Smart cities related issues and challenge areas. A number of pertinent smart city issues that affect sustainable development of the city.

In this paper, we discuss related issues of data and computation infrastructure and context-awareness and present related work in the `Context-awareness, data and computational infrastructure requirements’ section. Thereafter in the section `Conceptual framework for cloud-based context-aware services’, we propose a conceptual framework that provides a roadmap establishing the basis for the development of an integrated Cloud-based architecture for context-aware user services, which is then elaborated further in the section titled `Proposed architecture’. Furthermore, we showcase a hypothetical example using Bristol Open Data [13] in order to walkthrough the proposed Cloud based architecture for smart cities in the section `Use case and discussion’. In `Proof of the concept’, we present a proof of concept implementation of the proposed architecture along with evaluation and discussion. Finally, we conclude in the `Conclusion and future work’ section.

Context-awareness, data and computational infrastructure requirements

As discussed earlier, communication and information services provided by ICT bring smart aspect to the management of cities by transforming data into useful knowledge and actionable information. The challenge in realisation of smart cities through ICT lies in the integration of data from disparate sources and processing into useful information delivered through services, consumed by citizens and public administrations. This challenge has different dimensions including the collection of huge amounts of data, the aggregation of data in various formats, relevance of such data to practical problems and scenarios, analysis of the data to deduce useful information and visualisation, and management of the historic and ever-increasing sets of such data. Addressing these challenges require a multipronged approach involving standardisation of data formats, data harmonisation mechanisms, computational processing and storage infrastructure and mechanisms to ascertain contextual relevance of the data with its consumers.

As discussed earlier, communication and information services provided by ICT bring smart aspect to the management of cities by transforming data into useful knowledge and actionable information. The challenge in realisation of smart cities through ICT lies in the integration of data from disparate sources and processing into useful information delivered through services, consumed by citizens and public administrations. This challenge has different dimensions including the collection of huge amounts of data, the aggregation of data in various formats, relevance of such data to practical problems and scenarios, analysis of the data to deduce useful information and visualisation, and management of the historic and ever-increasing sets of such data. Addressing these challenges require a multipronged approach involving standardisation of data formats, data harmonisation mechanisms, computational processing and storage infrastructure and mechanisms to ascertain contextual relevance of the data with its consumers.

The sources of data related to urban environments continue to increase, ranging from data gathering services and sensing platforms deployed by administrative authorities to data gathered by/from the citizens through participatory and opportunistic sensing mechanisms. However, the absence of a common and standardised platform for collection, storage and utilisation of such data for collection, analysis and dissemination of such data severely curtails the prospects of information and services that can be developed and benefit the smart city themed infrastructures. Hence the foremost requirement for realising holistic smart city related information services by and for wide-spectrum entities (citizens, governments, private enterprises) is to agree and utilise common, standard and inter-operable data formats.

An important qualitative provisioning of ICT for smart cities is the inclusive governance by informed citizens through participation i.e. an aspect of citizen science that allows their participation in information collection as well as information utilisation. Citizens are likely to be better informed and engaged if the services they consume relate to their social and environmental context. Context-awareness, which is an established discipline in the computer science and human-computer interaction domains, is thus pertinent to the employment of ICT in smart cities. However, integration of such contextual information is not straightforward due to a number of factors. These include the availability of relevant contextual information, heterogeneity of information that is available, inter-linking different types of context from possibly different sources, aggregating independently sourced contextual information to infer higher-order context about citizens and environments.

The provisioning of context-aware services also depends on the seamless integration of data collection, processing and dissemination systems whose challenges we have discussed in the earlier sections. Such technology integration to develop comprehensive smart city platforms is one of the primary objectives of the European Innovation Partnership that is endeavouring to catalyse progress in this area [14]. Situation and contextual association of data to their pertinent environmental and human artefacts exists and not only in the raw state of the data (e.g. when it is collected by a sensor node), but also continues to associate as data are aggregated and synthesised into higher level information sets (e.g. by combining multiple data values and inferring higher complex informational concepts about the environment). Therefore, any data formats, data collection mechanisms and information processing steps should continue to retain and extend contextual characteristics of aggregated data as it moves vertically from raw state towards its manifestation as complex, serviceable information.

The requirements of data collection, aggregation, representation formats and contextual annotation hint towards another requirement of a resourceful and scalable computational infrastructure. Cloud computing – based on the concepts of converged infrastructure and shared services – can be utilised to address some of the challenges in this domain, primarily those related to the collection, storage and processing of the urban domain data. Cloud computing is ideally placed to provide infrastructural support for meeting the smart city domain challenge through its key characteristics of reliability, scalability, performance and cost effectiveness. Most importantly, utilising a cloud computing infrastructure for smart city related data collection, processing and service delivery can remove the burden of computational infrastructure management and administration from a single entity (e.g. a city government). It also reduces the risk of increasing heterogeneity, which is likely to set in when different stakeholders utilise their own computation infrastructure for data collection and processing related activities. There is an industry-wide push towards providing Cloud-based smart city solutions [15] and we are beginning to see prototype implementations at various early adopter cities [16].

Recently there has been considerable interest in context-awareness in clouds. Hyun and Soo have proposed a framework for enabling context-aware mobile services [17]. The framework enables providing better services to users that fit their current context. Saad et al. [18] have investigated caching strategies in context-aware clouds. Their solution takes advantage of the inherent temporal dimension in context data to improve the accuracy of context-based systems. Other endeavours attempt to investigate energy conservation in context-aware clouds [19]. In a cloud-based setting data is vulnerable to cyber attacks. As more and more users are storing sensitive data online, privacy becomes a legitimate concern in these settings. Hamza et al. investigate privacy concerns in cloud-based user data by utilising their sharing context [20]. Paelke et al. have proposed a solution that gathers geo-referenced contextual information from public sources such as Wikipedia [21]. This information is rendered as a tag-cloud and presented to users to increase their awareness about their spatial context. In short, utilising context in cloud-based systems is an active research area with many interested parties.

The issues and requirements discussed above are spread across a range of areas and addressing these holistically requires a bottom up approach that considers the individual artefacts affected by these issues. These artefacts, e.g. data/process models, context models, services, infrastructure, and their subcomponents may have different objectives, roles, stakeholder association and utility. In order to develop a computational architecture for enabling citizen participation in smart cities and delivering contextual information services, we need to categorise and understand these artefacts, their characteristics and inter-relationships. We describe a conceptual framework in the following section to elaborate this point further.

Conceptual framework for cloud-based context-aware services

The motivation behind introducing the framework is to develop a roadmap for the development of cloud-based context aware services for citizens of smart cities. The framework attempts to establish the what, why, how and who characteristics of the relevant artefacts and associated components or procedures. The artefacts are the main building blocks for the development of cloud-based context aware services architecture (discussed later). The artefacts include process models, data models, contextual models, citizen participation, application thematic models, cyberspace infrastructure, management aspects and service federation. The description (i.e. what), goals and objectives (i.e. why) of these artefacts briefly explain their purpose. In addition, various standards and technologies are identified to exemplify how these artefacts can be operationalised and who can be the potential stakeholders. The framework, explained in Table 1, also briefly describes the usefulness of the artefacts.

Table 1 Context-aware citizen services framework for smart cities

The framework is generic in a sense that various artefacts, components, standards and technologies can be applied (as platform-as-a-service or software-as-a-service model) depending on the need of different applications. Also, it is flexible to accommodate new artefacts and procedures and include new technologies and standards for various stakeholders. For example, the contextual models artefact consists of three components structuring and profiling, context exchange and context management. These components contribute in developing user preference profiles, structuring and managing contextual information and associated actions to provide necessary information to end users. In the next section, we attempt to operationalise the above framework by developing a layered architecture using different framework artefacts.

Proposed architecture

Khan et al. [10] presented the capabilities required in a Cloud environment to acquire integrated intelligence for urban management systems. These capabilities provide a sound foundation to respond to smart cities requirements by developing a context-aware component in a Cloud environment. Here we apply the proposed framework and adopt the Cloud-based layered architecture proposed in [10]. The layered architecture is extended by introducing context-aware capabilities to respond to requirements of access to contextual information by citizens as well as data provision on demand basis, as depicted in Figure 3. The proposed architecture can be used to build either a platform-as-a-service or a software-as-a-service solution. For example, when it is used to build modelling service, then it becomes a platform-as-a-service solution on top of which other services can be built. When it is used to build a service that interacts directly with users, for example through visualisation, then it becomes a software-as-a-service solution. In `Proof of the concept' section we present it as a software-as-a-service model.

Figure 3
figure 3

Proposed architecture. Computation architecture for context-aware citizen services smart cities.

The architecture depicted in Figure 3 consists primarily of five horizontal and two vertical layers. In our bottom up approach, the Platform Integration, Thematic and Data Acquisition and Analysis layers output generic data, which can be tailored to specific smart cities related application needs in the top three layers. One of the design principles here is to introduce context-aware components at different layers of the architecture in order to continually coordinate the vertical flow of data and retain or associate contextual information. Below we walkthrough the above architecture with the objective that how each layer contributes towards providing contextual information to end users for various purposes.

  1. 1.

    The Platform Integration layer constitutes a collection of hardware and software components providing the necessary computational infrastructure e.g. a hybrid public and private cloud instances that ensures cross-platform accessibility of data. In addition to the physical computational hardware and virtual Cloud resources, this layer also provides the integration of hardware and software sensors that form the data sources in this architecture. OGC’s Sensor Observation Service [22], which provides the standardised APIs for managing deployed sensors and retrieving observation data is a suitable candidate for this role. The standard also includes provisions for specifying sensor metadata, both for existing and new sensors and can thus provide the necessary building blocks for acquiring contextual information about the sensors.

  2. 2.

    The Data Acquisition and Analysis layer allows collection of environmental data from various sources including remote database repositories, sensor nets, and citizens’ observations, e.g. using smart phones, in the Cloud environment. This layer also ensures the quality of data acquired and identifies the need for necessary data cleansing. A context-aware component is introduced here to filter out unrelated data and to perform quality check and harmonisation only to contextually related data. With respect to the sensed data format, Open GIS Sensor Modelling Language [22] is an established standard that caters for simple, aggregated and derived data concepts and supports multiple encodings (text, XML) as well. Other features that enable harvesting of contextual data from sensed observations include ability to encompass measurements about composite physical and non-physical processes, phenomena, temporal concepts and metadata information.

  3. 3.

    The Thematic layer classifies the acquired data into application specific thematic categories and performs data harmonisation and updates the data/service catalogues for further use of the data. The thematic categorisation of data, that is already contextually annotated, can help in its efficient and appropriate utilisation by services and applications in the higher layers of the proposed architecture.

  4. 4.

    The Service Composition layer is required to design and specify service workflows, identify data sources, and link necessary processing components to enact the workflows that can constitute context-aware, citizen-specific services. Furthermore, necessary analytical analysis of the workflow outputs can be performed in this layer. This layer also ensures that the provenance of data and specific processes is maintained that can be utilised for analysis by different expert systems in the application layer. The context-aware component in this layer helps to utilise contextually related services for workflow composition and information generation.

  5. 5.

    The Application Service layer uses the outcomes from the service composition layer in application domain specific tools such as simulations, smart phone apps and visual maps to perform contextual analysis for decision-making. Further, this layer enables stakeholders to use existing tools and develop new application domain specific components and services (at SaaS level) to satisfy contextual information needs of end users. User context can be modelled in a simple, extensible and machine readable context representation formats e.g. a civil address context snippet related to a person is shown in ContextML [23] format in Figure 4. This layer also supports participatory sensing applications for collection of new data from end users. For example, reporting of micro-criminalities in a neighbourhood using smart phone application.

Figure 4
figure 4

ContextML. ContextML encoded data for a person's civil address.

  1. 6.

    The Management and Integration layer is used to automate the flow of filtered data and information between the horizontal layers. It ensures that processed outputs from one layer to another are contextually related and syntactically correct. It also aims to handle change management that occurs at different layers and to reduce the extent to which the layered architecture requires management overhead.

  2. 7.

    The Security layer ensures the necessary authentication, authorisation and auditing for the use of data and services by legitimate users. Further, it ensures secure personalisation of end users services based on pre-defined preferences for processing and retrieval of contextual information from a Cloud environment.

Use case and discussion

The following discussion showcases a smart city scenario that can benefit from the architecture we have presented in the preceding section. Our premise rests on the importance of smart city solutions for urban governance that involves citizens’ participation for their general wellbeing, city planning and decision-making. We consider citizens not as mere consumers of services offered in smart cities but highlight their inclusive role by acting as collectors of data that informs the development and utilisation of such services. The issue in any such scenario is that the amount of data resulting from the efforts of public agencies that collect such data and contributions from citizens will overwhelm a conventional computing system due to initial and continually increasing storage and processing requirements and compromise quality of service. A Cloud computing based infrastructure that is designed with smart city themed services is well placed to address such issues.

Consider a local city government that maintains a collection of various parameters that reflect the quality of life in the region. These parameters may include general census information and population statistics, labour market profile, crime statistics, traffic, energy and water quality statistics, etc. Occurrence of crime is a critical indicator of the quality of life in a neighbourhood and affects the socio-economic outlook of the region significantly. Research has shown that in addition to the actual occurrence of crime, the perceived fear of crime is also a significant element that affects the quality of life measurement of a region [24],[25]. Coupled with the fact that a proportion of crimes (or micro-crimes) go unreported [26], and hence are not reflected in the regional quality of life records. We can present the use case where citizens, through our proposed architecture, can supplement the authoritative data by collection/submission of regional micro-crime statistics. This data then can be used to deliver informative services to the citizen for various purposes e.g. prototype scenario in next section.

  1. 1.

    Data sources and Platform Integration Layer

  2. (a)

    One of the major sources of data is through Open Data Initiative e.g. UK Open Data [27]. Many city councils and public agencies have started to publish data in both raw and processed, visual format. For example, crime and safety data profile of a local authority e.g. Bristol city council (Bristol Open Data initiative [13]) is a collection of related statistical indicators and can be downloaded as well as viewed in an online visual atlas. Such data is useful for various stakeholders in making decisions such as buying a house in a specific area. However, the aggregated data here is covered at ward scale and hence makes it difficult to associate individual aspects of crimes and safety to a specific spatial coordinates such as smaller streets. The following option (b) complements data collection by associating different events and citizens’ perception to specific locations. The data storage and processing in performed in a cloud-based infrastructure to dynamically scale resource provisioning for citizens queries.

  3. (b)

    User reported micro (and/or macro) security events or crimes e.g. through a desktop based visual interactive map or smartphone based application using GPS coordinates.

  4. 2.

    Data Acquisition and Analysis Layer

  5. (a)

    The local authority collected data is imported into data repositories. The import process can be automated if data is in a standardised format e.g. compliant to Open Geospatial Consortium (OGC) OWS [28] and ISO 19000 Series on geospatial data standards [29]. Otherwise manual extraction, transformation and loading (ETL) process and conversion to standardised formats needs to be carried out.

  6. (b)

    Citizen submitted data, through smartphone or desktop-based applications is also imported at this layer. A significant difference from local authority data is that this submission can benefit from collection of user context at the time of submission e.g. location, time of submission, proximity to reported crime, relevance to supported crime (observer, witness) etc. This context awareness augmentation can be built into the data submission tools used by the citizens. However, this approach may require additional data quality checks to improve accuracy and precision of the spatial data captured by citizens. Also, privacy concerns must be dealt by security layer.

  7. 3.

    Thematic Layer: The available data is harmonised and classified into specific thematic areas e.g. Crime & Safety class, `Bristol’ locality, temporal validity of 2001-2012 are examples of expected classification parameters. The INSPIRE data specificationsa play a major role in harmonising spatial data and reusing at various spatial scales.

  8. 4.

    Service Composition Layer

  9. (a)

    The collection, classification and harmonisation of the aggregated data at the lower layers provide a platform for utilising the data into workflow definitions for service composition. For example, administrators can specify the data fields which can serve as querying parameters for analysis or trigger points that can be used for generating notifications. For the use case being discussed here, these fields can be correlated with user context (through a user profile maintained in the `Management’ layer) such that applications can compare user preferences and specified parameters e.g. crimes and offensives related to dog attacks, during the evenings, within the past year.

  10. (b)

    Similarly, further data aggregation and analysis that can be carried out by using other data sources stored in the lower layers to generate datasets of higher complexity and granularity e.g. aggregating a crime profile with a `Child wellbeing- profile [2] to link crimes or offences that can affect children including road accidents, dog attacks, fights, etc.

  11. 5.

    Application Service Layer: The services and applications at this layer build upon the data collected and aggregated with user context information in the lower layers. Exemplar application include dissemination of the collected data to users in novel, interactive formats including visualisations, analysis services, periodic reports and automated triggers/notifications based on user context e.g. a user who frequents evening walks on a particular track may receive notifications of past and/or recent crimes in the vicinity of the track.

Proof of the concept

As a proof of concept we simulate a cloud-based implementation of selected components of the proposed framework. The purpose is to demonstrate the effectiveness of cloud-based infrastructures to meet Quality-of-Service (QoS) requirements in an urban environment. Based on the above use case, consider the scenario where a user is passing through an area in Bristol. The user would like to buy a flat in this area or start a small business. Such a user would be interested in information about the quality of life situation in that area (e.g. crime and safety, dog attacks, anti-social behaviour etc.). For this purpose, he opens up UrbanAwareness, a smart phone app provided by the City Council for just such purposes. The user selects Crime and Safety from the list of choices available and the app sends a query to the Council's servers along with contextual information; more specifically the coordinates of the user along with the data type preference. Moreover, the user also chooses to restrict the geographical radius about which information is presented to him. This radial preference is also sent by the app as part of the contextual information. For this simulation, we have chosen to focus on the Broadmead area of Bristol City Centre.

The contextual query

The query is encoded in ContextML [23] and sent to the contextual service where it is processed and the results returned to the user. A sample contextual query is shown in Listing ??.

In addition to the location and the radius preference of the user, it also contains a timestamp and an expiry limit for the information. This ensures that the location information is considered invalid after a reasonable amount of time as the user may be moving around.

Processing the queries

Processing the query involves retrieving all data pertaining to the city centre from the database. The data consists of reported incidents along with their description, location and date of occurrence. The incidents are filtered according to the user's preferences. In this case the Vincenty distance [30] from the user’s location to the location of each reported incident is calculated. All incidents that occurred outside of the user's preferred radius are filtered. The remaining incidents are sent back to the mobile app, where they are visualised on a map and presented to the user.

Calculating the Vincenty distance between two points is a compute-intensive task. From the contextual service provider's point-of-view, there may be many users issuing similar queries at the same time. For example, in a medium-sized city of 400,000 to 1 million inhabitants, it is not unreasonable to expect that 20,000 or more people may be using the UrbanAwareness app at any given time. Such a high volume of concurrent queries can easily overload any desktop system, degrading the QoS. This is evidenced by the results shown in Figure 5. This figure depicts high execution times of such queries on a single compute node. In order to maintain an acceptable QoS, it may be desirable for the local council to process the queries concurrently on a cloud infrastructure. This prototype explores the efficacy of using such an infrastructure. The methodology adopted involves measuring the net execution time when multiple concurrent queries are issued and processed for an urban environment. A mapping between various stages in the prototype application to specific layers in the proposed architecture is shown in Table 2. The prototype, therefore, comprises a cloud-based software-as-a-service.

Figure 5
figure 5

Experimental setup. Simulating the QoS for different scenarios.

Table 2 Mapping the prototype to the proposed architecture

Experimental setup

The experimental setup is shown Figure 6. The mobile application sends a query to the cloud infrastructure via the internet. The infrastructure consists of a single master node that also acts as the scheduler. This node is responsible for receiving queries from the mobile applications and dispatching them to the worker nodes. It is also responsible for receiving the results and communicating them back to the mobile applications. For these experiments actual crime data from the UK Police websiteb ( was used; in particular, data about all reported incidents within 1 mile of the Broadmead area. To simulate the cloud infrastructure, the SimGrid toolkit was used [31]. It allows users to simulate execution of various kinds of jobs on distributed cloud infrastructures. The infrastructure itself is described in terms of its topology, network connectivity and computing power. To accurately simulate execution, a job is described using its computing and data requirements. The unit for computing power in SimGrid is Floating-Point Operations (FLOPS) and for data size is bytes. The parameters shown in Table 3 were used for the cloud infrastructure configuration.

Figure 6
figure 6

Increasing number of queries and execution time in a two node cluster.

Table 3 Configuration parameters for simulated cloud infrastructure

To estimate the FLOPS required by a typical query of the previously-discussed nature, a sample query was implemented. This query took the user context, queried a database for reported criminal incidents and filtered the results based on the radial distance preference specified by the user. The FLOPS required by the application were then calculated using the following formula:

F = R × F × C × ? where F = FLOPS required by query R = Runtime of query F = CPU frequency in GHz C = No of CPU cores ? = CPU FLOPS per cycle per core

The prototype query was executed on a quad-core 2.2 GHz processor using the Sandy Bridge architecture [32]. To simplify the calculation, the query process was bound to a single CPU core. To the best of our knowledge, a CPU with the Sandy Bridge technology can perform 8 FLOPS per cycle per core. Based on this and the observed runtime of the query, it was calculated that each query requires approximately 11 GFLOPS to be executed when the user radius preference was set to 0.5 miles and approximately 13 GFLOPS for a radius preference of 1 mile. The numbers of required GFLOPS will significantly increase with larger sample area.


Using the aforementioned experimental setup, two sets of experiments were conducted. For both sets a simple Round-Robin scheduler was implemented [33]. In one set, the number of queries being executed on the cloud infrastructure were varied and the results are shown in Figures 7 and 8. For this set of experiments, a virtual cluster of 20 nodes was used. As can be seen, there is a significant increase in execution time as the number of queries increases. Such a delay in getting results significantly deteriorates the QoS for users who may consider it unacceptable. In the other set the number of queries remained constant (20000) while the number of nodes in the infrastructure were varied. The results for this are shown in Figures 9 and 10. In this case a sharp decline in execution time is observable at first as the number of nodes is doubled. However, the rate of decline decreases as computing power increases. This is due to the fact that as the number of nodes increases in the cluster, the cost of scheduling the queries for execution also increases. At a critical point (approximately at about 150 nodes), the time taken by the scheduler to schedule the first round of queries becomes greater than the time taken to execute a query. Therefore, at this point increasing worker nodes becomes meaningless since most of them sit idle for most of the time. Compared to these results, the relationship between total execution time and number of queries in the first set of experiments is linear because the number of nodes does not change. Thus, the scheduling time for the cluster remains constant, eliminating its influence.

Figure 7
figure 7

Query execution time for fixed number of cluster nodes and 0.5 mile radius area.

Figure 8
figure 8

Execution time for several queries using fixed cluster nodes and 1 mile radius area.

Figure 9
figure 9

Scaling cluster nodes for fixed number of queries and 0.5 mile radius area.

Figure 10
figure 10

Query execution time in scaling cluster nodes for fixed number of queries.

Based on the aforementioned results, it can be argued that a utility-based computing model is well-suited for such applications in which demand ebbs and flows with time. Such a model is used in clouds, where resources are provisioned as they are needed and utilised elsewhere when they are not. This way resources are utilised efficiently. Moreover, it is also possible to dynamically decommission and recommission resources as required, saving both energy and money. Clouds have the added benefit that they are invisible to the user. Given all these benefits, clouds are an attractive option for organisations wishing to employ distributed processing resources for similar urban applications.

Conclusion and future work

In this paper we have briefly presented a smart cities perspective and argued that it necessitates myriad of complex interactions between its different applications to generate intelligent information for smart urban governance. Further, we have proposed that Cloud computing can provide a suitable computing infrastructure for data storage and processing needs of smart cities applications. We also emphasise that, on one hand, end users e.g. citizens can collect data from their environment and, on the other hand, should be able to access contextual information from a smart cities based integrated information system with reasonable quality of service. The contextual information presents necessary information to end users based on their predefined preferences but it requires additional processing for contextual data preparation and information visualisation. In this regard, we have proposed a cloud based context-aware service framework and architecture. The context-aware components enable data processing in a specific application context and facilitate application layer to correlate information based on end users preferences.

The use case indicates that citizens’ participation for quality of life and in particular crimes and safety related data collection can provide precise location information but is subject to data quality checks for accuracy tolerance. This capability of the proposed system can be utilised to raise awareness about crime and safety situation of specific places but can also help in collecting data from citizens using smart phones and/or web-based interfaces. However, much concentration would be required to ensure data security and digital citizens’ privacy issues and QoS. Our proof-of-concept implementation of the proposed architecture indicates the effectiveness of cloud-based infrastructure for context-aware citizen services in smart cities. The prototype results show that in order to meet increasing number of user queries cloud-based dynamic resource provisioning can satisfy required QoS requirement. This is true especially when more citizens participate and/or area of interest for querying is enlarged (e.g. 1 to 10 miles). Our future work aims to develop a participatory application for data collection using sensors and smart phones and information provisioning using an open cloud-based infrastructure.


a INSPIRE Themes - Annexes:

b Contains public sector information licensed under the Open Government Licence v2.0. (

Authors’ contributions

ZK and SLK carried out the research in identifying the scope of this research. ZK developed the case for smart cities and citizen participation and SLK integrated context-based information development. ZK introduced the generic contextual framework and SLK applied it to the proposed architecture. Both applied the proposed architecture on a smart city use case. KS and ZK derived a scenario for prototype application. KS designed, described, implemented and evaluated the proof-of-concept implementation. He also presented and analysed the results of the evaluation. All authors read and approved the final manuscript.