1 / 9

MN Status Option for Proxy Mobile IPv6

This document discusses the challenges encountered in PMIPv6 deployments regarding mobile node connectivity and flow mobility across multiple access technologies like WiFi and 3GPP. It identifies a critical issue where the connectivity status of a mobile node (MN) in sleep or idle mode is not communicated to the Local Mobility Anchor (LMA), hindering the successful transfer of IP flows. To address this, a new option for message exchange between the Mobility Access Gateway (MAG) and LMA is proposed, allowing for proper MN status representation and improved flow mobility management.

feo
Télécharger la présentation

MN Status Option for Proxy Mobile IPv6

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MN Status Option for Proxy Mobile IPv6 YangweiTu(ZTE) Nov. 2011

  2. Background • PMIPv6 deployments support communication using multiple access technologies simultaneously. • The PMIPv6 flow mobility draft specifies extensions for the traffic/IP flow to be moved from one access type to another. • The PMIPv6 flow mobility draft assumes a Mobile Node connectivity status of (1) connect or (2) disconnect. However some access technologies allow for a MN status of sleep or idle mode.

  3. Identified Problem • For flow mobility the LMA essentially decides the routing rules for the specific IP flow (s), however, • the connectivity status of a node in sleep (idle) mode for a specific is not carried to the LMA. • so that it is impossible to guarantee the flow mobility can be done successfully.

  4. Problem Illustration LMA WiFi 3GPP MAG 1 MAG 2 IP Flow X IP Flow Y MN

  5. Problem Illustration LMA WiFi 3GPP MAG 1 MAG 2 IP Flow X Sometime IP Flow Y is deleted, and the 3GPP access of the MN is changed to sleep or Idle mode MN

  6. Problem Illustration the IP Flow X is decided to move from WiFi to 3GPP,and LMA determines the 3GPP access is in connect mode(the PMIP tunnel exist) LMA WiFi 3GPP MAG 1 MAG 2 IP Flow X MN

  7. Problem Illustration LMA IP Flow X WiFi 3GPP MAG 2 can not establish the link to the MN, and the flow mobility of IP flow X is fail to complete. MAG 1 MAG 2 MN maybe move out of the coverage of the MAG 2 in Idle Mode, then the MAG2 will fail to wake up the MN MN

  8. Initial idea for addressing issue • A new option is defined for using it in messages (PBU/PBA) exchanged between MAGand LMA. • MN-status Length • 8-bit unsigned integer indicating the length in octets of the option,excluding the type and length fields. • Mobile Node status • The status of the mobile node attached from a specific accessnetwork, such as WiFi,WiMAX and 3GPP. Currently the value of the MNstatus can be as follow:1,connect mode,2,disconnect mode,3,idle/Power saving mode,4,reserved.

  9. Next steps • If the working group agrees that this is a problem and that the NETEXT resolve this issue.

More Related