1. 21-07-0009-00-0000 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0009-01-0000 Title: Events generated by MIH Users Date Submitted: February, 17th, 2007 Presented at IEEE 802.21 session #19 in Orlando, FL Authors or Source(s): IEEE 802.21 WG Abstract: Discussion on the communication between MIH_Users

2. 21-07-0009-00-0000 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

3. 21-07-0009-00-0000 Assigned Comment #16: MIH User Events Comment 3041 from LB #1b

4. 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?

5. 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 resolution 4.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 WLAN3G ApplicationHO decision module … … ?

6. 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 WLAN3G AppHO module … MIH Function WLAN3G App … MIH Function WLAN3G HO module …

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

8. 21-07-0009-00-0000 Solution B Enable downwards direction for MIES in addition to upward events. Local Remote MIH Function WLAN3G AppHO module … MIH Function WLAN3G App … MIH Function WLAN3G HO module … User EventMIH Event User Event MIH Event Added/Modified to MIH No modification to MIH

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

10. 21-07-0009-00-0000 Solution C Add new command to send notification to other MIH_Users (eg: MIH_Notify) Local Remote MIH Function WLAN3G AppHO module … MIH Function WLAN3G App … MIH Function WLAN3G HO module … 1.Request Added/Modified to MIH No modification to MIH 4.Conf 1.Request3.Indication6.Confirm 2.Request 5.Response 4.Response 2.Indication 3.Resp

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

12. 21-07-0009-00-0000 Solution D Add new command (eg: MIH_Notify) combined with regular MIH Event Local Remote MIH Function WLAN3G AppHO module … MIH Function WLAN3G App … MIH Function WLAN3G HO module … 1.Request3.MIH Event Added/Modified to MIH No modification to MIH 2. Confirm 1.Request4.MIH Event2.Confirm 3.Remote MIH Event

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