## 4 Implementation
### Bluetooth Mesh Fine-Tuning Segmented Messages  
The BLE Mesh protocol that makes use of the OEC protocol described in this article internally exhibits a 'flooding' behavior in its communications because it does not use routing tables. This makes it extremely efficient when transmitting small messages, but, because the designed protocol uses messages with a high payload to use libp2p, improvements need to be performed by making certain internal adjustments to the BLE Mesh protocol [42].  
First, it must be noted that the transmission of a single segment depends on the number of retransmissions and on the initial interval between retransmissions. Specifically, the average transmission of N segments can be determined using the following formula:  
\[T_{avg}=(10+(T_{int}+10)*T_{count})*N \tag{1}\]\(T_{count}\) determines the amount of extra transmissions for a certain message; if set to zero, it implies transmitting a single message, which implies sending a total of three packets (one for each advertisement channel), as long as the message does not need segmentation (i.e., it has a length of 11 bytes or less). \(T_{int}\) limits the duration in milliseconds of the sending interval of these extra messages, and \(N\) is the number of segments.  
Using 0 additional transmissions would result in the lowest message sending time of 10 ms. However, because segmented messages are sent in a maximum of 32 segments, the maximum transmission would be 320 ms if no additional messages were used. Moreover, for segmented messages, the transport layer must also be considered. It is important to note that segmented messages, unlike unsegmented messages, must always employ ACKs.  
Fortunately, Mesh version 1.1 allows developers to fine-tune segmented messages using several settings of the Segmentation and Reassembly (SAR) protocol used at the transport layer. One of the most important settings is the duration of the gap between two successive segments in segmented messages (both transmitting and receiving), which is determined by the following two formulas:  
\[\begin{split} Tx_{seg\_int}&=(Tx_{seg\_int\_step}+ 1)*10\\ Rx_{seg\_int}&=(Rx_{seg\_int\_step}+1)*10\end{split} \tag{2}\]  
\(Tx_{seg\_int\_step}\) controls the interval between sending two consecutive segments in a segmented message, and \(Rx_{seg\_int\_step}\) defines the segment reception interval step used for delaying the transmission of an acknowledgment message after receiving a new segment. By default, both variables are equal to 5 ms, implying a period of 60 ms between segment transmission/reception. When applied to a maximum of 32 segments, this corresponds to a time of 1920 ms, assuming that no further messages are utilized in the communication. However, by default, the number of additional resends is two, so the default periods would be significantly longer. These times greater than one second are quite similar to what is obtained when message sending is decoupled from the designed protocol, though buffers and caches are used to reduce the number of performed transmissions, so these times are not exact, but they provide an approximation. In this case the forwarding factor is more critical, since all the segments that make up the messages are forwarded.  
Taking into account the opportunistic nature of some nodes, they could benefit from adjusting the previously described times in order to minimize the use of the radio module and thus consumption, as a constant traffic flow is not necessary. However, it is necessary to determine an optimal adjustment for the previously mentioned time parameters, since a reduction in the intervals can lead to collisions and to the need for retransmitting the segment (by default, one retransmission is used for unicast addresses and two for multicast). In opportunistic environments with low data traffic, a minor change to these intervals can result in significant time improvements.