FIG. 12 illustrates an exemplary device and cloud architecture and how the data flows from the device to the actual database tables on the cloud. In one embodiment, the cloud platform could be custom, or it could utilize one of the well-known cloud platforms such as Google Cloud Platform, Amazon AWS, Microsoft Azure, or other custom platform. In another embodiment the device 1202 sends the sensor data, spectrum data, network characteristics data, and any other data available from the device such as Bluetooth network characteristics and any Bluetooth beacons that the device can sense around its area. There are multiple POST/GET methods that can be utilized to send the data to the server as also described in FIG. 11 where different protocols could be implemented and used. In yet another embodiment, the data is sent using the POST method 1218 as an HTTP request to the server. Once the Device API 1216 receives the data it runs through multiple checks to validate that the data is coming from a real device, it has not been altered, and that the server is not being attacked with malicious hits. In order to read the data, the decryption 1214 of the data is performed. The decryption happens using a key that is unique to the device. The keys are securely stored internally on the device and on the server and accessed only when decryption of the data happens. After decryption, the integrity of the received and decrypted data string starts with a checksum 1204 such as CRC16, CRC32, or others, if that passes, the length of the data 1206 is verified. For each transaction, there is a unique request ID that is generated and this checks if the request ID 1208 is different from the last transaction. In order mitigate Denial of Service (DoS) attacks, a duplication check 1210 is performed to make sure that the same string is not being sent over and over again by an unauthorized client, where SSL is not utilized. In this case any duplicate data is ignored, this check most likely will not occur as it would have failed the unique request ID check 1208. If all of the above checks pass, a last check 1212 of confidence is performed to verify that the incoming data from the device correlates with the configuration of the device. For instance, if the data is being sent every minute and the device is configured to send every 15 minutes, this raises a flag. The device is then checked to make sure that the update rate is set to the client's desired update rate of every 15 minutes. Device API also communicates back to the actual device hardware with response such as SUCCESS of reception of data, and/or ERROR ###, where ### is an error number corresponding to an issue that the device has experienced. Upon successful checks, the device API also responds 1220 to the device for “Successful Reception” of data or an error code showing the reason why the data reception failed. If there are any configuration changes on the device, those are also sent at this time. In addition to responding to the device, the device API sends all the verified data to a queue for further processing, computation and storage.