Presentation is loading. Please wait.

Presentation is loading. Please wait.

21-07-0066-00-0021 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0066-00-0021 Title: Clarification for Handover Primitives Date Submitted: February,

Similar presentations


Presentation on theme: "21-07-0066-00-0021 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0066-00-0021 Title: Clarification for Handover Primitives Date Submitted: February,"— Presentation transcript:

1 21-07-0066-00-0021 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0066-00-0021 Title: Clarification for Handover Primitives Date Submitted: February, 19, 2007 Presented at IEEE 802.21 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.

2 21-07-0066-00-0021 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-07-0066-00-0021 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…

4 21-07-0066-00-0021 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.

5 21-07-0066-00-0021 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

6 21-07-0066-00-0021 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.

7 21-07-0066-00-0021 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.

8 21-07-0066-00-0021 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

9 21-07-0066-00-0021 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

10 21-07-0066-00-0021 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 21-07-0069-00-0021-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 802.21 defined types such as Network Identifier, Link Identifier, Resource List, Status? Suggest add a section in section 7 that describes the 802.21 defined types. 21-07-0068-00-0021-Primitive_Parameter_Type.doc


Download ppt "21-07-0066-00-0021 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0066-00-0021 Title: Clarification for Handover Primitives Date Submitted: February,"

Similar presentations


Ads by Google