# An Architecture for Reliable Transportation of Delicate Goods
## 5 Workflow
### Merchandise Aggregation and Disaggregation
#### 5.3.1 Type (c) Topology
The BLE implementation should be prepared to automatically start the pairing and bonding procedure, exchanging the necessary keys to establish a secure communication channel (Figure 10--message 1.4 and 1.5). The approach used is the Just Works, without an explicit authentication, where the Short-Term Keys are exchanged as plain text (without any channel encryption), being susceptible to man-in-the-middle attacks. But by forcing the pairing to take place only when the devices are close reduces the possibilities for such type of attack. On the other hand, the relevant information is encrypted before being sent, so encrypting the communication channel is an extra security. The BLE standard provides more safer solutions, like Passkey Display, that requires more complex user interfaces (LCD and/or keyboard), or Out of Band (OOB) that uses technologies like NFC to implement a safer authentication. After the bonding, the central node sets the association state characteristic to true if the terminal is already in its whitelist. Otherwise, the characteristic is set to false (Figure 10  
Figure 10: Common part of the aggregation and disaggregation protocols. message 1.5.1). This state signals if the merchandise is already associated to the container, allowing the operator to request the disaggregation; or, if is not associated, allowing the operator to request the aggregation. On the next stage, the central node reads the information available on the terminal, mainly focused on the merchandise (Figure 10--from message 3 to 11). It starts by the Temporary ID used to index all the data related with the merchandise. Then it reads the Merchandise token, including the Data token with the existent non-compliances. It also reads descriptive information to supply to the operators, including information about device, the self-merchandise, current and next operators, contract conditions, LDD and EDD. Once all the values are read, the central device triggers a notification to the mobile app (Figure 10--message 12). That notification is a sign for the mobile app to read the Merchandise token, including the Data Token (Figure 10--message 12.1), and implement the same procedure used on the iteration protocol between mobile app and device (Figure 5), aiming to validate on the cloud service the information received from the central (that came from the terminal device) (Figure 10--from message 12.1 to 12.4.6). Once validated, the mobile app reads the remaining information to display it on the context of the container, including the association state (between terminal and central) (Figure 10--message 12.4.6) to enable one of the request options: merchandise aggregation or disaggregation. The next stage is specific of the aggregation or disaggregation protocols (Sections 5.3.2 and 5.3.3). Notice that the information exchange procedure between terminal and central, and between this one and the mobile app, are purposefully similar, normalizing the behavior, the implementation and minimizing the number of BLE services and characteristics.