A service discovery mechanism is basically identified as a combination of an application layer SDP and a particular network layer protocol; in other words, a SDP works on an underlying routing protocol. In contrast to the separate integration of application layer SDPs on routing protocols, cross-layer solutions have also been studied. They directly inject SDP capabilities into underlying routing protocols, e.g., . Although the cross-layer solution efficiently discovers services thanks to the direct interaction with the SDP and routing protocol, it loses the modularity of each protocol since SDPs are in turn tightly connected to a particular routing protocol. Regarding the service discovery for ITS, the separated solution is more feasible because VANETs for ITS will be developed and operated by several different stakeholders, which may use a number of different communication technologies [1, 2].
The selection of SDPs and underlying routing protocols is highly dependent on use cases. For instance, a UDP-based SDP with link-local scope IP multicast on traditional routing protocols can be used for small-scale static network [4, 6, 11]. For wide-area service discovery (i.e., in the Internet), SDP with overlay routing mechanisms on several intra/inter-domain IP routing protocols can be used . On the other hand, for mobile service discovery within a VANET, SDPs need to be integrated over ad-hoc routing protocols, e.g., [13–15]. This section therefore explores existing SDPs and ad-hoc routing protocols that can be used for VANET.
2.1 Service discovery protocols
SDPs provide a set of mechanisms such as service description language, discovery function, registration function, and application layer messaging mechanism . In this paper, we focus on these two functions and the messaging mechanism.
SDPs are basically composed of service consumers (SCs), service providers (SPs), and service directories (SDs). SPs manages the description of services (e.g., service type, service specific attributes, and communication endpoint of services), and possibly register their available service descriptions to SDs, while SCs try to discover services by asking SPs and SDs. SDs are centralized cache entities that act as services' directory. SDs may not be introduced to a small and/or mobile network, in which such a centralized entity does not fit the characteristics of the network, i.e., infrastructure-less mobile ad-hoc network. Depending on SDPs, each component can communicate with either unicast or multicast with/without SD: unicast is appropriate for wide-area service discovery, in which SCs need to discover a topologically distant service in the Internet. In this case, SCs and SPs normally use SDs to avoid broadcasting messages. On the contrary, multicast can be used for small, dynamic mobile network. In such a case SCs and SPs do not need to rely on SDs; they can directly propagate messages within a considered network. Consequently, IP multicast based SDPs fit the characteristics of VANET, in which most participating nodes are mobile and there is no centralized entity.
One of SDPs based on IP multicast is SLPv2 standardized by IETF [4, 5]. It introduces three system components: user agent (UA), service agent (SA), and optional directory agent (DA), which correspond to the above-mentioned SC, SP, and SD, respectively, in the context of this article. A UA issues a service request (SrvRqst), which contains a type and attributes of the requested service, to SPs or DAs. If a service managed by a SP and/or DA satisfies the request, the SP/DA returns a service reply (SrvRply), which contains a list of URL representation of all available services in the considered network, to the UA. UAs can either directly send SrvRqst to SAs via IP multicast if DAs are not installed. If DAs are available, UAs must send the request to DAs via unicast. SAs always return SrvRply to UAs via unicast.
While SLPv2 has originally used only one IPv4 multicast address to communicate with SAs, the modification specified by  has enabled SLPv2 to discover services over IPv6. It allows using multiple IPv6 multicast addresses assigned for each service (available address range is FF0x::1:1000/118 ). SAs join the multicast groups that correspond to their type of service. The multicast address is determined according to a hash algorithm, which generates a numerical value (0-1023: corresponds to the range of the allocated multicast address) from a service type's string representation. From the communication point of view, the benefit of this modification is to send SrvRqst to a specific subset of nodes that certainly manages a particular service using the IPv6 multicast group assigned for each service. If there are a large number of SAs that operate several different services, this modification can significantly reduce bandwidth usage.
Multicast DNS (mDNS) with DNS-based service discovery (DNS-SD) is also a well-known service discovery mechanism using IP multicast [6, 7], which supports both IPv4 and IPv6. It discovers services using the regular DNS message via IP multicast with introducing a special DNS domain '.local.' Available services are described in a list of DNS resource records, e.g., SRV, TXT, etc. Contrary to regular DNS, DNS servers (corresponds to SDs) are not necessarily used because nodes having mDNS/DNS-SD capability (corresponds to SPs) work as distributed DNS servers, thus DNS clients (corresponds to SCs) are able to directly communicate with SPs.
Unlike SLPv2 with the IPv6 modification, in mDNS/DNS-SD, only one IP multicast group is used for both request and reply (FF0x::FB in IPv6 ). All SCs inside a considered network are therefore able to listen SP's reply for a particular discovery request. It may help to discover services quickly as a kind of cache entry.
Thanks to the link-local scope IP multicast, each SDP can efficiently work in static and/or local networks. However, regarding the service discovery for ITS in VANET, they may consume significant bandwidth because they do not have any dedicated mechanism to handle geographical position but rely on regular IP multicast. The geographical position of SP is just one of attributes of services in the application layer SDP. Although they use IP multicast, SCs need to ask all SPs joining a multicast group within a considered network to discover a service, which is inside a specific geographical area.
2.2 Routing protocols for VANET
We classify routing protocols for VANET as two categories: traditional MANET routing protocols and the geographical routing protocol designed for VANET.
AODV  and OLSR  by IETF are representative routing protocols of the former category. These protocols dynamically construct network topology using flooding reactively or proactively, respectively. They enable to deliver packets with limited number of forwarding instead of broadcasting, so that a sender can deliver packets rapidly without wasting bandwidth. Each protocol has capability to take care of link failure due to nodes' mobility; their routing algorithm can automatically reconstruct the routing topology. However, although they can be applied to dynamic mobile networks, they do not satisfy the previously mentioned requirements of ITS applications: discover services according to geographical position. As we mentioned above, it may be possible to leave the geographical position handling to SDP, but in such a case sender nodes need to transmit service discovery packets to all nodes in the worst case.
On the other hand, IPv6 GeoNetworking is a reference specification of IPv6 operated over GeoNetworking developed by the GeoNet project, which conforms the C2CNet specification [2, 15]. C2CNet, specified by the CAR 2 CAR communication consortium , is a communication layer dedicated to car-to-car communications and is located between the network layer and the link layer. It supports geographical addressing and routing by means of encapsulation of IPv6 packet with a new C2C header containing geographical locations. Although the C2CNet layer exchanges packets without IP, the GeoNet project has defined how to transmit IPv6 packet over C2CNet ('IPv6 over C2CNet'). This is performed transparently to upper layers; In IPv6 GeoNetworking-enabled VANETs, each node is assigned a C2CNet identifier. When a node sends out an IPv6 packet, the C2CNet layer encapsulates the packet with the C2C header, which includes the C2CNet identifier of the IP next hop node. The C2CNet layer thereby makes the routing decision with the C2CNet identifier and nodes' geographical location.
IPv6 GeoNetworking has four types of geographical routing mechanisms: GeoUnicast, GeoBroadcast, TopoBroadCast, and GeoAnycast. Depending on the mechanisms, several types of the geographical destinations (GeoDestination) can be specified with geographical coordination and descriptions of a shape, such as a circle area with a particular radius of a geographical position. These geographical routing mechanisms are mapped to the IPv6 unicast, multicast, and anycast so that upper layer entities can transparently use these mechanisms without direct interaction between the C2CNet layer. Users therefore only need to support the legacy IPv6 stack.
In the GeoNet project, IPv6 GeoNetworking has been integrated with TUN virtual interface onto regular Linux, which enables to communicate with IPv6 and C2CNet without modifying the routing mechanisms in the kernel. IPv6 GeoNetworking-enabled routers at first receive regular IPv6 packets on their ingress (egress) interface, and pass the packets to the C2CNet module inside userland via the virtual interface. Then subsequent communication is performed in the C2CNet layer [19, 20].
From the point of view of service discovery, GeoBroadcast is the most appropriate mechanism to discover services inside a certain geographical area, because the GeoBroadcast mechanism delivers a packet to all nodes inside a specific GeoDesination via IPv6 multicast.