# An Architecture for Reliable Transportation of Delicate Goods
## 5 Workflow
### Merchandise Transmission
* Characteristic 6-10: These characteristics allow to read information about a merchandise, namely information about: the device attached to the merchandise, current operator, next operator (if exist), Earlier and Later Deliver Dates and contract conditions. On topologies (a) and (b), the device information is the same of the characteristic one. * Characteristic 11: Authentication (write)--Allows to write the authentication token to activate the Closed Access BLE Services. The token is requested using the mobile app, for operations such as associate/dissociate merchandise to a container, or confirm the receipt of merchandise. Based on the requested operation, it is returned a token that, once authenticated, will turn on the related BLE service. * Characteristic 12: Used to get the association state among central and terminal devices on type (c) star topologies (see Section 5.3). Some BLE implementations do not trigger an event on the read-access operations, returning the value that is on the variable associated to the characteristic, which may not be the most up-to-date value. For these BLE implementations, it is necessary to previously guarantee that the associated variables are updated. On the present protocol, the update procedure could be triggered on the connection event (Figure 5--message 4.1). Figure 5: Iteration protocol between mobile app and device. On type (c) topologies, more than one merchandise is associated to the central device. The terminal devices periodically supply information to the central device and the smartphone is used to get information from the central device about the merchandises. For this reason, an iteration solution is supplied, namely, the Next merchandise (Figure 6a--characteristic 2). Whenever it is called, it passes to the next merchandise information record. The first time it points to the first record and, after the last record, it will produce an empty record (the following requested information will be empty). After the connection is established and the Open Access BLE Service is turned on, the mobile device will initiate the iterator (Figure 5--message 5) to process, one by one, all the merchandises associated to the device (devices on type (a)/(b)). Topologies are associated to a single merchandise, but devices on type (c) topologies can be associated to many merchandises). Taking advantage of the eventual opportunity to send information to the cloud server, for each merchandise, the mobile apps get from the device the correspondent token (Figure 5--message 7). The Merchandise token is produced using an asymmetrical encryption over a concatenation of the identifiers of device, merchandise, current operator, next operator and a temporary identifier of the merchandise. The last one is created by the device, for local and temporary use, to be supplied to the smartphone, avoiding exposing the system merchandise identifier used on the cloud server/device. It is with this temporary identifier that the mobile app references the merchandise on the iterations with device and cloud server. On the Merchandise token generation is also included the elapsed time since the start of the track, the data related with the non-compliances of the transport conditions and respective collection time. The encryption is done using the public key generated when the transport service was contracted. The public key follows the device and the private key is associated to the merchandise information on the cloud server. After receiving the Merchandise token, the mobile app will associate with it the GPS coordinates (Figure 5--message 8) and encrypt everything again using a second public key (Figure 5--message 9), producing the Mobile token that is sent to the central server in the cloud (Figure 5--message 10). On the server, the data is decrypted using the private key, validated and stored. The validation is done matching the values of the device (device, current operator and next operator identifiers) with the values on the server, plus checking  
Figure 6: BLE Services API. (a) Open Access BLE Service.