|
|
@@ -252,17 +252,9 @@ Currently, there seem to be a lack of solutions on detecting crowds or how busy
|
|
|
|
|
|
% It will be better to expand more on this
|
|
|
Sending data in raw binary was chosen as suppose to encoded with data interchange format such as JSON or XML due to bandwidth efficiency, computation time and simplicity of implementation with C.
|
|
|
-
|
|
|
- Checksum was required to ensure that all the values that were sent are correct as there was no way to ensure that the raw values were not corrupted.
|
|
|
-
|
|
|
ChaCha20 cipher was used for encryption with 12 byte nonce. This nonce size requires payload to be in multiples of 12 bytes blocks which is the reason for having "reserved" byte in payload.
|
|
|
|
|
|
- % what is message authentication code? Explain to reader since it was not mentioned before
|
|
|
-
|
|
|
- Message authentication code (such as Poly1305) was not used for simplicity reasons.
|
|
|
- % expand
|
|
|
-
|
|
|
- Instead, each IoT device has a unique built-in symmetric key. Device ID is not encrypted and used by server to lookup key dictionary and decrypt the payload. Checksum is also crucial in this case to ensure that used key is correct.
|
|
|
+ Each IoT device is designed to have a unique built-in symmetric key. Device ID is not encrypted and used by server to lookup key dictionary and decrypt the payload. Checksum is also crucial in this case to ensure that used key is correct, because when using an incorrect key resulting message would be "garbage" meaning that the message and CRC would not match.
|
|
|
|
|
|
Since this IoT device will not be sending any sensitive information and encryption may seem unnecessary.
|
|
|
However, this solution ensures that received information was authenticated.
|
|
|
@@ -280,9 +272,7 @@ Currently, there seem to be a lack of solutions on detecting crowds or how busy
|
|
|
|
|
|
|
|
|
% this section needs to be expanded. It is hard for a reader to follow. Mor information is required
|
|
|
- On IoT Device connects to local Access Point it sends data over WiFi to the cloud. The cloud contains four parts: connector, database, API and Grafana User Interface, general block diagram is shown in \autoref{fig:cloud}. Connector is responsible for recieving raw TCP packets, decrypting payload and sending formatted content to Influx Database. This database is chosen because of its time series nature, real-time monitoring and easy data analysis.
|
|
|
-
|
|
|
- \colorbox{yellow}{$\uparrow$ This probably should be moved to trade off section $\uparrow$}\\
|
|
|
+ The cloud contains four main parts: connector, database, API and Grafana User Interface, general block diagram is shown in \autoref{fig:cloud}. Connector is responsible for recieving raw TCP packets, decrypting payload and sending formatted content to Influx Database. This database is chosen because of its time series nature, real-time monitoring, rich documentation and advanced capabilities to analyse data.
|
|
|
Data from database is then used by Grafana UI for this platform administrators to perform analysis and monitoring. API block is a simple HTTP server that formats and serves all necessary data from database to user application, such as day predictions and current readings. These responses are formatted with JSON. This block also acts as a security layer so database could not be accessed directly.
|
|
|
|
|
|
|
