# A Context-Aware Edge Computing Framework for Smart Internet of Things
## 4 Use Case Scenario: A Smart City Parking Space Detection  
In this section, we provide a real-world use case scenario portrayed in a smart city to indicate the applicability of the CONTESS framework and describe its functionalities with a step-by-step process. In modern cities, finding parking spaces is a huge problem due to the higher population density in small areas. Drivers spend a significant amount of their time trying to find a parking space. A huge amount of money is wasted on parking fines and overpriced parking lots. Parking space management is an essential part of any smart city environment. It helps reduce congestion, pollution, conserve resources and provide convenience for residents. Existing parking management systems either use car counters positioned in park gates, or use physical sensors deployed under cars in parking spaces. Both methods require higher construction costs for big parking lots. Employing the already deployed video surveillance cameras, normally used for security, to cover huge areas offers a real-time and accurate service for very low costs [30]. Numerous applications based on image analysis for vacant parking space detection were proposed in the literature such as [30; 31]. In a typical cloud-based video analytics systems, a middleware is introduced to manage the heterogeneous connected devices and offer some preprocessing capabilities. The video data still need to be fully processed in cloud servers. For a large city, this puts tremendous load on the communication infrastructure and consumes large computing resources, therefore, we propose to use the CONTESS framework to tackle this issue. Assuming that the deployed surveillance cameras are connected to a nearby edge server, using wired or wireless data connections, the CONTESS framework is run (see Figure 7). When a driver approaches their destination, their navigation device issues a request to the cloud stating that they need a parking space. The cloud server combines their location with a set of requirements and send it to the nearest CONTESS server. These requirements can contain descriptions of events to look for, such as when a car is leaving an empty spot. Figure 6: Selective Sensing Module Architecture. Assuming there are no available parking places, we recognize two possible scenarios. Firstly, the nearby parking lots are already equipped with surveillance cameras. In this situation, captured video data from multiple cameras are transmitted to the CONTESS framework and received at the level of the context acquisition module. The video data are first standardized into a specific predetermined data format. The modeling module receives preprocessed video data and extracts moving object coordinates according to the requirement descriptions provided by the cloud servers. The extracted low-level context is represented (i.e., modeled) in the form of a Markup model (e.g., XML) and sent to the reasoning module. The reasoning module attempts to extrapolate the moving object coordinates into a full path (i.e., high-level context). It also tries to fuse contexts the provided from different angle cameras to produce a more complete context. The context is validated against a set of logical rules to filter-out unusual contexts such as those regarding objects moving in paths which are not normally associated with a vehicle. For example, a human or a bird could generate paths that are impossible for a vehicle. A high-level context is analyzed using a selection model (SM) in the selection module. The SM takes a feature vector consisting of the produced context markup model as input. It is trained in the cloud servers to classify feature vectors into a positive event (i.e., car leaving empty spot) or a negative event. Data related to positive events are selected and sent to the cloud servers implemented for scene analysis, which then measures the available spots using more complex methods.