1. IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Group management in MIHF Date Submitted: November 4, 2011 Presented at IEEE session #47 in Atlanta Authors or Source(s): Antonio de la Oliva Abstract: Requirements for group management in IEEE

2. IEEE 802.21 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

3. Motivation
Recently group management has been identified as a missing feature from IEEE
There is no way of addressing commands to group of users
Several scenarios exist:
Per-technology offload
Per CoS handover

4. Requirements Group identifiers at the MIHF level
Mechanisms to distribute the group information to the terminals
Mechanisms to enable the users to ask for the creation of groups
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
Group motivation (groups per technology, CoS, services, etc.)
Capability discovery, by default groups?

5. DCN 170 A first contribution on these ideas was presented in DCN 170
What was defined there?
Group MIHF IDs, based on NAI representation of L2/L3 multicast addresses
MIH_MN_HO_Join_Mcast: With this primitive the MN was able to either join an already existing group or ask for the creation of one
MIH_Net_HO_Join_Mcast: This primitive allows the PoS to force the MN to join a group
MIH_Multicast_Information: This primitive enables the PoS to inform all MNs in a region of the available groups

6. MULTICAST_GRP
The whole contribution is based on the MULTICAST_GRP data type
SEQUENCE(
CHOICE(IP_ADDR, MAC_ADDR,NULL),
CHOICE(MIHF_ID, NULL),
CHOICE(MULTICAST_CODE, GROUP_INFO) )

7. What is missing
Mechanism to let the MIH User receives the information and ask the MIHF to join the group
Probably recheck the state machine to be sure we are not braking it