# A Service-Efficient Proxy Mobile IPv6 Extension for IoT Domain
## 3 Proposed Scheme
### Proposed PMIPv6 Protocol Extension  
The proposed protocol extension is based on the foundation of RSS, location information, and profile information of the target MAG identifier. The existing RSS-based PMIPv6 protocol extensions suffer from false handover initiation, longer handover latency, additional buffering, and high signaling due to RSS errors. Furthermore, existing location-based PMIPv6 protocol extensions may enhance some of the issues; however, to provide an overall efficient protocol, extensions are required. The proposed extension improves the efficiency of RSS-based PMIPv6 extension protocols. The working of the proposed solution is the following. To efficiently use the location information with RSS measure, the MAG will also communicate information regarding its location to the MNs attached to it. For this purpose, MAG is considered as static MAG and each MAG knows its coverage. Furthermore, MAG can communicate with its surrounding MAG and know their locations too. Therefore, after sharing its information with their corresponding MNs, MN will be able to find its distance from their MAG. Such knowledge will help the MN avoid false handover requests when RSS falls below the threshold. MN in this solution will monitor RSS in addition to the location of MAG. The handover process is improved by monitoring not only RSS but also the effective usage of MAG's location of resources involved in mobility. It is important to mention that the MAG location will only be exploited when an RSS error occurs. Such a procedure will ensure that if the RSS measure is normal, then the MN will roam without any service disruption. However, if an RSS event or RSS error occurs, the MN will check the location of MAG to decide whether the request for handover is to be made or not. In case of an RSS error, the location will not be appropriate, and MN will not request for handover initiation. Such decision-making will also eliminate false handover initiation problems. Furthermore, MN will only request for handover whenever handover is mandatory. For simplifying the handover process and to optimize the signaling efficiency by avoiding unnecessary communication among network resources, the MN will communicate information associated with its location using an L2 report when an RSS event occurs. It is important to mention that an RSS event is when the MN is properly located for handover, and an RSS error is when RSS becomes too low due to surroundings. After receiving the location information of MN, then pMAG will identify the target or next MAG that is expected to be the next MAG for MN. pMAG will send a De-Reg PBU message along with nMAG-ID to LMA. Upon receiving De-Reg PBU, LMA will start buffering packets and will keep sending the packets to pMAG. At the same time, LMA also sends an IHR message to the nMAG using the nMAG-ID. In a low latency scheme, LMA multicast the IHR message to surrounding MAGs. However, in the proposed location-based protocol extension, the LMA only sends the IHR message to the corresponding nMAG instead of surrounding MAGs. Such enhancement significantly reduces the signaling required. For forwarding the buffered packets, a tunnel is established between LMA and nMAG. When MN is detached from pMAG, then the LMA forward all the buffered packets to nMAG and, at the same time, LMA sends a De-Reg PBA message to pMAG. When the MN attachment is detected by nMAG, then it immediately provides services to the MN by sending the buffered packets received from the LMA. In the meantime, nMAG communicates with LMA via PBU message in order to inform the LMA regarding MN's arrival while LMA replies with a PBA message. Upon receiving the PBA message, nMAG communicates with MN by forwarding the Router Advertisement (RA). LMA forwards the packets destined for MN towards nMAG that are further provided to MN via nMAG in a regular fashion. The proposed solution will always ensure that MN will only request when a handover is necessary.