3.1 Software architecture
The software architecture is based on three main components, Mobile Client, Data Server and Admin Server as shown in figure 3.1.
- Mobile Client is an Android application. Its main purpose is to collect iBeacon data such as RSSI-values and send it over to the data Server.
- Data Server is a Restful API (Application Programming Interface) that takes care of the data collected by Mobile Client application. Data Server is also responsible for business logic and calculation algorithm. Data Server have a UI, to show RSSI results of experiments.
- Admin Server is a Web Application with Restful API offer an administrator UI help to manage the iBeacons and smartphones information.
The idea of separating Data Server and Admin Server relies on future thinking. Hence Data Server purpose was only experimental and data analysis. We thought at some point the Data Server will end its job and the logic of the algorithm will be implemented directly in the smartphones. That way the smartphone will take care of all logic and returns its x and y position directly to Admin Server.
Figure 3.1: System Architecture. We show how Mobile Client connect once at startup of the application to Admin Server to get a list of all allowed devices and iBeacons. When the Mobile Client is done with collecting of iBeacon data, it posts our data to Data Server. When we start Data Server it connects to Admin Server to get a list of all allowed devices and iBeacon.
3.1.1 Mobile Client
The main purpose of Mobile Client Android application 3.2 is to collect iBeacon RSSI data. When the application starts up, Wi-Fi, Bluetooth and Location service turn on, because it is required, otherwise it will alert the user 3.3. This is required to update initial iBeacons (iBeacon fixed position, name of device etc.), data from Admin Server, sending and receiving data over Wi-Fi, receiving iBeacon data using Bluetooth. When a user enters experiment name and start collecting process, it will check for six conditions before collecting iBeacon data as described here and shown in process flow 3.5:
- Data-structure: the application will connect to the Admin Server to build a data structure of activated iBeacons with initial information such as fixed X and Y position of iBeacons, names of iBeacon, name of trackable object iBeacon and smartphones name if registered in system.
- Registered: it checks if a smartphone device is registered and is allowed by the Admin Server.
- Bluetooth: it checks if Bluetooth is receiving data from iBeacons as expected.
- Connected: it checks for Restful API connectivity.
- Collecting: smartphone starts collecting real-time data over 60 second.
- Send Data: when 60 seconds is over, it posts the collected data to Data Server.
Figure 3.2: Preparing page.
Figure 3.4: Mobile Client Android application. When the application is ready to collect data for each experiment, the Start-button appears automatically to the user. When the collecting time is over it will automatically post the data and give a pipsound at the end. In case one of the communication service like Wi-Fi, Bluetooth or Location Server is down, the user gets alert.
Figure 3.5: Mobile Client application process, shows how the application react while starting up until the user is ended with the experiment.
3.1.2 Data Server
Data Server is a Restful API. It receives iBeacons data from Mobile Client Application and store it on real-time database from RethinkDb 3.8 (an Open Source real-time database). Data Server stands for business logic and calculation algorithm. In addition, it offers a UI 3.6 to show graph of RSSI-results 3.7 for analysis purpose. The server works on a local machine in PitLAB.
Figure 3.6: Data Server UI. We built this system to deliver the tools we needed to make our experiment process smoother. It delivered data to Excel or showed RSSI- values of given experiment
Figure 3.7: RSSI samples. This is example of Data Server UI that shows RSSI-values of given experiment
Figure 3.8: Real-time Rethink Database administration UI. In our development we used Rethink Database, it has own API that is compatible with programming language such as Java, C#, PHP and many other programming language. This means it deliverers us a simple ReQL (RethinkDB Query Language) which we can use on different platforms
3.1.3 Admin Server
Admin Server is a cloud based Web Application which delivers an administrator UI 3.9 to manage all devices and iBeacons allowed to interact with the system. In addition, it offers all initial information about iBeacons, trackable object and Mobile Client.
Figure 3.9: Administrator UI. This is Admin Server UI which helped us adding new iBeacons or smartphones to our experiment.
3.2 Development challenges
In previous chapter under different smartphones challenge section 220.127.116.11, it is described how we had challenges with developing a Mobile Client.
We developed our Mobile Client on Google Nexus 5X smartphone with single iBeacon and it collected iBeacon data as expected. When we tested the same application on the smartphone we got from PitLAB (Motorola Moto E3) the we got different results. First, we thought our software had issues and we tried to re-write and improved our code, but we ended up understanding that it was a hardware issue rather than software.
Throughout the project, we had minor network issues in PitLAB. Unfortunately, we were not able to start our server with the given IP address. Luckily, the management of PitLAB offered us access to an internal Wi-Fi system that was reliable and stable.
3.3 Conclusion of this chapter
In this chapter it has been explained how our software infrastructure was implemented. At an early stage of development process of this project, the main idea was simple: how to collect iBeacon data and process it? This idea turned soon to require us to develop three main software solution: a Mobile Client, a Data Server and an Admin Server. All of them intercommunicating with each other. We have learned that developing software for iBeacon for one smartphone does not necessarily means it works for all smartphones.