1. 21-04-0161-01-00001 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-05-XXXX-00-0000 Title: Panasonic’s MIH Proposal (Details) Date Submitted: January, 09, 2005 Presented at IEEE 802.21 session #06 in Monterey Authors or Source(s): Benjamin Koh, Cheng Hong, Tan Pek-Yew, Makoto Funabiki, Shinkichi Ikeda, Takashi Aramaki Abstract: This presentation presents more details on selected events and normalisation of values as outlined in the previous presentation (161-01).

2. 21-04-0161-01-00002 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-04-0161-01-00003 Contents Events Link_Found Link_QoS_Change Queries Avail_Events Connection_Cost Requests Event_Request IF_Disconnect UL_Register Normalisation MIH-MIH Signalling

4. 21-04-0161-01-00004 Events Link_Found.event Function This event is used to notify about the detection of a possible new link. Semantic LINK-FOUND.event {InterfaceIdentifier, StationIdentifier} –InterfaceIdentifier - An integer to identify the interface that is giving the event. –StationIdentifier - Used to identify the base station, access point or host that was detected When Generated When the presence of a base station, access point or host with whom a link may be set up is detected, this event may be generated by the MAC or PHY and sent to the MIHF or else generated by the MIHF to be passed to requesting Upper Layers to inform of the discovery of a possible link. The event may be triggered due to the presence of broadcasted information by the station in question. Effect on Receipt If received by the MIHF, it should check if there are any standing requests from Upper Layers or other MIHF for this kind of event. If found, it should proceed to generate and send its own LINK-FOUND.event up to the requesting protocol stack, else no further action is needed.

5. 21-04-0161-01-00005 Events Link_QoS_Change.event Function This event is used to inform the higher layers that the QoS parameter for the link has changed. Semantics LINK-QOS-CHANGE.event {InterfaceIdentifier, NewQoSValue} –InterfaceIdentifier - An integer to identify the interface that is giving the event. –NewQoSValue - This is the new QoS metric for the link in question. The exact value and significance may be media specific. When Generated When the QoS parameter for a link has changed, this event may be generated by the PHY, MAC or LLC and sent to the MIHF or else generated by the MIHF to be passed to requesting Upper Layers to inform of the new QoS parameter. The event may be triggered due to the presence of broadcasted information by station in question. Effect on Receipt If received by the MIHL, it should check if there are any standing requests from Upper Layers or other MIHL for this kind of event. If found, it should proceed to generate and send its own LINK_QOS_CHANGE.event up to the requesting protocol stack, else no further action is needed.

6. 21-04-0161-01-00006 Queries Avail_Events.query Function This query is used to enquire on the available triggers that the MIHL is able to provide at this time. Semantics AVAIL-TRIGGERS.query {ProtocolIdentifier, (SAPLocator)} –ProtocolIdentifier - An integer to identify the protocol that is requesting the trigger. –SAPLocator - An address string specifying the location of the SAP handling the communication between MIHF and the protocol. For protocols already registered with the MIHF this field is optional Effect on Receipt The MIHF should return a list of available triggers to the SAPLocator specified in the query. If the SAPLocator is not specified, the MIHF should check for the registered SAPLocator.

7. 21-04-0161-01-00007 Queries Connection_Cost.query Function This query is used to inquire on the metric cost of the specified connection. Semantics CONNECTION-COST.query {ProtocolIdentifier, InterfaceIdentifier, (ConnectionIdentifier), (TypeofCost)} –ProtocolIdentifier - An integer to identify the protocol that is requesting the trigger. –InterfaceIdentifier - An integer to identify the interface to be activated. –ConnectionIdentifier - An integer to identify the specific connection on the interface if the interface supports multiple connections. This field may be optionally left empty. –TypeofCost - A variable to indicate the type of cost the requesting protocol is interested in. This field may be optionally left empty. Effect on Receipt Upon receiving the query, the MIHF should first check that the given ProtocolIdentifier is already registered. It should then query, if required, and reply the current metric cost of the connection on the specified interface via the registered SAP. If the interface supports multiple concurrent connections, the desired connection may be specified.

8. 21-04-0161-01-00008 Requests Event_Request.request Function This request is used to request for a particular trigger to be sent to the requesting protocol. Semantics EVENT-REQUEST.request {ProtocolIdentifier, EventIdentifier} –ProtocolIdentifier - An integer to identify the protocol that is requesting the trigger. –EventIdentifier - An 8 bit descriptor identifying the event the protocol is interested in receiving. This field may consist of more than one EventIdentifier. Effect on Receipt Upon receiving the request, the MIHF should check to see if the protocol identified by ProtocolIdentifier has a valid registration. The MIHL should then proceed to verify that the requested EventIdentifier descriptors are valid and should register them for the requesting protocol. If both procedures are successful, a successful EVENT-REQUEST.confirm should be sent to the requesting protocol else an error message should be sent.

9. 21-04-0161-01-00009 Requests IF_Connect.request Function This request is used to request that the specified interface perform the necessary actions in order to create a connection. Semantics IF-CONNECT.request {ProtocolIdentifier, InterfaceIdentifier, Connect, (StationIdentifier)} –ProtocolIdentifier - An integer to identify the protocol that is requesting the trigger. –InterfaceIdentifier - An integer to identify the interface to be activated. –ConnectFlag - A flag to decide if the interface is to make a connection (TRUE) or break a connection (FALSE). –StationIdentifier - Used to identify the base station, access point or host the connection is to be set up with. This may be the MAC address or any other identifier as appropriate. This field may be optionally left empty. Effect on Receipt Upon receiving the request, the MIHL should check to see if the protocol identified by ProtocolIdentifier has a valid registration and that InterfaceIdentifier specifies a valid interface. The MIHL should then proceed to request that specified interface initiate a connection. The selection of the base station may be specified in the IF- CONNECT.request or at the discretion of the MIHL or interface. After completion a confirmation or error message should be sent, as appropriate, to the requesting protocol.

10. 21-04-0161-01-000010 Requests UL_Register.request Function For individual upper layer protocol stacks to register themselves with a locally unique ID and a SAP address/location. Semantics UL-REGISTER.request {ProtocolIdentifier, SAPLocator} –ProtocolIdentifier - An integer to identify the protocol that is requesting the registration. –SAPLocator - An address string specifying the location of the SAP handling the communication between MIHF and the protocol. Effect on Receipt Upon receiving the request, the MIHF should initiate registration process for the requesting protocol. The MIHF should then proceed to verify that the given SAPLocator is valid and reachable. If both procedures are successful, a successful confirmation message (UL_REGISTER.confirm) should be sent to the requesting protocol else an error message should be sent.

11. 21-04-0161-01-000011 Normalisation

12. 21-04-0161-01-000012 Normalisation 802.21 to focus on defining MIH generic: SAPs Events Queries Requests Information Elements QoS Levels Power Level/State Cost Metrics Specific Media/Entity/Layer would define its own SAPs Mapping between SAPs and values would likely be a collaborative effort. 802.21 needs to provide a consistent definition & interpretation of IEs Individual media needs to map their own technology specific info to the above 802.21 may publish guidelines for use with legacy media/entities/layers(?) Upper layer needs to be interpret the info provide by.21 and map to their own needs

13. 21-04-0161-01-000013 Normalisation Examples: QoS level: 11e QoS is different from the.3 (1p) QoS (or.15/.16 QoS if there is), certain mapping needs to be done for any handover control. E.g. if.21 MIH takes the 1p QoS as the generic QoS IE format, then mapping to the corresponding.11,.15,.16 QoS has to be done Unit scale: different tech and upper layers have different scales in presenting certain attributes, e.g. if the link_going_down trigger is specified using unit of sec from upper layer, lower layer SAP may need to have that in form of msec. Certain mapping is needed Cost metrics conversion table could be built in (stored in SIM), or downloaded Network side Conversion of info from different technology could be crucial for the information base service