ON THE CHALLENGE OF SERVICE RECOMMENDATION TO MOBILE USERS IN SMART CITIES: CONTEXT AND ARCHITECTURE

The industrial and academic interest of the research on mobile service recommendation systems based on a wide range of potential applications has significantly increased, owing to the rapid progress of mobile technologies. These systems aim to recommend the right product, service or information to the right mobile users at anytime and anywhere. In smart cities, recommending such services becomes more interesting but also more challenging due to the wide range of information that can be obtained on the user and his surrounding. This quantity and variety of information create problems in terms of processing as well as the problem of choosing the right information to use to offer services. We consider that to provide personalized mobile services in a smart city and know which information is relevant for the recommendation process, identifying and understanding the context of the mobile user is the key. This paper aims to address the issue of recommending personalized mobile services in smart cities by considering two steps: defining the context of the mobile user and designing an architecture of a system that can collect and process context data. Firstly, we propose an UML-based context model to show the contextual parameters to consider in recommending mobile services in a smart city. The model is based on three main classes from which others are divided: the user, his device and the environment. Secondly, we describe a general architecture based on the proposed context model for the collection and processing of context data.


INTRODUCTION
Nowadays mobility has become a major concern in cities mainly because of the problems generated by the excess of population such as traffic jams and parking problem. One of the main objectives of smart cities is to improve mobility and solve its problems which affect not only the quality of life of citizens but also the environment (pollution problems). In smart cities, mobility is improved by exploiting different mobility data of citizens to produce services. Among these services we find mobile personalized service recommendation systems that aim to recommend the right service to the right person in the right time. Personalized mobile service recommendation has become one of the main issues in the fields of artificial intelligence and machine learning (Liu, Guo, 2017) where the goal is to recommend the service that best fits the situation of a mobile user. To design personalized mobile service recommendation systems two challenges must be faced: defining the context of the mobile user and designing an architecture for context data collection and processing. The context designates all the elements that make it possible to clearly identify the situation of an entity. In literature, the most popular definition of the context was that proposed by Dey: "Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves" (Dey, 2001). The first step to recommend personalized mobile services in a * Corresponding author smart city is to define the context. In the early works,the context of a mobile user was focused on user's preferences and location. However, in the smart city era the notion of context became more complex because of the variety of information that can be obtained on the user and his environments using information and communication technologies available in a smart city (sensors, open data platforms, etc.). This makes the context definition step necessary where it is essential to sort the information that can be obtained on the user and his environment and identify which one is relevant for mobile service recommendation. There are several works (Boudaa et al., 2018, Gutowski et al., 2017, Ntalasha et al., 2016, Vahdat-Nejad et al., 2019, Badidi et al., 2019, Aguilar et al., 2018 that have focused on defining the context of mobile users in a smart city and on the designing of context models to show context parameters that influence the service recommendation process. However, these models are in most cases general and do not describe well the mobility of users in the city. The second step to consider in order to recommend personalized mobile services in smart cities is to have an architecture of a system that collects and stores context data. Context data (like temperature, user mobility data, urban traffic data, etc.) is massive, heterogeneous (images, videos, text, etc.), with great velocity and which can be retrieved from several sources (sensors, websites, etc.). All these features make context processing a difficult task hence the need for an architecture dedicated to context processing separated from the recommendation module. This paper aims to address these two steps that are the mas- Figure 1. General view of a personalized mobile service recommendation system terpieces to the design of personalized recommendations for mobile services in smart cities: context and architecture. On the one hand, we aim to create a context model that allows to clearly identify the situation of a mobile user and to properly describe his/her mobility. On the other hand, we aim to propose a general architecture that allows the collection and processing of the context defined in the proposed model. The literature works have dealt a lot with context processing architectures , Liu, Guo, 2017, our goal in this point is to propose a general architecture that can support our context model and covers the main stages explained in the literature. We also aim in this paper to present a comparative study between the most relevant works of these last years that have focused on context modeling. The comparative study will be done based on context parameters to consider in order to define the context of a mobile user in a smart city. The rest of the paper is organized as follows: in section 2 we present the area of personalized mobile service recommendation systems and we give a general description of its main related domains. In section 3, we, first identify the main context parameters to consider in the case of personalized mobile service recommendation in smart cities. Then, we present our context model, give the main literature works on context modeling and show their differences with our model. In section 4, we provide a general architecture for recommending personalized services to mobile users in a smart city based on the defined context model. Then we propose a scenario of interaction between a tourist and a mobile application that implements the proposed architecture, in order to show the use of our architecture in a concrete case. Section 5 presents a conclusion and future work.

PERSONALIZED MOBILE SERVICE RECOMMENDATION SYSTEMS: GENERAL OVERVIEW AND MAIN RELATED DOMAINS
Personalized mobile service recommendation systems represent a recent area of research that has emerged thanks to the development of communication and information technologies. Their goal is not to recommend any service but the most appropriate service given a situation of a mobile user. Figure 1 shows an overview of the main steps to recommend a personalized service. The key is to collect context data about the user first, to process this data to obtain the context of the user, and then to identify the service that goes best with the context. Mobile personalized service recommendation systems in smart cities involve several key areas ( Figure 2) that are related to each other. These areas are presented briefly in the following:

Mobile crowd sensing and computing
With the development of data collection technologies and wireless networking techniques, Mobile Crowd Sensing and Computing (MCSC) has emerged. The MCSC covers the processes of mobile data collection, storage and processing. Guo, et al. (2015) define the MCSC as "a new sensing paradigm that empowers ordinary citizens to contribute data sensed or generated from their mobile devices, aggregates and fuses the data in the cloud for crowd intelligence extraction and human centric service deliver". In recommending personalized mobile services, the MCSC improves the quality of context data collection process and the efficiency of the recommendation process for several reasons including: MCSC applications have the ability to infer high level knowledge from the collected data thanks to the diversity of contextual information that can be obtained from mobile devices (user preferences, environmental conditions, user activities, etc.) (Guo et al., 2015). MCSC makes recommendation systems development easier as deploying the sensors requires no technical or financial effort. MCSC applications directly use the present sensors in mobile devices, while static sensor networks are difficult to set up technically and financially as the installation of a smart urban traffic management system can require millions of dollars (Bawany, Shamsi, 2015). The mobility of mobile users provides unprecedented spatiotemporal coverage compared to static sensor networks (Guo et al., 2015). This allows the development of many novel sensing applications like environment monitoring applications (Ruge et al., 2013, Eisenman et al., 2010.

Context-aware computing
Context-aware computing focuses on the design of systems that can collect and process a broad range of context data. In the case of mobile users, context data (such as the user current position, his activity, his surrounding environment, etc.) is collected mainly from the user's smartphone and used after processing to recommend personalized services. The processing of context data involves dealing with several issues such as the volume and heterogeneity of the data (Bawany, Shamsi, 2015), the issue of uncertainty in sensor measurements (Nalepa, 2018), privacy and security issues (Beierle et al., 2018), dynamic adaptation of context (Nalepa, 2018), etc. These challenges have led to the design of systems dedicated only to context processing regardless of the recommendation system. In the recommendation of mobile services, the use of context-aware systems enhances the recommended services by providing more personalized recommendations (Mettouris, Papadopoulos, 2011).

Service recommendation systems
A service recommendation system allows proposing products or services to the user. The product depends on the field of application (films, documents, etc.). In the case of mobile users, the service is generally a point of interest or a route to take. Mobile recommendation systems typically focus on user request and preferences to recommend a point of interest, such as tour guides (Al-Omari, Al-Marghirani, 2017). In a smart city where it is possible to interpret and understand the situation of a mobile user well, the recommendation becomes more personalized and more suited to his needs, but also becomes more complicated to implement. To achieve such a recommendation, the service recommendation domain provides several machine learning techniques: Filtering-based content, collaborative filtering and hybrid filtering (Tran, 2007). These presented domains are very related to each other. The MCSC and the context aware computing make service recommendation systems more efficient, the context aware computing makes the recommended services more personalized (Mettouris, Papadopoulos, 2011) while the MCSC facilitates the acquisition of the data used to recommend mobile services. Also, the context-aware computing provides context awareness capabilities for different roles (users and developers) in MCSC systems and facilitates the interactions between these roles (Hu et al., 2014).

CONTEXT MODELING FOR MOBILE PERSONALIZED SERVICE RECOMMENDATION IN SMART CITIES
In this section we give the main parameters that we find relevant for describing the context. Then, we describe our context model and present a comparative study between our model and the most relevant models found in literature.

Main parameters for context modeling in smart cities
In this section, we propose a list of parameters that should be taken into account when defining the context of mobile users in an intelligent environment. These concepts are identified based on two points: (1) the need to properly describe the mobility of users, issue that has been little discussed in literature works. And (2) the main related works on mobile context modeling in smart cities (Boudaa et al., 2018, Gutowski et al., 2017, Ntalasha et al., 2016, Vahdat-Nejad et al., 2019, Badidi et al., 2019, Aguilar et al., 2018. Static profile of the user: each user has information or properties specific to him. The following static information is the most relevant to consider: a user identifier, age, sex, preferences, occupation, and the means of transport he uses to move in the city. Mobility status of the user: this dimension refers to how the user moves in the city: on foot, by a means of public or private transport. Knowing this information is essential in the recommendation process. For example, we cannot recommend a service that is far from the user location if we know that he is moving on foot. At a given moment one can know the mobility status of a user by analyzing his movements in time. Mobility history: represents places visited by the user over time. The analysis of mobility history data makes it possible to know the mobility status of the user, predict user's mobility, and detect new preferences (Ceselli, Premoli, 2018). Service History: the service history adds diversity to the recommendation process by avoiding recommending the same service several times to the user (Kang et al., 2015). Climate: services may change according to the climate. For example, if it rains we cannot recommend a distant service to a user walking on foot (Boudaa et al., 2018). User location: a service is recommended according to the user location (Ntalasha et al., 2016) . Some works consider the current location as well as the future location of the user (Ceselli, Premoli, 2018) in order to adapt the services even more. In these works, IA algorithms are used to predict the future location of the user. In our case we will only focus on the current location of the user at the time of the recommendation of the service. Time: we have two sub-dimensions of time: day of the week and time of the day. Habits or activities of the user may vary according to these two temporal criteria, which leads to different recommendations (Gutowski et al., 2017). Urban traffic: the use of urban traffic data is very useful for providing mobile services (Stathopoulos, Karlaftis, 2003). If a user is using private vehicle, the recommendation system can use urban traffic data to detect and recommend free parking spaces or paths where the traffic is the least intense. The device: the device has integrated parameters and functionalities like the battery level, a Wi-Fi connection, a list of downloaded applications, etc. Some of these factors influence the type of service to recommend and allow to know more information about the user (Gutowski et al., 2017).

Context model for a mobile user in smart cities
Hammoudi, et al. (2015) have discussed different approaches for the notion of context and proposed three requirements that any context model must satisfy: The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLIV-4/W2-2020, 2020 5th International Conference on Smart Data and Smart Cities, 30 September -2 October 2020, Nice, France Be sufficiently general to be used by different users centered mobile applications, Be sufficiently specific to cover the main contextual entities proposed in the state of the art of context-aware mobile applications, Be sufficiently flexible to allow an extension and to take into account new entities specific to a given application domain.
Based on these requirements and the parameters defined in section 3.1, we propose a mobility-centered context model for mobile service recommendation in smart cities based on Unified Modeling Language (UML). Figure 3 illustrates the model classes and their relationships. We chose UML to show well the relationships between the different classes. The rest of the subsection gives a general approach for the model and after that a description of the main classes.

General approach
The model presents the relationships between the parameters listed in section 3.1 that should be taken into account for defining the context of a mobile user in a smart city. The proposed context model extends the context definition of Day which considers the case where the application and the user interact explicitly and where the user requests services from his recommendation system. In addition to this case, we consider the case of implicit recommendation of services where the system captures and analyzes the context of the user and recommends (without user request) the most appropriate service according to context. This implicit recommendation case has already been considered by context models found in the literature (Hammoudi et al., 2015, Gutowski et al., 2017 but has never been as detailed as in our model. In addition to defining the "pushes service" and "requests service" relationships between the service manager (the service recommendation system) and a mobile user which has already done in the state of the art, we define the association classes "requested service" and "pushed service". This will subsequently identify the list of services requested by the user and the services implicitly offered to him. The comparison between the two kind of services (requested and recommended) makes it possible to evaluate the system's performance. If the services recommended to the user are close to the services requested by him, then the performance of the system is good. However, it is important to ensure that the user has no problems with implicit recommendations. The user may dislike notifications or want a service only when he requests it. A recommendation system can know if the user accepts implicit recommendations during the registration step, when the user gives his preferences. Also, the model takes into account the user feedback. It associates the MCSR view class which represents a context situation or a context view (user,device, environment conditions) to the context relevance assessment class which contains users' feedback about the recommended services. This will allow each context view to be linked to the feedback of the corresponding services. The analysis of the user feedback according to the context view allows the context view to be evaluated and consequently the user profile to be refined. Another important issue that must be considered in the use of our context model is the security issue. The proposed context model includes personal data that must not be accessed by anyone like mobility history or user's preferences. Designing a security mechanism in a system that uses the proposed context model is extremely important. In literature, many works have carried out on mobile data protection and privacy handling mechanisms ( (Beierle et al., 2018), (Wang et al., 2020)), anonymization (Wang et al., 2020) seems to be a promising method because it ensures identity privacy and data protection. Encryption (Wang et al., 2020) is also a promising method to achieve data confidentiality, but it can involve a high computation complexity which is not recommended for mobile systems because of energy consumption. Also, Eisenman et al. (2010) propose a sensing profiling method to ensure data security where data sensing rules are established such as where, when and which data is collected and the conditions to trigger data capture. The sensing profile aims to control and minimize data collection process to avoid attacks. The suite will describe the main context classes of the model. model that represents a context view (a user, his device status, environment conditions). A context view involves many context entities. Context Entity: represents a context parameter that influences the type of the recommended service. A context parameter can be the user, the device or the environment and it belongs to a context view. User: the user is a person moving in the city. He has a profile, evolves in an environment and uses a device to request or receive services. User profile: The user profile is important in the recommendation process. It gathers static information about the user (ID, age, sex, occupation, the means of transport he uses), his preferences, the history of the services he consumed as well as entities related to mobility (Mobility status, mobility history). Mobile Device : The mobile device is used by the user to capture context data from the environment. It implements a service manager that is a mobile application that uses the captured context to recommend personalized services to the user, either explicitly or implicitly. Environment: : represents conditions surrounding the user and his device that can influence the type of service to recommend. Environmental context includes: climate, time, location of the user and urban traffic. Context Relevance Assessment: : allows to record users' feedback for each context view in order to evaluate the context views.

Related works
In the literature, there are many works that have focused on context modeling for mobile service recommendation in smart cities. In this section we propose the main literature works of the last years with a comparative study with our proposed model. Gutowski, et al. (2017) present a context-aware mobile service recommendation system in smart cities. The system focuses on predicting the users' mobility to recommend personalized services according to their future locations. The work defines an AI module dedicated to the customization of services based on a context model. The context model considers several context parameters for service recommendation such as the environment (location, time, climate), the device, the user's activity and the user profile. Boudaa, et al. (2018) propose an ontology-based generic context model for mobile users in smart cities. The model considers four basic elements for context description: The user profile that contains information about the user (id, age, sex, preferences), the environment that includes external conditions (time, location, climate), the user's activity, and the user's device. Ntalasha, et al. (2016) Badidi, et al. (2019) propose an integrated framework for personalized mobile-cloud services recommendation. The work defines an architecture for the framework which has a client side on mobile devices responsible for locale adaptation of the recommended services and a backend cloud-based side for service delivery, composition and context adaptation. For the recommendation process, the framework uses the user profile, the device profile and user's environment. Aguilar et al. (2018) propose CAMEONTO, an ontology-based meta-model for context awareness in smart environments. The meta model is generic and not specified to a particular domain. text reasoning and context-aware services delivery. Table 1 establishes a comparative study between the presented literature works and our model. This study is based on the context parameters defined in 3.1. The literature works presented in this paper do not include mobility status, urban traffic and mobility history in defining the context of a mobile user. However, these parameters are important to properly describe mobility. The proposed works focus on location and time to describe mobility. However, location and time are not sufficient to fully understand the mobility of users. Even if we know the location of the user and time, if we don't know how the user is moving around the city (mobility status), what are his mobility habits (mobility history) and how is mobility around him (urban traffic) we cannot recommend a good service. Another important point in recommending mobile services is to consider the history of services as part of the context, something that the presented works in this paper do not do. As mentioned in 3.1 service history improves the recommendation process by adding diversity in the services to recommend.

CONTEXT-AWARE MOBILE SERVICE RECOMMENDATION ARCHITECTURE IN SMART CITIES
This section describes a general architecture for the service manager that deals with service recommendation process. The service manager captures the context using the mobile device and environmental sensors and retrieves the most appropriate service to the context from a service repository. Figure 4 shows a general view of the architecture components. The architecture is based on the main literature works of the last few years that have focused on context processing , Liu, Guo, 2017, but unlike the architectures proposed in these works, our architecture obeys to a context model and focuses on the collection of the context parameters mentioned in the proposed model. After the description of the architecture, we give a general interaction scenario between a system that implements the proposed architecture and a tourist to show the use of the architecture.

Architecture components
The architecture components are divided into two groups , frontend components located in the mobile device and responsible for context data collection, and backend components located in a remote server and responsible for context processing (machine learning, uncertainty handling, etc.), storage and service recommendation.

Frontend components
User manager: it allows to manage interactions with users, it has four functions: User' s authentication and registration. In user registration case, the user manager sends the user profile (static profile, preferences) and the device profile to the backend information system (NoSQL database) to be stored and notifies the frontend context manager to create a local representation of the user profile and the device profile in the frontend. Manage a user request. When the user requests a service, the user manager sends the requested service to the matching engine and notifies the sensing manager to collect environmental data for environmental context acquisition. Delivers the different services generated by the matching engine to the user whether it is a recommended or requested service. Sends the user feedback to the backend database.
Sensing Manager: controls sensing activities and makes sensing tasks abstract to the other components. The sensing manager collects environmental context data from the mobile device and from city sensors. From the mobile device, it collects data related to time, user location and climate conditions. The climate conditions data comes from the device temperature sensors and information provided by climate sensing applications installed in the device. From city sensors, the sensing manager collects urban traffic data using motion sensors and surveillance cameras, and also collects additional climate data from humidity and temperature sensors. After collection, the sensing manager sends the data to the frontend context manager. Frontend context manager: receives raw data from the sensing manager and performs preprocessing tasks on context data (Liu et al., 2017) to generate higher context information (like location, time, urban traffic quality and climate quality). The preprocessing tasks includes five operations: cleaning, interpretation, managing missing val-ues and impossible data combinations (e.g. sex=male and pregnant=yes) and normalization. After the preprocessing step, the frontend context manager uses the local representation of the user and device profiles to generate a complete context view and sends it to the matching engine for service recommendation. Matching engine: this is the service management component. It is responsible for finding the most appropriate service to the user from an external repository according to his context in the case of an implicit recommendation, and adapts the requested service by the user to his context in the case of an explicit recommendation. On the other hand, once a service is selected it returns the service to the user manager and stores the description of the service in service history. The matching engine can also request the history of service recommendations from the backend information system to ensure that the service about to be recommended has not yet been proposed to the user.

Backend components
Backend context manager: the backend context manager is responsible for knowledge extraction using machine learning algorithms (Liu et al., 2017). In literature many machine learning techniques are proposed to handle knowledge extraction: supervised learning, unsupervised learning, rule-based reasoning, fuzzy logic, ontology based and probability logic. The rules-based method is considered as the most suitable method to use (Liu et al., 2017) for its high precision. The backend context manager uses urban traffic data from city sensors to generate urban traffic quality models, recovers mobility history data from the backend database to identify users' mobility patterns, and extracts new users' preferences using context feedback and mobility history data. Each time new preferences are extracted, the backend context manager updates the preferences at the database level and at the frontend level. NoSQL Database: represents the system database, it stores information about services and contextual information about users. We chose NoSQL because context data is big data that can't be handled using classic database systems. In literature, there are many methods for modeling and storing mobile context data (key-value, markup scheme, graphical, object based, logic based and ontology based) and the key-value model is considered to be the most suitable method to use (Liu, Guo, 2017). For each user, the database stores his static information (id, age, sex, occupation, the means of transport he uses), his preferences, his mobility history and the history of the services he consumed. For each service, the database stores its type (recommended or requested), user feedback as well as the context view that triggered its recommendation. Link module: it is an intermediate component between the system database and the other components, it handles and interprets the requests of the different components. Its purpose is to control the access to the database in order to enhance the system security.

Case study
In this sub-section, we give an overview of the application of the proposed architecture in the field of tourism. We chose tourism because it is one of the major areas where personalized recommendations for services are necessary.
Informing tourists of points of interest in the city according to their context can be beneficial to improve their experience. A tourist arriving in a smart city who chooses to use a mobile application that implements the proposed architecture can benefit from information on the city according to his preferences (cultural events taking place in the city, information on points of interest for him like museums, historical monuments, etc.). After acceptance of the terms of use and installation of the application, the user communicates to the system his personal information (username, age, sex, possession of private vehicle) and his preferences (types of places he likes to visit, types of foods he likes to eat, etc.). This information along with the device properties is sent to the backend to be stored and also used by the frontend context manager to create a local representation of the user profile and the device profile in the frontend in order to facilitate access to information about the user and his device. From there, each time the user authorizes it, the system collects environmental data (location, time, climate) from the sensors of the mobile device. Then, if the weather conditions are favorable, the system uses this environmental data along with the static profile of the user, his preferences, his mobility history, and the current state of the device to find a service that matches the context using machine learning techniques (Filtering-based content, collaborative filtering, etc.). The recommended service is a place of interest for the tourist depending on the context (restaurant, hotel, historical monuments, beach, cafeteria, etc.). Once a service has been chosen, the system consults the history of the services consumed by the tourist to ensure that the service that is going to be recommended is new. Outside the recommendation phase, the system uses the context history and the mobility history to extract new preferences and design mobility models using rules-based reasoning to further personalize the recommendations based on user's needs and habits.
In the case where the tourist uses a private means of transport, the app can use the urban traffic quality to provide itinerary services. The app collects urban traffic data from motion sensors installed in roads, open data platforms and city web sites and analyzes this data to make urban traffic models that predict traffic quality per time and location. The system can consequently provide users with the best itinerary according to their location, destination and preferences. Also, during the collection and processing of mobility data, security mechanisms will be applied in order to protect data and identities. Anonymization (Wang et al., 2020) can be used when the data is sent to the backend in order to make user data difficult to distinguish. Encryption (Wang et al., 2020) can also be applied in the frontend to protect data confidentiality. Also, the sensing manager can adopt a sensing profile (Eisenman et al., 2010) to minimize communication with the sensors and therefore minimize the risk of attack.

CONCLUSION
In this paper, we proposed a context model for personalized mobile service recommendation in smart cities. The proposed model has two characteristics lacking in the models proposed in literature works. First, it describes well the mobility of users in the city by considering the following parameters: mobility history, urban traffic conditions and mobility status. Then, it considers the history of services consumed by the user as a context parameter. Considering the service history in the recommendation process allows to add diversity in the recommendation of services by avoiding recommending the same service many times. The model takes also into account the user feedback which is a very important means for refining the user profiles and improving the recommendation process by evaluating the corresponding context view. Also, we proposed in this paper a general architecture for context data collection and processing. The architecture focuses on the collection on the context parameters described in the context model. We also presented a general use case of the architecture in the field of tourism where we describe a scenario of interaction between a mobile application that implements the proposed architecture and a tourist who wants information on the different services in a smart city.
In the future, we will test the feasibility of our architecture by creating a mobile application for recommending tourist services. The app will be based on the architecture and the scenario explained in the previous section. We will also discuss the security issue in more detail by identifying and implementing the security measures that should be taken into account in a mobile service recommendation system in a smart city in order to ensure data and identity privacy.