## 3 Proposed Work  
The most important part of the proposed scheme is modifying the role of the trusted third-party server (TTP) that is responsible for the vehicle's and network entities' authentication and authorization. In the proposed scheme, the TTP server is allowed to multicast the authentication information to neighboring TTPs, as well as to the anchor point of the domain, i.e., the LMA, as shown in Figure 1. The authentication of vehicles involves following certain steps. In step 1, the access router, i.e., MAG, forwards the authentication request containing the vehicle ID and MAG ID to the TTP present in the local domain. It is the responsibility of the TTP to authenticate the vehicle. After authenticating the vehicle, the TTP server returns the authentication response (in terms of the vehicle profile, MAG profile) back to the MAG in step 2. During this, in step 3, the TTP multicasts the authentication information (vehicle and/or MAG profile) to the LMA present in the local PMIPv6 domain, as well as to the neighboring TTPs present in other PMIPv6 domains. The information shared with neighboring TTPs can be used in case of inter-domain handover. Thus, the TTP of the local domain works as a multicast server for the authentication process. The addition of the multicast server maintains the Layer 4 connection in both the intra- and inter-domain regions and allows for vehicle handover, which PMIPv6 did not initially provide. The solution will minimize multicast forwarding delays to provide seamless and fast handovers for real-time services. It will eliminate lookup costs and binding update delays at the BCE.  
Once the LMA has received the authentication information from the Trusted Third Part (TTP), the LMA can directly send the Proxy Binding Acknowledgement (PBA) message consisting of Vehicle-ID, MAG-ID and Home-network Prefix (HNP) to the MAG in step 4, without waiting for the MAG to send the Proxy Binding Update (PBU) message.  
Current handover techniques [9] do not account for the authentication cost when calculating the overall packet delivery costs in the handoff of VANET in PMIPv6. To assess the entire cost of packet delivery during handover, our proposed architecture considers the authentication cost during handover. Figure 2 shows the architecture for handoff during intra-domain and inter-domain handover that uses the IP multicasting described above. Here, three proxy mobile IPv6 domains, namely PMIPv6 domain1, PMIPv6 domain2, and PMIPv6 domain3, are considered. In each PMIPv6 domain, vehicles are connected to one of the MAGs, e.g., MAG1_D1, available via an access point, e.g., AP1_D1, which in turn are under the control of the topological anchor point of the domain, i.e., LMA1. The authentication and authorization of vehicles and MAGs are performed by the trusted third-party (TTP) server present in every domain. The role of the TTP server has been modified as described in Figure 2. Upon receiving the authentication request from an MAG, the TTP present in the local domain authenticates the vehicle by generating a vehicle profile and MAG profile. The TTP server then returns the authentication response back to the MAG, as well as to the LMA present in the local PMIPv6 domain. During the intra-domain handover, a vehicle changes its attachment from AP1_D1 of MAG1_D1 to the access point AP2_D1 of MAG2_D1 of LMA1. On the other hand, when a vehicle changes its point of attachment from AP2_D1 of MAG2_D1 to access point AP1_D2 of MAG1_D2, inter-domain handover occurs. The TTP server, upon authenticating the vehicle, multicasts the authentication information to the neighboring TTPs present in other PMIPv6 domains. Section 3.1 describes the message flow diagram of a vehicle when it first connects to domain, Section 3.2 explains the message flow diagram of a vehicle during intra-domain handover, and Section 3.3 describes the message flow diagram during inter-domain handover.