IEEE 802 21 MEDIA INDEPENDENT HANDOVER DCN Title

  • Slides: 6
Download presentation
IEEE 802. 21 MEDIA INDEPENDENT HANDOVER DCN: Title: Required changes to standard. 21 primitives

IEEE 802. 21 MEDIA INDEPENDENT HANDOVER DCN: Title: Required changes to standard. 21 primitives for multicast usage Date Submitted: November, 2012 Authors or Source(s): Daniel Corujo (ITAv), Antonio de la Oliva (UC 3 M) Abstract: This document describes the changes required in th standard MIHF protocol to be able to use multicast messages 21 -12 -0058 - Mu. GM

IEEE 802. 21 presentation release statements This prepared to assist the IEEE 802. 21

IEEE 802. 21 presentation release statements This prepared to assist the IEEE 802. 21 Working Group. It is offered This documenthas hasbeen prepared to assist the IEEE 802. 21 Working It is as a basisasfora discussion is not binding contributing or offered basis for and discussion and is on notthe binding on theindividual(s) contributing organization(s). Theorganization(s). material in this document is subject to change in form content individual(s) or The material in this document is and subject to after further study. The contributor(s) reserve(s) the right to add, amend or withdraw change in form and content after further study. The contributor(s) reserve(s) material contained herein. the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to theto. IEEE to incorporate material Thecontained contributor grants a free, irrevocable license the IEEE to incorporate in this contribution, and any modifications thereof, in the creation of an IEEE material contained in contribution, andname any modifications thereof, in the Standards publication; to this copyright in the IEEE’s any IEEE Standards publication creation of an IEEEinclude Standards publication; to copyrightand in at thethe IEEE’s even though it may portions of this contribution; IEEE’sname sole any IEEE Standards publication even though it may include portions of this discretion to permit others to reproduce in whole or in part the resulting IEEE contribution; and at the IEEE’s sole discretion to permit others to reproduce in Standards publication. The contributor also acknowledges and accepts that this whole or inmay part Standards publication. The contributor contribution be the maderesulting public by. IEEE 802. 21. acknowledges that this contribution be 6 made by Thealso contributor is familiarand withaccepts IEEE patent policy, as stated in may Section of thepublic IEEE-SA IEEE 802. 21. Standards Board bylaws <http: //standards. ieee. org/guides/bylaws/sect 6 -7. html#6> and Understanding Patent Issues IEEE Standards Theincontributor is familiar with During IEEE patent policy, as. Development outlined in Section 6. 3 of http: //standards. ieee. org/board/pat/faq. pdf> the IEEE-SA Standards Board Operations Manual <http: //standards. ieee. org/guides/opman/sect 6. html#6. 3> and in Understanding Patent Issues During IEEE Standards Development http: //standards. ieee. org/board/pat/guide. html> 21 -12 -0058 - Mu. GM

Multicast Operation of Existing 802. 21 commands • Existing 802. 21 commands make use

Multicast Operation of Existing 802. 21 commands • Existing 802. 21 commands make use of the request/response mechanism • Under 802. 21 d, if such messages are used with multicast MIHF_IDs as destination, there will be a separate response message sent by each node towards the Po. S

Multicast-able 802. 21 messages • Proposal A: Identify which messages make sense to be

Multicast-able 802. 21 messages • Proposal A: Identify which messages make sense to be supported in multicast environments – Rule 1: All commands sent from the Po. S (i. e. , not from the MN or the Po. A) are multicast-able – Rule 2: Commands specifying actions in the destination (i. e. , MIH_Get_Parameters and MIH_Configure_Threshold), need to have a generic TARGET LINK IDENTIFIER instead of the current link ID of a specific node

Multicast-able 802. 21 messages • Features: – In this way, only messages which make

Multicast-able 802. 21 messages • Features: – In this way, only messages which make sense to be used under multicast environments, are allowed to do so – Generic target link ID, allows new scenarios to be conceived • Send link commands to specific technologies for nodes in a group • Send link commands to all interfaces in all nodes belonging to a group

Changes to MIHF protocol state machine • Some minor changes to the protocol stack

Changes to MIHF protocol state machine • Some minor changes to the protocol stack are required in order to process multiple replies to a request in an independent way