IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: MIH Registration Amendments Date Submitted: Nov.13, 2006 Submitted for discussion and possible inclusion in the draft against LB_1a comment Authors or Source(s): Xiaoyu Liu Abstract: This contribution proposes MIH protocol registration amendments, mainly for reregistration updated with the comments in New Jersey Ad Hoc.

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

Motivation for Re-Registration Re-Registration in current draft D2.0 –Mentioned as part of the registration primitive Section , pp.93, only one line#29: Re-Registration… ‘Re-Registration scope to be defined’. –No specification in D2.0 Technical issues regarding Re-Registration –Use Cases applicable –Differences between Re-Registration and Registration

2 Use Case 1 With Registration? –Frequent registration and deregistration –Serving POS has to create/release Session ID and states (associated with lifetime) frequently MIHF MN.11 AP1.11 AP2.11 AP3.11 APn Serving POS.16 BS Candidate POS … 1.Registration Session ID #1 3.Deregistration Session ID #1 Session ID #N 4.Registration Session ID #2 7.Registration Session ID #3 Session ID #NN 6.Deregistration Session ID #2 9.Deregistration Session ID #

Use Case 1 (cont.) With some kind of “Re-Registration” to improve the overall situation? –In stead of perform deregistration when the old lower layer connection is broken, why not try to refresh the current session… If MN knows it will connect (break-before-make) or it has been connected (make-before-break) to the next AP AND that AP is served by the same Serving POS (not that difficult to do so) –Serving POS just maintains the same Session ID and states (associated with lifetime). –Then what if it cannot (or fail to) perform re-registration? – Has to resort to Deregistration and Registration. MIHF MN.11 AP1.11 AP2.11 AP3.11 APn Serving POS.16 BS Candidate POS … 1.Registration Session ID #1 Deregistration Session ID #1 Registration of a new Session ID #NN 3. Re-Registration of Session ID #1 Session ID # Re-Registration of Session ID #1 …

Use Case 2 The MN stays in the same place and the underlying layers works well, but the lifetime of an established Session expires: –Without any kind of refreshing mechanism The session has to go to the end by deregistration And MIHF in MN/Network has to perform registration procedure to create a new Session –Why not just refresh the existing Session? By periodically send some Re-Registration message to refresh that session

Re-Registration – Key Points The difference between registration and re- registration –Registration establishes a new session; a new Session ID is created; –Re-registration refreshes an existing session; no need to create a new session ID Thus in nature, the procedures regarding registration may include: – Registration – Deregistration – Re-Registration

Re-Registration – Proposed Texts Comment #266 to propose the primitives for MIH Re-registration –Remedy #3 in contribution –Key points: existing session ID in the semantics of requests Comment #378 to propose the messages for MIH Re-registration –Remedy #4 in contribution

Other Amendments Comment #215 to propose texts for section –Remedy 1 in contribution –Brief description of the procedures Registration –between MIHF in MN and MIHF in a serving network. –between MIHF in a serving network and detected network. Deregistration –between MIHF in MN and MIHF in a serving network. –between MIHF in a serving network and detected network. Re-Registration (as illustrated in this presentation) Comment #267 to add Session ID in the deregistration primitives. –The peer MIHF shall know which session it should release.

Open Issues to be discussed (future work) The indication and confirm primitives shall be added. Abnormal cases in MIH registration shall be considered: –Registration failure cases, e.g., registration rejected. –Lifetime expiry for active sessions –Link layer failure due to unreliable lower layer links