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
> >>
>
>