1. Media Independent Handover
January 2006
11-06-xxx
January 2006
Media Independent Handover
Date:
Authors:
Notice: This document has been prepared to assist IEEE 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.
Release: 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Eleanor Hepworth, Siemens Roke Manor

2. January 2006
11-06-xxx
January 2006
WiNOT Consortium
This presentation is made on behalf of the WiNOT (Wireless NetwOrking Technology), comprising:
BenQ
Cingular
Intel
Nokia
Panasonic
Siemens
STMicroeletronics
T-Mobile
Eleanor Hepworth, Siemens Roke Manor

3. Abstract This submission addresses the 802.21 Media Independent
January 2006
11-06-xxx
January 2006
Abstract
This submission addresses the Media Independent
Handover Requirements
Eleanor Hepworth, Siemens Roke Manor

4. 802.21 General Requirements [1.1] Reference Model
January 2006
General Requirements
[1.1] Reference Model
The Reference Model shall support Media Independent Handover (MIH) Function services. The specification shall define appropriate SAPs, primitives and Information Elements to support IEEE MIH functionalities
[1.2] Capability Indication
The IEEE specification shall provide a means for APs to indicate support for the specification. This shall be in the form of a Media Independent Handover capability indication that shall be made available before a STA attaches to the network

5. January 2006
SAP Requirements
[2.1] The IEEE specification shall support the following services as specified in the specification
Link layer events
Link layer commands
Information service
For each of the above services this may result in definition of a new primitive, or change in semantics of an existing primitive or just identification of an existing primitive with appropriate semantics in the specification.

6. 802.21 Transport Requirements
January 2006
Transport Requirements
[3.1] Events and Commands
The specification shall support a L2 transport for transferring remote events and remote command messages (only in state 3 and not in any other state) over the air interface between the MIH function on the STA and the MIH Function on the PoA (AP). The L2 transport shall need to support integrity, fragmentation and re-assembly of packets.
[3.2] Information Service
The STA shall be able to use the Information Service and query specific IEs. The specification shall provide a suitable L2 transport that allows the STA to query the values of different Information Elements in State 1 and State 3 phases. The L2 transport shall need to support integrity, fragmentation and re-assembly of packets.
Also,
The specification shall use a new ether type for supporting MIH services over the data plane. This is just a fyi, not really a requirement.

7. MIH Architecture for 802.11 Proposal
January 2006
MIH Architecture for Proposal
New items in scope of
New enhancements to MLME_SAP proposed by

8. MIH Capability Indication Proposal
January 2006
MIH Capability Indication Proposal
Make use of the extended capability field and define a new IE for MIH capability
Order
Size (octets)
Description 1
TBD Element ID (to be assigned by the IEEE Assigned Numbers Authority): defines the Extended Capability IE 2
Length 3 n
Extended capabilities (Variable Size)
Extended Capability Information Element
Length indicates a value representing the variable size of the Extended Capabilities field.
Byte 0
Bit 0
MIH Capability Enabled
Indicates that MIH Capability is supported
Bit 1
MIH Event Service Enabled
Indicates that MIH Event Service is supported
Bit 2
MIH Command Service Enabled
Indicates that MIH Command Service is supported
Bit 3
MIH Information Service Enabled
Indicates that MIH Information Service is supported
Bit 4-7
Reserved
Set to 0, if not used
Extended Capabilities Field

9. Proposed Link Layer Events
January 2006
Proposed Link Layer Events No
Event Type
Event Name
Description 1
State Change
Link Up
L2 Connection established 2
Link Down
L2 Connection is broken 3
Predictive
Link Going Down
L2 connection breakdown imminent 4
Link Detected
New L2 link has been found 5
Link Parameters Change
Change in specific link parameters has crossed pre-specified thresholds (link Speed/Qos/ Quality metrics) 6
Administrative
Link Event Rollback
Event rollback 7
Link Transmission
Link SDU Transmit Success
Improve handover performance through local feedback as opposed to waiting for end-to-end notifications 8
Link SDU Transmit Failure
Error in transmitting SDU corresponding to a specific PDU 9
Link Synchronous
Link Handover Imminent
L2 intra-technology handover imminent (subnet change). Notify Handover information without change in link state) 10
Link Handover Complete
Notify handover state

10. Link Up: SAP Changes Proposal
January 2006
Link Up: SAP Changes Proposal
Function
Link Up is a L2 event which indicates that L3 can now send packets over the link. All L2 activities required for configuring the link are expected to be completed at this point. Thus in case of network with i security it would mean that not only has station associated with an AP, but the 4 way handshake is also complete.
Semantics
MLME-LinkUp.indication
Parameters
Local node MAC address
Link Identifier (SSID + BSSID)
MAC address of old Access Router (if any)
MAC address of new Access Router (if any)
Network Identifier for detecting possible change in subnet
When Generated
Generated by MLME when all L2 connection set up activities are completed
Effect On Receipt
Higher layers may initiate a new connection, router discovery, IP configuration, etc.

11. MIH Transport Proposal
January 2006
MIH Transport Proposal
Two ways for Un-Authenticated and Un-associated state (state 1)
Use existing Management frames (e.g. Probe-Request/Response) to transport MIH information for Information Elements
Minor changes in .11 (except a new IE), but includes overhead in the response
Define a new container Management frame to transport MIH information
Optimized for transport requirements (less overhead)
Also useable to carry network selection information
Authenticated and associated state (state 3)
All MIH transport requirements can be addressed via the data plane or appropriate higher Layer mechanism
No changes needed.
Define an Action Frame if certain components may require a higher priority of transfer

12. MIH Transport in Un-Authenticated and Un-associated State
January 2006
MIH Transport in Un-Authenticated and Un-associated State
Information Service is the target
Mainly query/response exchanges
Use of management frame implies
MIH layers in STA uses MLME_SAP to request transport of an IS query
creates management frame and transports the IEs
in AP may have to reconstruct the IS Query message to forward to appropriate entity
For the response, the opposite process takes place

13. Issue: 802.11 MAC Transparency
January 2006
MIH Transport in Un-Authenticated and Un-associated State
Issue: MAC Transparency
Requirement 3.1: “The specification shall support a L2 transport for transferring remote events and remote command messages (only in state 3 and not in any other state)”
Need to ensure that a misbehaving STA does not exchange ES and CS in state 1
If is completely transparent to the type of service being exchanged in state 1, the requirement cannot be satisfied
MAC in MAC is unaware of specific service
unless the MIHF in the network is built in the AP and aware of state for STA, MIHF does not know whether ES/CS registration is received the STA is valid (i.e. STA is in state 3)

14. Issue: 802.11 MAC Transparency (cont.d)
January 2006
MIH Transport in Un-Authenticated and Un-associated State
Issue: MAC Transparency (cont.d)
Since we’re already modifying the MAC for IS support, do we need to provide transparency?
Also, currently IS has only query and response
How to support possible future extensions of IS with minimal or no impact on MAC?
Using IS-message specific management frames is not realistic

15. Issue: 802.11 MAC Transparency (cont.d)
January 2006
MIH Transport in Un-Authenticated and Un-associated State
Issue: MAC Transparency (cont.d)
Proposal
Add indication of IS service being transported to management frame
Introduce a new _IS_Msg_Type IE
Introduce a new _Data IE for transport of IEs

16. Issue: 802.11 MAC Transparency (cont.d)
January 2006
MIH Transport in Un-Authenticated and Un-associated State
Issue: MAC Transparency (cont.d)
Server
STA AP
Probe Request (802.21_IS_Msg_Type, _Data)
AP creates message based on _IS_Msg_Type and IEs
802.21_IS_msg1 ( IEs)
802.21_IS_msg2 ( IEs)
AP sets _IS_Msg_Type based on the type of message
Probe Response (802.21_IS_Msg_type, _Data)

17. Issue: Impact on Power Saving
January 2006
MIH Transport in Un-Authenticated and Un-associated State
Issue: Impact on Power Saving
Use of management frames for IS uses a query and response mechanism
To guarantee current power savings, response for idle STA must be obtained within a limited amount of time
Requiring a STA to wait indefinitely for a response to a query impacts considerably the power consumption
for practical implementations, WFA has e.g. indicated that the Probe Response shall be returned within 5ms from the receipt of the Probe Request in order to support power saving
Also, timing out (e.g. after MaxChannelTime) is not a realistic solution, since it may take considerably more time for the AP to retrieve the information and create a reply, therefore most queries would automatically time out
STA could query again before the AP has retrieved the info
Also, in order to avoid “wasting” the information retrieved by the AP, the AP must cache them and wait for the STA to ask again, without knowing if this will happen and no way to correlate the queries

18. Optimized Power Saving Querying Mechanism
January 2006
MIH Transport in Un-Authenticated and Un-associated State
Optimized Power Saving Querying Mechanism
Assumptions:
The AP receiving a query from a station can determine whether the information is available or not
If not available, the AP has the ability to retrieve such information
Mechanism is out of scope
Basic concept:
the mechanism enables an AP receiving a query from a station and not having the information readily available to reply to the station that the AP is capable to provide the information requested, but that such AP cannot provide it right away
The mechanism enables the AP to indicate to the station that the station needs to query again for the information
Specifically, the AP may optionally return a query identifier QueryID (whose value is unique for the AP) to be used by the station to query such AP again without the need for indicating again the information elements required (this may be useful when more than one IEs are requested and are not available instantaneously at the AP, and performing a new query by providing again the list of IEs would imply a waste of radio resources), and by the AP to correlate the queries.
The AP may optionally return also a time value ComeBackDelay determined by the AP and indicating how long the station shall wait before querying the AP again.

19. Optimized Power Saving Querying Mechanism (cont.d)
January 2006
MIH Transport in Un-Authenticated and Un-associated State
Optimized Power Saving Querying Mechanism (cont.d)
The Probe Request is extended to support a QueryID field
The Probe Response is extended to support
The QueryID field
a ComeBackDelay field
An overview using Probe Request/Response is shown in the next slide

20. Optimized Power Saving Querying Mechanism (cont.d)
January 2006
MIH Transport in Un-Authenticated and Un-associated State
Optimized Power Saving Querying Mechanism (cont.d)
Server
STA AP
Probe Request (802.21_IS_Msg_Type, _Data)
< 5ms
Probe Response ([QueryID], [ComeBackDelay])
AP stores QueryID and _Data to be able to correlate the “come back” Probe Request
Delay = ComeBackDelay
802.21_IS_msg1 ( IEs)
Typically
>>
5ms
802.21_IS_msg2 ( IEs)
AP stores the reply
STA generates the “come back” Probe Request
...
Probe Request ([QueryID])
< 5ms
Probe Response (802.21_IS_Msg_type, _Data)
[X] : optional IE

21. Optimized Power Saving Querying Mechanism (cont.d)
January 2006
MIH Transport in Un-Authenticated and Un-associated State
Optimized Power Saving Querying Mechanism (cont.d)
The STA does not need to remain active while waiting to send the “come-back” Probe Request, therefore enabling power saving
In case the STA is connected to an AP1 and is actively exchanging data frames with AP1, but wants to retrieve information from a target AP2, the STA does not need to remain on the AP2 channel while waiting to send the “come-back” Probe Request

22. Optimized Power Saving Querying Mechanism (cont.d)
January 2006
MIH Transport in Un-Authenticated and Un-associated State
Optimized Power Saving Querying Mechanism (cont.d)
The Probe Request is extended to support a QueryID field
The Probe Response is extended to support
The QueryID field
a ComeBackDelay field

23. 802.21 IEs as native 802.11 IEs Is it required? Use cases?
January 2006
MIH Transport in Un-Authenticated and Un-associated State
IEs as native IEs
Is it required? Use cases?
This seems more oriented to Network Selection requirement cluster

24. January 2006
Conclusion
TBC