IEEE 802.21 MEDIA INDEPENDENT HANDOVER

DCN: 21-10-0061-01-srho

Title: IETF NETEXT Overview and Relationship with 802.21c

Date Submitted: March 16, 2010

Presented at IEEE 802.21 session #37 in Orlando, FL

Authors or Source(s):

 Juan Carlos Zuniga (InterDigital)

Antonio de la Oliva, Carlos Bernardos (UC3M)

Telemaco Melia (Alcatel-Lucent)

Abstract: Overview of IETF activities in the NETEXT group and the relationship with current 802.21c activities

121-10-0061-01-srho

2

IEEE 802.21 presentation release statementsThis document has been prepared to assist the IEEE 802.21 Working Group. It is offered as a basis

for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.

The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.21.

The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws <http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf> 

21-10-0061-01-srho

IETF NETEXT Overview and Relationship with 802.21c

21-10-0061-01-srho

Proxy Mobile IP

• Proxy Mobile IP standardized in NETLMM– Provides roaming within a

PMIP domain without changing IP address

– It provides also a limited multi-homing support to multi-mode devices

• Initial assumption• Changes in the IP stack are

undesirable

• How do we provide more advance features while using PMIP, without changing the IP stack?– Inter-access handover– Flow mobility

21-10-0061-01-srho

NETEXT

• Working on PMIP extensions:• Localized routing• Bulk refresh• LMA redirection• Radius Extensions • Hiding access technology changes from IP

21-10-0061-01-srho

Hiding L2 changes to the IP stack• Layer 2 techniques hiding the actual physical interface

being used by the IP layer– Link layer support– Logical interface– Layer 2.5

• Assumption: an IP layer interface is able to simultaneously and/or sequentially attach to different MAGs

• Applicability statement– Draft bernardos– http://tools.ietf.org/html/draft-bernardos-netext-ll-statement-01

21-10-0061-01-srho

Link layer support• Certain technologies already have the ability of hiding physical

media changes– IEEE 802.11abg– IEEE 802.3– UMTS-R8– WiMAX?

• What can be hidden:– Changing rate/modulation in a transparent way for upper

layers– Changing point of attachment within WDS– Inter-RAT handover (GERAN/UTRAN/E-UTRAN)

21-10-0061-01-srho

Logical Interface

• Solutions bounding multiple interfaces so they appear to the IP layer as a single interface

• Application sockets are bound to this logical interface

• It allows:– Simultaneous use of

multiple interfaces– Fail over mechanisms– Simultaneous attachment to

different medias

• One Interface to rule them all!

TCP/IP

APP 1APP 1 APP 2APP 2 APP 3APP 3

Logical InterfaceLogical Interface

WiFiWiFi WiMAXWiMAX 3GPP3GPP

21-10-0061-01-srho

Active TCP/IP InterfaceActive TCP/IP Interface

Layer 2.5

• Single Radio Handover application

• There is only one active interface at IP layer

• 802.21 can help PMIP when dealing with inter-access technology changes TCP/IP

APP 1APP 1 APP 2APP 2 APP 3APP 3

WiFiWiFi WiMAXWiMAX 3GPP3GPP

TCP/IP TCP/IP

IEE

E 802.21

IEE

E 802.21

21-10-0061-01-srho

Intersection between NETEXT and IEEE 802.21

• 802.21 can help PMIP for inter-access technology handovers

• At the moment PMIP does not specify how the link layer information can be known by the PMIP nodes

• 802.21 + RFC5677 can provide the required link-layer information over a L3 transport

• A solution would greatly benefit the single radio handover work being carried out by 802.21c

21-10-0061-01-srho

Intersection between NETEXT and IEEE 802.21

• Possible solutions:

• PoS at MAG• e.g.http://tools.ietf.org/html/draft-bernardos-netext-pmipv6-mih-01

• PoS at LMA

21-10-0061-01-srho

PMIP+IEEE 802.21 (Assuming 802.21-2008)

• IEEE 802.21 can be used to fill the parameters used in the PBU (PoS at MAG)

– MN-Identifier• MIH_N2N_HO_Commit.indication contains MIHF_ID

– Handover Indication• MIH_Link_UP contains OldAccessRouter and

IPRenewalFlag• HI can be computed from above

– Link Layer Identifier• MIH_Link_UP contains LinkIdentifier parameter

– Access technology type• MIH_Link_UP contains LinkIdentifier parameter

21-10-0061-01-srho

PMIP+IEEE 802.21 (Problems in 802.21-2008)

• Main issues:• MIH_Link_UP is not reaching the new MAG

• It requires registration and subscription but it cannot be done when the MN arrives to the new PoA

• It requires the nMAG to talk with the pMAG in order the nMAG to subscribe to MIH_Link_Up before it moves

21-10-0061-01-srho

PMIP+IEEE 802.21 (Future 802.21c?)

• PoS at LMA?

• Maybe it is easier to manage all the mobility of the user in one central point, the same for IP and .21– One PoS located in the LMA– Just one subscription is required for all interfaces and maybe

flows

• Issues: Communication not allowed on nMAG– Use MIH_Link_Going_Down instead of MIH_Link_Up?– Preauthentication?– Change the way MIH_Link_Up can be sent?

21-10-0061-01-srho