Re: [802.21] MN_HO_Commit
Junghoon,
Thanks for creating the contribution. I will incorporate it into the new
draft.
regards,
-Qiaobing
Junghoon Jee wrote:
> Hi Qiaobing,
>
> Please refer the contribution,
> https://mentor.ieee.org/802.21/file/08/21-08-0110-00-0000-mih-mn-ho-commit-wrap-up.doc
>
> Best Regards,
> Jungnhoon
>
> ----- Original Message -----
> From: "Qiaobing Xie" <qiaobing.xie@GMAIL.COM>
> To: <STDS-802-21@LISTSERV.IEEE.ORG>
> Sent: Thursday, April 17, 2008 12:15 AM
> Subject: Re: [802.21] MN_HO_Commit
>
>
>
>> Junghoon,
>>
>> Could you put the changes that are necessary to implement the ideas
>> below in a contribution?
>>
>> regards,
>> -Qiaobing
>>
>> Junghoon Jee wrote:
>>
>>> Thank you Yoshi and JC for the feedback!
>>>
>>> According to the discussions we had, let's revisit the MN_HO_Commit to notify the Serving PoS of the decided target information.
>>> This surely be the remote command. Also, the current MIH_Link_Handover_Imminent will be preserved as only having the intra-tech feature.
>>> One more point is that we may add one flag to that MN_HO_Commit related with the resource reservation as suggested by Yoshi.
>>> Let me have the feedbacks and let's close this issue.
>>>
>>>
>>> Best Regards,
>>> Junghoon
>>>
>>> ----- Original Message -----
>>> From: "Yoshihiro Ohba" <yohba@TARI.TOSHIBA.COM>
>>> To: <STDS-802-21@LISTSERV.IEEE.ORG>
>>> Sent: Wednesday, April 02, 2008 9:55 PM
>>> Subject: Re: [802.21] MN_HO_Commit
>>>
>>>
>>>
>>>
>>>> Hi Junghoon,
>>>>
>>>> Thank you for clearly describing the alternatives and issues. Please
>>>> see my comment below.
>>>>
>>>> On Wed, Apr 02, 2008 at 05:16:02PM +0900, Junghoon Jee wrote:
>>>>
>>>>
>>>>> Hi Yoshihiro,
>>>>>
>>>>> Thank greatly for sharing an insightful idea to resolve the issue.
>>>>> I agree that can be a possible way to move forward.
>>>>>
>>>>> Let me share more thought on that to clearly resolve this issue not to revisit again at this important stage of our specification.
>>>>>
>>>>> I would say that we need to decide whether to couple the following two functional components when invoking an MIH primitive.
>>>>> 1) Informing the Serving PoS about the decided target network information.
>>>>> 2) Switching the active interface from the serving to the target network.
>>>>>
>>>>>
>>>> I don't think couping the above two procedures is a good idea.
>>>> Coupling the two procedure would make sense only if the
>>>> MIH_Link_Action command for Procedure (2) is a remote command (and
>>>> hence it requires one more MIH message exchange), but I believe the
>>>> MIH_Link_Action command in this case is a local command, so separating
>>>> the two procedures should not have any performance impact.
>>>>
>>>>
>>>>
>>>>> If we couple them, the MIHF shall send the notification message to the Serving PoS and
>>>>> execute the Link_Action.request to switch the active connection *at the same time*.
>>>>> We can use both remote MIH command or event message to notify the Serving PoS of the decide target network information.
>>>>>
>>>>> There are several issues we need to think about.
>>>>>
>>>>> A) The use of MIH command: MIH_MN_HO_Commit
>>>>> The issue is that when the MIHF should invoke the MIH_MN_HO_Commit.confirm primitive to notify the MIH User of the command results.
>>>>> Should it be done when receiving the Link_Action.confirm or when receiving the MIH_Command Response message from the Serving PoS?
>>>>> This issue mainly comes from performing the dual functions through executing an single MIH_MN_HO_Commit.
>>>>> Also, in the Break-Before-Make mode, there is a problem of not receiving the MIH_Command Response message
>>>>> because of closing the active connection before receiving the MIH_MN_HO_Commit Response from the Serving PoS.
>>>>>
>>>>> B) The use of MIH event: MIH_Link_HO_Imminent
>>>>> We can utilize the MIH Event (MIH_Link_Handover_Imminent) which is in nature one-way without requiring the confirmation from its peer.
>>>>> However, in this case the MIH Event is produced by the MIHF itself when receiving a certain MIH Command primitive from the MIH User.
>>>>> AFAIK, this is somewhat different with the existing MIH Event architectural model where the MIH Event is generated when receiving the corresponding Link Event from the lower layers.
>>>>> One way to solve this issue would be to define the MIH_MN_HO_Commit as a one way indication message not requiring the response from the Serving PoS.
>>>>> The similar choice is taken in the IEEE802.16e by defining the one-way MOB_HO-IND *indication* message.
>>>>>
>>>>>
>>>> If we go with separting the two procedures, we don't have to think
>>>> about the above issues.
>>>>
>>>>
>>>>
>>>>> The other way would be to separate them. In this case, the MIH_MN_HO_Commit and MIH_Link_Actions have differen\t functionalities.
>>>>> We need to define the major function of the MIH_MN_HO_Commit as the target network notification and the MIH_Link_Actions as the link switch commands.
>>>>> When the target network is decided, the MIH User invokes the MIH_MN_HO_Commit.request to notify the Serving PoS of the decided target network information.
>>>>> After receiving the MIH_MN_HO_Commit Response from the Serving PoS, the MIHF invokes the MIH_MN_HO_Commit.confirm primitive.
>>>>> The MIH User after confirming that the Serving PoS identifies the target network information through the MIH_MN_HO_Commit.confirm,
>>>>> it invokes the MIH_Link_Actions.request to switch the active interface from the serving to the target network. The Link_Actions primitives are executed following that.
>>>>> One issue in this case is that the MIHF should wait to receive the MIH_MN_HO_Commit Response from the Serving PoS before executing the link switch command.
>>>>> This can be a problem affecting the overall handover performance because it is highly desirable to immediately try to connect to the target link not waiting something to happen at the old link which is degrading rapidly. This problem becomes more serious when the resource reservation is coupled with the target network notification.
>>>>>
>>>>>
>>>> Depending on implementation, MIH User on MN can issue an
>>>> MIH_Link_Action.request primitive without waiting for an
>>>> MIH_MN_HO_Commit.confirm primitive. In other words, there is no
>>>> restriction in our specification that prohibits two or more
>>>> outstanding commands within an MIHF. Thanks to our specification,
>>>> there should be no issue with separating the two procedures.
>>>>
>>>> Best Regards,
>>>> Yoshihiro Ohba
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Any thoughts?
>>>>>
>>>>> Best Regards,
>>>>> Junghooon
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Yoshihiro Ohba" <yohba@TARI.TOSHIBA.COM>
>>>>> To: <STDS-802-21@LISTSERV.IEEE.ORG>
>>>>> Sent: Tuesday, April 01, 2008 12:28 AM
>>>>> Subject: Re: [802.21] MN_HO_Commit
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi Junghoon,
>>>>>>
>>>>>> I agree with adding MIH_MN_HO_Commit as a remote command. However, we
>>>>>> should not change the definition of MIH_Link_Handover_Imminent to
>>>>>> include inter-tech handover. It's basically a *link* event and not
>>>>>> possible to use it to indicate inter-tech handover unless there is
>>>>>> some unwritten assumption.
>>>>>>
>>>>>> Instead of changing the definition of MIH_Link_Handover_Imminent to
>>>>>> include inter-tech handover, I suggest MIH_MN_HO_Commit.request
>>>>>> primitive to have one new parameter to indicate whether resource
>>>>>> reservation is coupled with the MIH_MN_HO_Commit command or not. In
>>>>>> the case of coupling with resource reservation, an MIH_MN_HO_Commit
>>>>>> response message will be returned from the PoS only after the resource
>>>>>> reservation is made. In the case of not coupling with resource
>>>>>> reservation, an MIH_MN_HO_Commit response message will be returned
>>>>>> from the PoS immediately after the PoS receives an MIH_MN_HO_Commit
>>>>>> request message.
>>>>>>
>>>>>> Regards,
>>>>>> Yoshihiro Ohba
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 31, 2008 at 10:03:42AM +0900, Junghoon Jee wrote:
>>>>>>
>>>>>>
>>>>>>> Dear Ajay and all,
>>>>>>>
>>>>>>> We have a long history about the MN_HO_Commit.
>>>>>>> We made it as a local command from the remote in the D8.0 owing to the MIHF ID issues and
>>>>>>> dropped it in the D9.0 because the same functionality can be provided through the MIH_Link_Actions.
>>>>>>>
>>>>>>> Now, the #2217 in this round of SB Recirc #2 did pointed out that
>>>>>>> we need that MIH_MN_HO_Commit again and also as a remote command.
>>>>>>> The main motivation comes from the need for the Serving PoS to identify the decided target network information
>>>>>>> in the mobile-initiated handover case.
>>>>>>> The detailed remedy following this line is provided in the 21-08-0062-00-0000-mih-mn-ho-commit.doc
>>>>>>>
>>>>>>> There are several issues we need to think about.
>>>>>>> To encourage the discussion and wrap up this issue, I posted the contribution,
>>>>>>> https://mentor.ieee.org/802.21/file/08/21-08-0096-01-0000-mih-mn-ho-commit-revisited.ppt.
>>>>>>> We need to choose the way to move forward by referencing the conclusion part of this contribution.
>>>>>>>
>>>>>>> Ajay, it's actually third 'ping' to you. :-)
>>>>>>> Please take your time to see the contribution and provide the feedback.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Junghoon
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>> >