## 6 Application of Proposed Architecture
Public transportation vehicles are equipped with BLE beacons that detect the smartphone of a passenger in proximity and broadcast their identifiers to the smartphone. All the passengers have a ticketing app installed on their smartphones with a software development kit (SDK) that allows the collection and sending of smartphone sensor data along with contextual information. The raw passenger data are uploaded to a cloud-based database and transformed in an extract, transform, and load (ETL) process, as shown in Figure 2. By analyzing these data and using machine learning solutions, we have plannedto define the mode of public transportation and whether the passenger is inside the public transportation vehicle. A big challenge here is uploading the data to a cloud-based database that can have high latency because of network traffic or the size of data being uploaded to the cloud, high operational costs, as well as security and privacy risks. To avoid these problems, we can consider three solutions: one solution is performing all the analyses on the mobile phone directly. Another solution is transferring the data to IoT devices, in this case, a Raspberry Pi placed very close to the traveler's smartphone, for instance, inside the public transportation vehicle or at the public transportation stops, then the data will be analyzed on these IoT devices rather than transferring the data to the cloud. Our last proposed solution is implementing edge devices and servers at the cellular base stations. For our scenario, the IoT layer corresponds to the public transportation, the edge controller layer corresponds to the controller units of smartphones, the edge gateway layer corresponds to the smart gateways, the edge server layer corresponds to the centralized dispatching edge servers in certain cellular base stations, and the cloud layer corresponds to the cloud computing platforms. As the entity of the IoT layer, the smartphone is equipped with sensors, such as a rotation vector, sounds, a magnetic field, a gyroscope, etc., to collect various sensor data. Meanwhile, the smartphone is equipped with a variety of actuators to execute the instructions from the upper layers. As the entity of the edge controller layer, the controller units of smartphones are responsible for collecting and recognizing data from different sensors, performing some simple data filtering, data preprocessing and real-time threshold judgment, and transmitting instructions based on the judgment or decision from the upper layers to various action actuators of the IoT layer. For instance, when an error occurs, such as errors in the normal working of a smartphone or in collecting sensor data or full memory errors, the controller units must be able to provide ms-level feedback to the actuators to execute alarms. The edge gateway layer (in our scenario Raspberry Pis close to the traveler's smartphones) has more storage and computing resources than the edge controller layer and is usually responsible for collecting data from smartphones, preprocessing, fusing, and caching heterogeneous data, and performing corresponding heterogeneous computing. This layer is also responsible for transferring control flow from the upper layers to the edge controller layer. For example, when enough data are obtained from smartphones, Raspberry Pi will perform the steps of data processing, aggregating, and analyzing the data in the way of traditional big data analysis or emerging edge intelligence technologies. The  
Figure 2: Current cloud-based architecture of the automatic ticketing scenario. data analysis log will also be saved for future use. The edge gateway layer can monitor and optimize the parameters of different smartphones and identify errors in time. However, if the amount of data is more than the storage capacity of Raspberry Pi or more complex data analysis is required, the data will be transferred to the edge server layer.