1. IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-13-xxxx-00-MuGM Title: Demo Scenario Date Submitted: May, 16th, 2013 Presented at IEEE 802.21 session in Waikoloa, HI Authors or Source(s): Toru Kambayashi (Toshiba), Yoshikazu Hanatani Abstract: The demo scenario 21-12-0157-00-MuGM1

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 outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html> Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3 http://standards.ieee.org/board/pat/guide.html 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#6 http://standards.ieee.org/board/pat/faq.pdf 21-12-0157-00-MuGM2

3. Group Commands 1.Four MNs are shown: The Leaf Numbers of which are 2, 3, 5 and 8 2.A group, named “test”, has already been prepared: It has all the MNs ranging from 1 to 127. Thus, the group “test” covers the four MNs (2, 3, 5 and 8), too 3.Several group commands are sent from the Command Center to the group “test” via the multicast channel associated with the group  Configuration update commands update the power consumption limit  Link HO Commit commands send an IP address of the destination of handover  Link Actions commands on/off the power save mode

4. Creation of a Group 4.A group “foo” which are comprised of 2, 3 and 8 is created by a group manipulation command  The input can be either of the followings: The leaf numbers 2 (=0b00000010), 3 (=0b00000011) and 8 (0b00001000), or 0b0000001* (the node which covers 2 and 3) and 8 (0b00001000) They both result in the same GKB having two GKB Indices: {(0x07, 00000001), (0x08, 00001000)}  239.0.1.15, for instance, is the multicast address associated with the group “foo” 5.Several group commands are issued by the Command Center and sent to the group “foo” via the associated multicast address  Check that the members of “foo” react to the commands

5. Removal of a Member 6.An MN, say 3, is removed from the group “foo” by a group manipulate command 7.Several group commands are issued to “foo”  Check that the removed MN reacts no more

6. Bad MN 8.An MN, say 8, is “gone bad”: Even if a group manipulation command is issued to removed it, it continues to listen to the multicast address 9.Group commands are issued to “foo”. The bad MN can get the arguments of the commands because they are not encrypted 10.Group commands which are encrypted by the group key are issued to “foo”. The bad MN cannot take the arguments of the commands