21-07-0009-00-0000

IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0009-01-0000Title: Events generated by MIH Users Date Submitted: February, 17th, 2007Presented at IEEE 802.21 session #19 in Orlando, FLAuthors or Source(s):  IEEE 802.21 WG

Abstract: Discussion on the communication between MIH_Users

21-07-0009-00-0000

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

21-07-0009-00-0000

Assigned Comment #16:MIH User Events

Comment 3041 from LB #1b

21-07-0009-00-0000

Introduction

• Current communication model allows only upward events:• FROM Lower layers TO MIHF (Lower Layer Events)• FROM MIHF TO MIH_Users (MIH Events)

• PROBLEM: How to notify to MIH_Users about ‘things’ (or ‘events’) happening asynchronously in other MIH_Users?

21-07-0009-00-0000

Example

1. User is streaming video at low resolution.2. User is currently connected to 3G, but is also within WLAN coverage.3. User decides to change the application settings to high resolution4. The action of the user may cause a handover to WLAN, seeking for a higher

throughput to support the resolution demanded by the user.

• Notification FROM the Application (an MIH_User) TO the HO_decision_module (another MIH_User) which may decide to initiate a handover or not.• How?• 4 possible solutions (so far)

MIH Function

WLAN 3G

Application HO decision module…

…

?

21-07-0009-00-0000

Solution A• Communication between MIH_Users not specified by 802.21.

It can be achieved through proprietary mechanisms, locally and remotely.

• Local

• Remote

MIH Function

WLAN 3G

App HO module

…

MIH Function

WLAN 3G

App

…

MIH Function

WLAN 3G

HO module

…

21-07-0009-00-0000

Solution A• PROs:

• No need to change current draft D04.00• Applications (or MIH Users in general) do not have to be

MIH aware

• CONs:• No standard interface between MIH_Users• Every application (and MIH User in general) will have to

build proprietary interfaces with other MIH_Users (e.g. HO modules)

21-07-0009-00-0000

Solution B• Enable downwards direction for MIES in addition to upward

events.• Local

• Remote

MIH Function

WLAN 3G

App HO module

…

MIH Function

WLAN 3G

App

…

MIH Function

WLAN 3G

HO module

…

User Event MIH Event

User Event MIH EventMIH Event

Added/Modified to MIH

No modification to MIH

21-07-0009-00-0000

Solution B• PROs:

• Semantically, MIES better suits the kind of information we want to transmit: ‘things’ happening asynchronously (events). MICS implies to request an action and MIIS is for non time critical information.

• MIH_Users will subscribe to this type of events via the MIHF. Same behavior as Link_Events. When a new MIH_User is started will inform the MIHF of the events offered.

• CONs:• The direction of MIES has to be modified: also downward

events instead of only upward events• New event(s) need to be specified in the draft.

21-07-0009-00-0000

Solution C• Add new command to send notification to other MIH_Users

(eg: MIH_Notify)• Local

• Remote

MIH Function

WLAN 3G

App HO module

…

MIH Function

WLAN 3G

App

…

MIH Function

WLAN 3G

HO module

…

1.Request Added/Modified to MIH

No modification to MIH

4.Conf

1.Request 3.Indication6.Confirm 2.Request

5.Response

4.Response

2.Indication3.Resp

21-07-0009-00-0000

Solution C• PROs:

• Only one modification: add a new command to the MICS (eg: MIH_Notify)

• CONs:• There’s no subscription method. How a MIH_User (e.g.

application) knows which MIH_User (e.g. HO_module) has to inform to? Broadcast to all MIH_Users? Maybe fine for LOCAL, but definitely not for REMOTE case.

21-07-0009-00-0000

Solution D• Add new command (eg: MIH_Notify) combined with regular

MIH Event• Local

• Remote

MIH Function

WLAN 3G

App HO module

…

MIH Function

WLAN 3G

App

…

MIH Function

WLAN 3G

HO module

…

1.Request 3.MIH Event Added/Modified to MIH

No modification to MIH

2. Confirm

1.Request 4.MIH Event2.Confirm3.Remote MIH Event

21-07-0009-00-0000

Solution D• PROs:

• Only modification: add a new command to the MICS (eg: MIH_Notify)

• Subscription mechanism problem (solution C) solved. When MIHF receives the MIH_Notify, MIHF will send an event only to MIH_Users subscribed to that particular event.

• CONs:• Semantically, the kind of information is more an event than

a command.• New event(s) need to be specified in the draft.