# Enabling Horizontal Collaboration in Logistics Through Secure Multi-Party Computation
## 5 Extensions and Future Directions  
As mentioned earlier, this paper aims at proving the feasibility and practicability of a secure realization of a solver for the CFDP as specified by [PERSON] et al. [3], thereby overcoming the trust-related challenges highlighted by [PERSON] et al. [4], and compare the efficiency and effectiveness of the modified heuristic to their results. However, we acknowledge that the modeling used in [3] (and thus also our paper) oversimplifies certain aspects of real-world large-scale collaborative transport networks. In the following we thus briefly outline some of the most immediate tasks in increasing order of complexity of integration into our solution, arguing that all but the last extension can be achieved without breaking the practicability claims made earlier. Firstly, in practice, many transport orders pose requirements regarding the _physical and operational conditions_. Such requirements can be related to temperature (e.g., refrigerated or frozen goods), humidity (e.g., protection from high humidity for electronic devices or paper), shock and vibration protection (e.g., fragile goods such as glass), or hygiene standards (e.g., related to food safety). However, especially when assuming sufficiently large numbers of orders per category in large-scale networks, this can trivially be realized in our solution by simply running an independent instance per requirement class. Furthermore, if hauliers wish to hide the types of orders that they provided to the network, a relatively cost-efficient single round of sorting of all orders can be performed in MPC prior to the independent execution of the instances. Secondly, _time management_ needs to be reflected more carefully. It is important to note here that our implementation already includes the concept of time in the sense that each truck has a variable nextAvailability that is increased by the driving time between different regions after each truck drive. However, this is not presented in Section 3 as \"time\" is neither included in the modeling in [3] nor is it part of the optimization criterion in Equation (1). Nevertheless, as the overall modeling considers regions rather than pick-up locations, our current internal modeling ignores journey times between different locations within the same region. This can be addressed in our heuristic at minimal costs by adding some fixed additional time period per order to model the time a truck needs to pick up different orders within a city. Investigating the feasibility of advanced routing algorithms using, e.g., [PERSON]'s algorithm [44] on complex maps without disclosing origin or destination, leveraging results by [PERSON] and [PERSON] [45], could be an interesting direction for future research. Thirdly, and closely related to the previous aspect, _time constraints_ of orders should be considered to accurately reflect just-in-time delivery requirements. While highly complex constraints might be hard to realize in MCP, a compromise already foreseen in our implementation is as follows. Each order contains an additional variable prio from some predefined domain, e.g., 1,...,10. Now, as an already available optional pre-processing step before entering our presented approach, all orders are sorted by prio, making sure that high priorities tend to be processed earlier. As potential future extensions, when selecting a truck to be filled next, the one with the lowest nextAvailability could be selected; similarly, when introducing an empty truck drive, the truck minimizing its nextAvailability plus the necessary journey time could be selected. Note that the computational overhead of this approach should be manageable, as all loops in Protocols 2 and 3 obliviously iterate over all trucks already in our current version to maximize confidentiality. Fourthly, external constraints should be added as future work.