1. 21-06-0522-02-0000 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN:21-06-0634-00-0000 Title: MIH Capability Discovery Amendment Date Submitted: April 20, 2006 Presented at IEEE 802.21 session #14 in Jacksonville Authors or Source(s): Yan PENG, Junxiang Guo Abstract: This contribution proposes amendments related to the MIH Capability Discovery. We propose to specify the way for dealing with MIH_Capability_Discover.request, i.e. broadcast or not. Finally, we add new ActionCode in this MIH message.

2. 21-06-0522-02-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-06-0522-02-0000 MIH Capability Discovery Procedure MIH Capability Discovery through media specific broadcast messages The network may be able to indicate to the mobile node if it is MIH capable by broadcasting MIH capability over the medium, e.g. beacon in 802.11 and DL-MAP in 802.16. On Demand MIH Capability Discovery The MIH Function in mobile node or in the network may discover which entity in the network or which mobile node supports MIH capability by using MIH capability discovery procedure.

4. 21-06-0522-02-0000 Current Message Format MIH_Capability_Discover Request SupportedEventList This parameter specifies the list of supported events. Each event is represented by an event code and occupies one byte. SupportedCommandList This parameter specifies the list of supported commands. Each command is represented by a commandcode and occupies one byte. SupportedTransportList This parameter specifies the list of supported transport options for different MIH services. SupportedISQueryTypeList This parameter specifies the list of supported IS query types. Four query type options are defined as follows: TLV, RDF_DATA, RDF_SCHEMA_URL, RDF_SCHEMA.

5. 21-06-0522-02-0000 Problems Description Assumption: Considering the case where some PoAs with MIHF and one PoA without MIHF, e.g. as shown in figure 29 (page #3), there are one mobile node, three PoAs with MIHF and one PoA without MIHF. Problem 1: When a PoA receives a message MIH_Capability_Discover.request, how does the PoA deal with it, i.e. to broadcast the message or only to response directly? Problem 2: Is the other discovery scenario possible? For example, the MN wants to know the MIH capability of all the PoAs in this area (both the serving PoA and others, by contrast with the figure 29 in page 3). If yes, how could the serving PoA know whether to broadcast only or to response and broadcast? Conclusion: A method is needed to tell the receiver of message MIH_Capability_Discover.request, what the sender want it to do.

6. 21-06-0522-02-0000 Does a transport level address solve them? There two reason why a transport level address can’t different. When the MIHF receives a MIH message, it doesn't know what broadcast or unicast address is used in transport level. The MIH message doesn't contain information of transport layer address. The transport layer address is transparent to MIHF. As for the figure 29, even if the mobile terminal uses broadcast address, this MIH_Capability_Discover.request message still can't be received by other PoAs (i.e. PoA2, Access Router). Currently the scope of this discovery is limited only to L2 (i.e. not beyond an FA/AR). Although it is possible to configure two technologies on the same subnet, this is not likely to happen. Forwarding this message by PoA1 in MIH level is necessary. Actually the "broadcast" of PoA1 is to only send several unicast messages other than real transport level broadcast.

7. 21-06-0522-02-0000 Proposal: Add Optional ActionCode IE Add an optional action code IE (ActionCode) to the message MIH_Capability_Discover.request, that suggests the receiver what to do next. NameType SupportedEventListEvent List (255) SupportedCommandListCommand List (254) SupportedTransportListTransport List (253) SupportedISQueryTypeListIS Query Type List (252) ActionCode (optional) Action Code(26) Definition of the ActionCode: TypeLengthValue 261Action of handling request message: 0: response directly 1: broadcast 2-255: reserved

8. 21-06-0522-02-0000 Proposal: Depict Default Mechanism If the optional ActionCode IE is absent in the message, the following default mechanism is used to solve the problem: Only the serving PoA receiving the MIH_Capability_Discover.request message from the mobile node should broadcast the message to other PoAs The PoAs except for the serving PoA should response to the message directly with its own MIH capability to the sender (i.e. the serving PoA).