RE: [802.21] MN_HO_Commit
Hello Junghoon,
Thank you for your detailed explanation. I agree with the assumptions
you make.
In light of the latest decisions of the group where we have been
de-coupling commands and events in order to make them more discrete, I
would tend to favour the last scenario you mention where the two
commands (MIH_MN_HO_Commit and MIH_Link_Actions) are separated. I think
that this is the cleanest and most logical solution.
Regarding your point about waiting for the response before executing the
command, I see that issue as a required trade-off that we have to live
with when resources are reserved before the handover. Moreover, the fact
that the MIH_Link_Actions can be sent independently from the
MIH_MN_HO_Commit response, gives the MN the flexibility to react even if
the response is not received (e.g. timeout), as compared to the
undesirable situation where we make the actions dependent on a response
that might not arrive.
Regards,
Juan Carlos
-----Original Message-----
From: Junghoon Jee [mailto:jhjee@ETRI.RE.KR]
Sent: Wednesday, April 02, 2008 4:16 AM
To: STDS-802-21@LISTSERV.IEEE.ORG
Subject: Re: [802.21] MN_HO_Commit
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.
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.
The other way would be to separate them. In this case, the
MIH_MN_HO_Commit and MIH_Link_Actions have different 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.
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-comm
it-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
>>