IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Clarification for Handover Primitives Date Submitted: February, 19, 2007 Presented at IEEE Ad Hoc Meeting in Santa Clara Authors or Source(s): Y. Alice Cheng, Srinivas Sreemanthula Abstract: Describes the inconsistency in the handover primitives for group discussion.

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

Issues I 1.Parameters name appended with "List" should be a type of list. (P126 L22, L29) 2.Destination Identifier appears as “the destination ID of request or response.” (starting P126L7) 3."Current Link Identifier" type and valid range are inconsistent 4.Current Link ID description “The command is then sent either at L2 or at L3.” Why is this description required?(P126 L11) 1.Change type to “List of” 2. Change text to “This is the MIHF ID of local or peer MIH entity that identifies the destination for this primitive.” 3.Type: Network Identifier. Valid range: Maybe one of different 802 and Cellular networks (what does that mean?) 4.Delete…

Issues II 1.“The front is most suitable, backward is less” is not very descriptive. (P126L27 and more) 2.No definition of “AvailableResourceList” (starting P126 L36) nor “QueryResourceList” (starting P130L19) 3.Boolean “Type” and “Valid range” are not consistent. E.g. P135L1 v.s. P126L18 4.Parameter Lists need matching. Either by order or create a new data structure. Preferred Link List v.s. Preferred PoA List. Preferred Candidate Link List v.s. Available Resource Set v.s Preferred Candidate PoA List (p132) 1."Items in the beginning of the list are more preferable." 2.Keep the comment 3.Create section for describing data structures of primitive parameters 4.Combine the Preferred Link List and Preferred PoA List to a Link.

Issue III 1.The request primitives "effect on receipt" description are actually for.indication "effect on receipt" 2.Similarly the.response primitive "effect on receipt" description are actually for.confirm “effect on receipt” 3.Primitive description and hand over protocol operation (message flow) are mixed. (e.g. P135L21) Left over of adding the confirm and indication primitives. Srini will provide the comment and contribution

Issue IV 1.Description is mixing request and response message with request response primitives 2.Some description just say.request or.response, are those trying to say request or response messages instead (e.g. P135 L 22) Create high level comment.. Srini make comments…. Identify high level problem. The description is about the protocol behavior. There’s no protocol description at the other sections.

Issues V 1.What is MN Identifier (starting P133L23) 2.MIH Function or MIH function, not consistent throughout these pages. 1.MIHF ID or is it MN Link Id. If the reason to map the resource to the candidate query, then it is implementation issue. Add description to say “the two messages should be correlated.” 2.Change to MIH Function.

Issue VI 1.The MN, N2N, and NET convention doesn’t correspond to some description. E.g. Can MN invoke MIH_N2N_HO_Complete.reques t. 2.Status parameter is not consistent. 3.Handover Status (P149L62) is not consistent with Handover Ack+ Error Code (P126L18) 1.Fix it… 2.Add comment of status is gen by MIHF

Issue VII 1.The response primitive *_Net_* should always be: Local or Remote: Local MIHF(Mobile Node) -> MIHF (Network) e.g. P125L54. And similar for *_MN_*.request e.g. P128L51 2.What is Network Identifier? 1.Remove the labels and write the naming convention and directions in the beginning of section 7.6 MIH_SAP primitives 2.Split Link Identifier: Link Type + MN MAC Connection Identifier: Link Type + MN MAC + POA MAC And have it as Connection ID

Derived Questions Is “Local or Remote” tag required? If the destination identifier is in the primitive and described as “Local or Peer MIHF ID” or “Local MIHF ID” or “Peer MIHF ID” which one takes precedence? Suggest remove “Local or Remote” tag and base on the primitive that has “Destination MIHF ID” and its description. Define the convention used for the primitive discussion to increase readability and remove inconsistency. E.g. P139 MIH_Net_HO_Candidate_Commit.response should be only Mobile Node -> Network. NOT Mobile Node Network Primitive_Convention.doc _MN_: _NET_: the network has to be able to know peer is an mobile node. _N2N_: the network has to know the peer is a network. Should there be a section that describes the defined types such as Network Identifier, Link Identifier, Resource List, Status? Suggest add a section in section 7 that describes the defined types Primitive_Parameter_Type.doc