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,

Slides:



Advertisements
Similar presentations
_link_parameter_report IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Definition and enhancements to MIH Link Parameter.
Advertisements

xx IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Proposed Presentation for 3GPP Date Submitted: July,
21-06-xxxx IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: The amendment for the MIH_Scan primitive Date Submitted: April,
21-06-xxxx IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: The amendment for the MIH_Scan primitive Date Submitted: April,
xxx IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Handover Procedure – Redraw of Annex Figure Date Submitted: January.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Utilizing terminal identifier to recognize the reserved resources.
MuGM IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Group management mechanisms Date Submitted: November, 2012 Authors or Source(s): Daniel.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Clarification for Handover Primitives Date Submitted: February,
IEEE MEDIA INDEPENDENT HANDOVER DCN: xxxx-00-MuGM Title: Outline of MuGM Date Submitted: January, 15th, 2013 Presented at IEEE.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Two New Information Elements for facilitating L3 connectivity.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Data Type Encoding Date Submitted: May 12, 2007 Presented at IEEE.
21-07-xxxx IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Command Service Date Submitted: Month, NN, 200x Presented at IEEE.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Analysis on Identifiers Date Submitted: January 9, 2006 Presented.
21-07-xxxx IEEE MEDIA INDEPENDENT HANDOVER DCN: xxxx Title: Subscription ID Scope Date Submitted: June, 14 th, 2007 Presented.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Amendments for Event Register Date Submitted: July, 10, 2006 Presented.
MuGM IEEE MEDIA INDEPENDENT HANDOVER DCN: MuGM Title: Definition of IEEE d multicast identifiers Date Submitted:
xxx IEEE MEDIA INDEPENDENT HANDOVER DCN: xxxx Title: Information Service Flow Update Date Submitted: October 22, 2006.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Instructions to get a Free IEEE Web Account Date Submitted: January.
21-05-xxxx IEEE MEDIA INDEPENDENT HANDOVER DCN: xxxx Title: Support for query of the registered event at MIH Layer and Link.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Higher layer services and information IEs Date Submitted: March 2006 Authors or Source(s):
1 IEEE MEDIA INDEPENDENT HANDOVER DCN: sec Title: Message Flow Date Submitted: March 1, 2011 Authors or Source(s): Fernando Bernal-Hidalgo,
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: MIH Handover Initiation Strategy Consistency Date Submitted: November,
Doc.: IEEE /0310r0 Submission Sept 2007 Srinivas Sreemanthula Slide 1 IEEE MEDIA INDEPENDENT HANDOVER DCN: MIH-Security-Options.ppt.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Notify high layer when events change Date Submitted: Jan, 06,
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: IE prioritization for query response size limit support Date Submitted:
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Handover Flow Diagrams Update Date Submitted: May 14, 2007 Presented.
21-07-xxxx IEEE MEDIA INDEPENDENT HANDOVER DCN: xxxx Title: Problem Scenario Date Submitted: September, 2007 Presented at.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: MIH Capability Discovery Amendment Date Submitted: April 20, 2006.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Higher layer services and information IEs Date Submitted: March 2006 Authors or Source(s):
IEEE MEDIA INDEPENDENT HANDOVER DCN: draft_invariants Title: Invariants in Proposed Drafts Date Submitted:
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: FMCA MIH Work Item Date Submitted: March, 2009 Presented at IEEE.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Session Identifier Date Submitted: February xx, 2006 Presented.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: MIH Handover Initiation Strategy Consistency Date Submitted: November,
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Comments Date Submitted: Jan, 06, 2006 Presented at IEEE
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Data Type Encoding Date Submitted: April 27, 2007 Presented at.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Events generated by MIH Users Date Submitted: February, 17th,
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: ID Definition Date Submitted: July 14, 2006 Presented at IEEE session in San.
1 IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: IEs related Issues Date Submitted: March 2007 Presented at IEEE session.
1 IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Figures of MIH reference model for and Date Submitted: Jan, 2008.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Optimize MIIS Get Information Message Date Submitted: February.
21-06-xxxx IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: The amendment for the MIH_Scan primitive Date Submitted: April,
IEEE MEDIA INDEPENDENT HANDOVER DCN: xxx Title: Suggestion about link parameters report Date Submitted: Jan 10,
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Amendment-for-Link_Handover_Complete.Indication- primitive Date.
IEEE MEDIA INDEPENDENT HANDOVER DCN: bcst Title: Overview of Draft P802.21b/D0.01 Date Submitted: May 11, 2010 Presented at IEEE
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: MIH Registration Amendments Date Submitted: Nov.13, 2006 Submitted for discussion.
xx-00-XXXX IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Workflow for IEEE Specification work Date Submitted: July, 11, 2005 Presented.
IEEE MEDIA INDEPENDENT HANDOVER DCN: 100 Title: Cross Domain Trigger and Handover Talking Points Date Submitted: July 13, 2004.
21-07-xxxx IEEE MEDIA INDEPENDENT HANDOVER DCN: xxxx Title: Multiple MIH User Issues Date Submitted: November, 12-16, 2007.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Proposal for power consumption information related to different.
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER DCN: xxx
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN: xxxx
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN: xxxx
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN: xx
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Your Title Here
21-06-xxx-LocInfo_in_IS_request
IEEE MEDIA INDEPENDENT HANDOVER DCN: xx-00-sec
Presentation transcript:

IEEE MEDIA INDEPENDENT HANDOVER DCN: XXXX Title: Panasonic’s MIH Proposal (Details) Date Submitted: January, 09, 2005 Presented at IEEE 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).

IEEE presentation release statements This document has been prepared to assist the IEEE 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 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 Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3

Contents Events Link_Found Link_QoS_Change Queries Avail_Events Connection_Cost Requests Event_Request IF_Disconnect UL_Register Normalisation MIH-MIH Signalling

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.

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.

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.

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.

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.

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.

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.

Normalisation

Normalisation 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 needs to provide a consistent definition & interpretation of IEs Individual media needs to map their own technology specific info to the above 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

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