IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: IEEE d base ideas and prototype implementation Date Submitted: Presented at IEEE session #48 in Jacksonville Authors or Source(s): Antonio de la Oliva (UC3M), Daniel Corujo (ITAv), Carlos Guimaraes (ITAv). Abstract: Requirements for group management in IEEE

2 IEEE presentation release statements This document has been prepared to assist the IEEE 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 The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws and in Understanding Patent Issues During IEEE Standards Development Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6http://standards.ieee.org/board/pat/faq.pdf

Motivation Recently group management has been identified as a missing feature from IEEE There is no way defined at IEEE of addressing commands to group of users: This feature is very useful for several use cases: –Relevant to this audience: Mesh sensor use case The aim of this TG will be to define Group Management mechanisms at the MIHF_ID level

Use Case 1: Mesh Network Mesh network is often characterized as self-forming and self-healing networks. Mesh networking is being used for AMI (Advanced Meter Infrastructure) managed by utilities During maintenance, controlled operation is needed, e.g., A specific group of smart meters are temporally moved to a specific network during maintenance for firmware update, etc. After maintenance, those meters are moved back to their original network. The network-controlled handover feature realized by MIH is quite attractive for this use case Maintenance PAN Maintenance After maintenance PAN under operation The group for maintenance may be independent of physical locations of smart meters.

Underlying mechanisms In order to take advantage of group management at the MIHF level, multicast transport must be supported by the underlying network. L3 multicast transport in the network connecting the different networks, for spread sensor meshes L2 multicast transport within a mesh This transport mechanisms is defined in IEEE MIH can use whatever is provided by the lower layers IEEE defines an structure that fits perfectly on IEEE Different entities can play the role of GC and become the PoS of the nodes receiving the commands

Requirements Group identifiers at the MIHF level, to form a specific group of nodes Mechanisms to distribute the group information to the terminals Distribution of the L2/L3 transport multicast mechanism to be used (e.g., the IP multicast address is going to be used) New primitives for the MIH Users to request the MIHF to join a certain group Capability discovery, MIIS new IEs Multicast message protection mechanism

Possible solution MIHF MIH_USER IP L2/PHY PoS IP/L2 Cloud MIHF MIH_USER IP L2/PHY MN 2 MIHF MIH_USER IP L2/PHY MN 1 Suppose MIHF_ID group mcast 1 already created and MN 1 and MN 2 joined it

Possible solution L2 MCAST MIHF MIH_USER IP L2/PHY PoS IP/L2 Cloud MIHF MIH_USER IP L2/PHY MN 2 MIHF MIH_USER IP L2/PHY MN 1 mcast 1 is transported through L2 multicast, MN 1 and MN 2 are in the same multicast L2 domain Association: mcast 1 _MIHF_ID L2 mcast address

Possible solution L2 MCAST MIHF MIH_USER IP L2/PHY PoS IP/L2 Cloud MIHF MIH_USER IP L2/PHY MN 2 MIHF MIH_USER IP L2/PHY MN 1 Messages sent to mcast 1 MIHF ID will be encapsulated as L2 multicast messages using L2 mcast address MIH message to mcast 1 MIHF ID L2 message to L2 mcast address Sending just one L2 message Reception by MN1 and MN2 due to multicast characteristics of technology

Possible solution L2 MCAST 10 MIHF MIH_USER IP L2/PHY PoS IP/L2 Cloud MIHF MIH_USER IP L2/PHY MN 2 MIHF MIH_USER IP L2/PHY MN 1 L2 mcast used to route the packet to the MIHF of nodes subscribed to the group. This is done by subscribing the nodes to L2 mcast multicast group, then the MIHF decapsulate the MIHF message and send it to the appropriate MIHF User Sending just one L2 message Reception by MN1 and MN2 due to multicast characteristics of technology Socket listening to L2 mcast Decapsulate packet and send it to MIH User listening to mcast 1

Possible solution L3 MCAST MIHF MIH_USER IP L2/PHY PoS IP/L2 Cloud MIHF MIH_USER IP L2/PHY MN 2 MIHF MIH_USER IP L2/PHY MN 1 mcast 1 is transported through IP multicast, MN 1 and MN 2 can be located in different networks as long as multicast IP transport is supported by them Association: mcast 1 _MIHF_ID IP mcast address

Possible solution L3 MCAST MIHF MIH_USER IP L2/PHY PoS IP/L2 Cloud MIHF MIH_USER IP L2/PHY MN 2 MIHF MIH_USER IP L2/PHY MN 1 Messages sent to mcast 1 MIHF ID will be encapsulated as IP multicast packets with destination address IP mcast MIH message to mcast 1 MIHF ID MIHF behaves as an IP layer user IP packet to IP mcast address Sending just one IP packet Reception by MN1 and MN2 thanks to standard IP multicast routing

Possible solution L2 MCAST 13 MIHF MIH_USER IP L2/PHY PoS IP/L2 Cloud MIHF MIH_USER IP L2/PHY MN 2 MIHF MIH_USER IP L2/PHY MN 1 This solution relies on the use of standard IP multicast mechanisms, the MIHF will assign a multicast MIHF ID to a multicast IP group and use standard IP mechanisms to route the packet to the members. Socket listening to IP mcast Decapsulate packet and send it to MIH User listening to mcast 1

Where are we now Following the ideas of this presentation a first draft of the primitives to join/leave has been sketched. A proof of concept implementation based on ODTONE has been performed and tested. The main conclusion is that the mechanism works And it integrates perfectly with underlying L2/L3 multicast standard mechanisms

L2 Demo overview MIH packets are sent to L2 broadcast address

L3 (1 multicast hop) Demo overview Multicast group used

Things we have detected require specification New IEs in the MIIS (we have already a proposal) In terms of MIH primitive formatting, commands related to link operations must have a link identifier, which is unique per node. How can we manage link SAP destination in multicast scenarios, where every node has a different link ID, but multiple nodes receive the message? Modifications to the state machine. What kind of answers are we expecting?