# A Service-Efficient Proxy Mobile IPv6 Extension for IoT Domain
## 2 Related Work  
Modern IoT such as 6G-enabled IoT are supported by efficient network-based mobility management protocols for resource efficiency [1; 13; 22; 23]. For adopting IoT in a modern solution, a number of associated IoT challenges, its feasibility, security issues, and architectures are analyzed for assessing the potential adaptation of IoT [24]. Experts suggest devising scalable, resource-efficient, feature-richer, and reliable solutions for improving the services' quality in the upcoming 5G/6G communication. Furthermore, for supporting IoT, a network-based mobility protocol is devised in which the point of attachment by their respective devices is updated frequently and provides better signaling efficiency during mobility [25]. For supporting the potential domains, Ref. [25] highlights a number of functional requirements and also provided various mobility management solutions that are made on the various requirement and the modern standards of 5G/6G. To meet such functional requirements, proxy mobile IPv6 protocol extensions are one of the most feasible candidates for enhanced mobility in the IoT [26; 27; 28]. Network-based mobility solutions such as PMIPv6 extension protocols have received much attention by avoiding the involvement of the MNs in their processes [16]. In addition, domain experts have put much effort to address and solve the aforementioned problems associated with PMIPv6 protocols [13]. As a result, a number of fast proxy mobile IPv6 extensions were proposed that minimize handover latency as low as possible [29]. The packet-loss problem is coped with the addition of a buffering mechanism to store the packets during the handover procedure. Overall signaling of the schemes is improved by eliminating the prediction of the expected resources to which the MN could roam [11]. Among the predictive schemes, there are many schemes that use the Received Signal strength (RSS) for predicting the initiating moment for handover. This scheme includes a smart buffering scheme [17], location-aware FPMIPv6, a low latency scheme [16], and FPMIPv6 [15]. An attempt made for handover efficiency and addressing the loss of packets during handover, FPMIPv6 works by predicting the next MAG (nMAG) in advance for the MN to move [15]. In this scheme, the MN identifies the target MAG when the value of RSS becomes too low. After predicting the nMAG, MN contacts the pMAG via the L2 report. Using the L2 report or L2 trigger, the MN informs the network about changing its location in the network. After receiving the information from MN, the message including handover initiation (HI) is sent from pMAG to nMAG while nMAG replies to the HI message with a Handover acknowledgment (HAck) message. For exchanging the buffered packets, a tunnel is formed between pMAG and nMAG. Furthermore, the attachment of MN is detected by nMAG and necessary signaling is performed for communicating Proxy Binding Update (PBA) and Proxy Binding Acknowledgement (PBA) between LMA and nMAG. Finally, the buffered packets and Router Advertisement (RA) are sent to the MN. For enhancing the handover latency, the process of authentication is optimized in an RSS-based PMIPv6 protocol [16] referred to as a low latency scheme. In such a scheme, based upon the occurrence of an RSS event, De-Reg Proxy Binding Update (De-Reg PBU) is sent to LMA from pMAG. LMA immediately starts storing packets and using the Immediate Handover Request (IHR) message, it contacts its surrounding MAGs. Upon the attachment of MN, the corresponding MAG reply to the IHR message based on MN's information. LMA responds to the pMAG with De-Reg Proxy Binding Acknowledgment (De-Reg PBA). LMA then forwards any stored packets to nMAG to MN. Another approach that directly addresses the packet-loss issue is the smart buffering scheme, which solves the problem by buffering packets during MN changeover. The smart buffering system operates by monitoring the RSS value and storing packets destined for MN when the value falls below a certain threshold [17].