# Decentralized Documentation of Maritime Traffic Incidents to Support Conflict Resolution
## 5 Application and Evaluation
### Application and Results  
To demonstrate the presented approach, the evaluation scenario was applied to the four phases presented in Section 4. In addition, it is described how the generated documentation of the mooring maneuver can be used in case of a conflict. 1. Initiate the documentation: Since the Port Operator wants to protect its port infrastructure, they are also responsible for defining when a traffic situation becomes critical and worthy of documentation. As already described in Section 4, for this purpose, a trigger needs to be defined that determines when a critical traffic event begins and thus the documentation is initiated. In the case of a mooring maneuver, a geographical region in front of the quay wall was utilized (c.f. Figure 8). Figure 7: Initial situation of the evaluation scenario. As a trigger, we defined a 50 m \(\times\) 200 m box in front of the Amerikahafen in Cuxhaven. If a Berthing Vessel enters this region, the documentation's initialization trigger is released. All vessels that request to berth in the port are informed that they have to participate in the documentation process when entering the port. Additionally, the IP-address of the port is also published at which a vessel has to report as soon as it enters the critical region. 2. Establish a communication channel: For establishing a communication channel between all participants, the Berthing Vessel is obligated to contact the IP of the Port Operator by using the prototype. Since the Port Operator and the VTS Operator know each other and the VTS Operator always supports the berthing documentation, the two participants are permanently connected via a P2P network. In this way, the Port Operator is connected to the VTS Operator and the Berthing Vessel. To enable the Port Operator and the VTS Operator to communicate with each other as well, the Port Operator broadcasts each other's IP addresses to all participants. In this way, each participant knows the IP of every other participant and can thus establish a P2P connection. 3. Derive a common trusted set of TSAs: Once a communication channel is established, participants use it to negotiate a mutually trusted set of TSAs. For this purpose, the participants share their preferred familiar TSAs in \(j\) iterations to all other participants via the P2P network. The negotiation proceeds according to the Negotiation Protocol (c.f. Figure 4), as outlined in detail in Table 1.  
* Iteration \(j=1\): According to the evaluation scenario (c.f. Figure 7), in the first iteration, each participant shares their first priority of trusted TSAs. Therefore, the Port Operator broadcasts TSA1 and TSA2, the VTS Operator broadcasts TSA3, and the Berthing  
\begin{table} \begin{tabular}{c c c c c} \hline \hline
**Iteration \(j\)** & **Port Operator** & **VTS Operator** & **Berthing Vessel** & **TSA Inters.** \\ \hline
1 & TSA 1, 2 & TSA 3 & TSA 4, 5 & \(\varnothing\) \\
2 & TSA 1, 2 & TSA 1, 2, 3 & TSA 4, 5, 6, 7 & \(\varnothing\) \\
3 & TSA 1, 2 & TSA 1, 2, 3 & TSA 1, 2, 4, 5, 6, 7 & TSA 1, 2 \\ \hline \hline \end{tabular}   
* Iteration \(j=1\): According to the evaluation scenario (c.f. Figure 7), in the first iteration, each participant shares their first priority of trusted TSAs. Therefore, the Port Operator broadcasts TSA1 and TSA2, the VTS Operator broadcasts TSA3, and the Berthing  
\begin{table} \begin{tabular}{c c c c c} \hline \hline
**Iteration \(j\)** & **Port Operator** & **VTS Operator** & **Berthing Vessel** & **TSA Inters.** \\ \hline
1 & TSA 1, 2 & TSA 3 & TSA 4, 5 & \(\varnothing\) \\
2 & TSA 1, 2 & TSA 1, 2, 3 & TSA 4, 5, 6, 7 & \(\varnothing\) \\
3 & TSA 1, 2 & TSA 1, 2, 3 & TSA 1, 2, 4, 5, 6, 7 & TSA 1, 2 \\ \hline \hline \end{tabular}   
* Iteration \(j=1\): According to the evaluation scenario (c.f. Figure 7), in the first iteration, each participant shares their first priority of trusted TSAs.