## 5 Service Discovery Mechanism
### SDM Message Format  
In previous works [8; 9], we showed the feasibility of this service discovery protocol, as a proactive push-based service discovery mechanism, integrated into the OLSRv1 protocol for MANET networks. We analyzed the service discovery mechanism in terms of messaging overhead, service discovery ratio (efficiency of the service discovery) and latency. The open lines were to extend the implementation of SDM messages and to integrate these messages into the new version of the OLSR protocol (v2), when it became an RFC standard (April 2014).  
As we have seen, the OLSRv2 protocol offers several advantages over OLSRv1, so it is to be expected that our service discovery protocol probably would reach better performance results when we integrate it into OLSRv2: (1) OLSRv2 is a modular protocol (it complies with RFC 5444 to define packet and message formats); (2) OLSRv2's header package allows one to easily discriminate whether one received packet has to be processed or retransmitted; (3) messages and packets in OLSRv2 could be extended with attributes that follow a TLV structure; and (4) to find the shortest path to a destination, OLSRv2 does not use the lowest number of hops metric between source and destination, but the link state metric. Moreover, in experimental tests, OLSRv2 has demonstrated a better behavior than OLSRv1 [52]: (1) the throughput in OLSRv2 is significantly higher than in OLSRv1, understanding throughput as the number of packets sent with success per time unit; (2) the average end-to-end delay (mean time that a packet spends to reach its destination) is less in OLSRv2 than in OLSRv1; (3) the average jitter is 50% less in OLSRv2 than in OLSRv1; and (4) the battery consumption in the nodes at the end of a simulation experiment, in the same scenario, is lower in OLSRv2. This is a very important issue, because usually, a MANET is composed of battery-powered nodes.  
To integrate the service discovery mechanism into OLSRv2, we define SDM messages as a TLV structure. In addition, we have made use of this new protocol design to improve our previous service discovery mechanism defined in OLSRv1: (1) the information in the routing tables is checked to know when a node leaves the network and so to delete the services offered by this node in the service table; and (2) we use the attributes VALIDITY_TIME and INTERVAL_TIME, already defined in RFC 5497, to configure the time to live parameter of a service in the network and the interval between service advertisements. We define INTERVAL_TIME as a user-configurable parameter, so depending on the working environment, this parameter could be higher or smaller.  
Then, we just have to define two new TLV structures: SDM_TYPE and SDM_DESCRIPTION. Each TLV structure has the format shown in Figure 4. We group all TLVs into one TLV block. A TLV block format is shown in Figure 5.  
Figure 6 shows the format of a TLV block with the four TLV structures needed for service discovery.  
Figure 4: Type-length-value (TLV) structure format.  
Figure 5: TLV block format.  
Figure 6: TLV block with four TLVs.  
This TLV block is added to HELLO and TC messages when needed: in the event that a node has to announce a service and/or in the event that a node has to retransmit the service announcement of another node. The packet format will be as Figures 7 and 8 show.