# An Architecture for Reliable Transportation of Delicate Goods
## 5 Workflow
### Merchandise Transmission  
The passage of merchandise between operators is marked by the transition of responsibility between them. It is a critical part of the process because the operator that delivers the merchandise wants to obtain official confirmation that it was delivered and without violations of the transport conditions. In turn, the operator that receives the merchandise wants to be sure that it is in good condition and that no violations of the transport conditions were committed. The idealized protocol aims to provide confidence to both parties, but also to those who may have hired them, whether they are other operators or the final customer. The process takes place in two stages: the registration of delivery to the next operator, and the registration of receipt by the next operator. The existence of these two procedures results from the fact that a single procedure would require the simultaneous presence of both operators and merchandise. However, it is quite common that an operator deposits the merchandise and performs the delivery register and, only later, the receiver of the merchandise comes to collect and register the reception. During the time in between the delivery registry to the receipt registry, it is still necessary to guarantee the transport conditions and responsibility. It may happen that the conditions are not the ideal, which does not mean that the transport conditions have been necessarily violated. Instead, it means that if that state is kept, the non-compliance will inevitably occur. It may also happen that it is acceptable to violate the transport conditions, but only for limited and well-defined periods. In either case, there is a timeframe for the merchandise to be collected. Otherwise, there will be unconforities in the transport conditions. In both situations--delivery and receipt of the merchandise, the protocol is implemented between the device and the mobile app (Figure 5). It is assumed that, when installing the app, there is an authentication process for the operator (company) and some  
Figure 4: Closed Access BLE Service—Setup. kind of access token is available on the app. Eventually, it may be necessary to renew the access token regularly. The common part of the protocol was designed to take advantage of all the possibilities to transfer data from the device to the cloud, even if not directly related to the delivery or reception of the merchandise. It may result from contractual reasons requiring more regular data updates besides the ones associated with the transition of merchandise between operators. Despite the mobile application being able to make the connection between device and server, the protocol is designed to minimize the information that the mobile device accesses, including information that can be used to vitiate data. To start the protocol, the device should be on advertise mode to allow the connection from the mobile. Type A devices are continuously advertising, but type B and C are not (it is necessary to push the advertise button). Once connected, the device turns on the Open Access BLE Service, that contains ten _read_ characteristics, two of type notify, and two others of type write, as defined on Figure 6a. A brief description of these characteristics follows:  
* Characteristic 1: Device info (read)--Supplies information about the device to which the mobile is connected. It is a representative characteristic, which in an applied context, may require to be broken down into several, depending on the information to be made available about the device. * Characteristic 2: Next merchandise (write)--it implements an iterator to access merchandise information and token, one by one. * Characteristic 3: Merchandise Temporary ID (read)--Supplies the merchandise temporary identifier. * Characteristic 4: Merchandise state (read)--Supplies the state of the merchandise (DEPOSITED/RECEIVED). * Characteristic 5: Merchandise token (read)--Allows to read the Merchandise Token pointed by the iterator, including the Data Token (non-compliance measures).