# Improving Recommendation Accuracy Using Social Network of Owners in Social Internet of Vehicles
## 4 The Proposed Model  
### Activity Life Cycle  
In SloV, the persons and vehicles are used synonymously, as persons are contained by vehicles for SloV functions, such as plan and navigation mechanisms (state changes). Each vehicle has a plan of weekly visits. Each of these visits is termed as an _activity_. An activity is constituted by three non-mutable and two non-mutable attributes. The non-mutable attributes are POI to visit, time of visit, and duration of the visit. The mutable parameters are the QoS of POI based on last visit and the outcome of the visit being happy or un-happy. Discrete-time simulation progresses in iterations. All vehicles get their turn at each iteration. When a vehicle is first created and is attached to a person, it is considered 'at home', represented by state '0'. The vehicle returns back to state '0' when it completes the life cycle of an activity. The vehicles at state '0' are checked by the \"outbound\" process.  
It takes into account the vehicle's last experience with the POI, when it intends to perform an activity at current time \(t\) to the same POI. If the vehicle was 'happy' on its last visit (which means that the quality offered by the POI was up to the expectations of the vehicle), it changes the state from '0' to '1'. The state otherwise remains '0'. The vehicle's expectation is a random static value assigned to each of the vehicles, ranging between 0 and 1. The outbound process also caters to the fact that the experience of a vehicle with a POI at the current instance might be completely opposite of the last experience. For example, a 'happy' vehicle based on previous experience might become unhappy during the current instance, or vice versa. Currently, if the quality \(q\) of the service provided by a POI is greater than or equal to vehicle's expectation value, the visit is considered as a 'Good Visit', and the vehicle would be termed 'happy'. Reciprocally, it would be a 'Bad Visit', and the vehicle would be termed as 'unhappy'. Lastly, we have labeled the visit that would not be performed due to bad experience of a vehicle last time and termed it as 'No Visit'.  
The \"go\" process would be executed when the vehicle is at state '1'. This process would let the vehicle move to current POI, and the state is set to '2'. After reaching the POI, the vehicle's experience will begin. The QoS provided by the POI would be logged (for future purpose), with a signaling error up to 25%. The signaling error is the difference between QoS provided by the POI and user perception. It can both be a positive or a negative difference, up to 25%. The \"inbound\" process, which is applied at state '2', lets the vehicle stay at the POI up to the required duration. When this duration is elapsed, the state is changed to '3'.  
The vehicles at state '3' initiate the \"communicate\" process to reset its state back to '0'. When a vehicle \(v\) encounters with vehicle \(w\) for the first time, it logs vehicle \(w\) using a tuple (time of discovery, total encounters so far, tie-type) with values (simulation time \(t\), 1, weak). The tuple values changes as the simulation progresses. When the total encounters exceeds by a threshold, the weak tie is changed to a strong tie. Figure 1 illustrates the schematic of the model's processes and states.