IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-12-0029-00-0000Title: IEEE 802.21d base ideas and prototype implementationDate Submitted: Presented at IEEE 802.21 session #48 in JacksonvilleAuthors 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-0000 1

21-11-0163-01-0000 2

IEEE 802.21 presentation release statementsThis 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 <http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf> 

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

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-0000 4Maintenance PAN

Maintenance

After maintenance

PAN under operation 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 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-0000 5

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-0000 6

Possible solution

21-11-0163-01-0000 7

MIHF

MIH_USER

IP

L2/PHY

PoS

IP/L2 Cloud

MIHF

MIH_USER

IP

L2/PHY

MN2

MIHF

MIH_USER

IP

L2/PHY

MN1

Suppose MIHF_ID group mcast1 already created and MN1 and MN2 joined it

Possible solution L2 MCAST

21-11-0163-01-0000 8

MIHF

MIH_USER

IP

L2/PHY

PoS

IP/L2 Cloud

MIHF

MIH_USER

IP

L2/PHY

MN2

MIHF

MIH_USER

IP

L2/PHY

MN1

mcast1 is transported through L2 multicast, MN1 and MN2 are in the same multicast L2 domain

Association: mcast1_MIHF_ID<->L2mcast address

Possible solution L2 MCAST

21-11-0163-01-0000 9

MIHF

MIH_USER

IP

L2/PHY

PoS

IP/L2 Cloud

MIHF

MIH_USER

IP

L2/PHY

MN2

MIHF

MIH_USER

IP

L2/PHY

MN1

Messages sent to mcast1 MIHF ID will be encapsulated as L2 multicast messages using L2mcast address

MIH message to mcast1 MIHF ID

L2 message to L2mcast 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

MN2

MIHF

MIH_USER

IP

L2/PHY

MN1

L2mcast used to route the packet to the MIHF of nodes subscribed to the group. This is done by subscribing the nodes to L2mcast 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 L2mcast

Decapsulate packet and send it to MIH User listening to mcast1

Possible solution L3 MCAST

21-11-0163-01-0000 11

MIHF

MIH_USER

IP

L2/PHY

PoS

IP/L2 Cloud

MIHF

MIH_USER

IP

L2/PHY

MN2

MIHF

MIH_USER

IP

L2/PHY

MN1

mcast1 is transported through IP multicast, MN1 and MN2 can be located in different networks as long as multicast IP transport is supported by them

Association: mcast1_MIHF_ID<->IPmcast address

Possible solution L3 MCAST

21-11-0163-01-0000 12

MIHF

MIH_USER

IP

L2/PHY

PoS

IP/L2 Cloud

MIHF

MIH_USER

IP

L2/PHY

MN2

MIHF

MIH_USER

IP

L2/PHY

MN1

Messages sent to mcast1 MIHF ID will be encapsulated as IP multicast packets with destination address IPmcast

MIH message to mcast1 MIHF IDMIHF behaves as an IP layer user

IP packet to IPmcast 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

MN2

MIHF

MIH_USER

IP

L2/PHY

MN1

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 IPmcast

Decapsulate packet and send it to MIH User listening to mcast1

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-0000 14

L2 Demo overview

21-11-0163-01-0000 15

MIH packets are sent to L2 broadcast address

L3 (1 multicast hop) Demo overview

21-11-0163-01-0000 16

Multicast group used 239.255.0.1

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-0000 17