1. IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-12-0029-00-0000 Title: IEEE 802.21d base ideas and prototype implementation Date Submitted: Presented at IEEE 802.21 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 802.21 21-11-0163-01-00001

2. 2 IEEE 802.21 presentation release statements This 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 and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf> 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

3. Motivation Recently group management has been identified as a missing feature from IEEE 802.21 There is no way defined at IEEE 802.21 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 21-11-0163-01-0000 3

4. 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. 21-10-0042-00-00004 Maintenance PAN Maintenance After maintenance PAN under operation The group for maintenance may be independent of physical locations of smart meters.

5. 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 802.15.5 MIH can use whatever is provided by the lower layers IEEE 802.15.5 defines an structure that fits perfectly on IEEE 802.21 Different entities can play the role of GC and become the PoS of the nodes receiving the commands. 21-11-0163-01-00005

6. 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 21-11-0163-01-00006

7. Possible solution 21-11-0163-01-00007 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

8. Possible solution L2 MCAST 21-11-0163-01-00008 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

9. Possible solution L2 MCAST 21-11-0163-01-00009 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

10. 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

11. Possible solution L3 MCAST 21-11-0163-01-000011 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

12. Possible solution L3 MCAST 21-11-0163-01-000012 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

13. 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

14. 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 21-11-0163-01-000014

15. L2 Demo overview 21-11-0163-01-000015 MIH packets are sent to L2 broadcast address

16. L3 (1 multicast hop) Demo overview 21-11-0163-01-000016 Multicast group used 239.255.0.1

17. 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? 21-11-0163-01-000017