RE: [802.21] Ad-hoc on ES/CS discussion
Should such an ACK occur at MIH level or at transport level?
If you are using L2 transport for sending these MIH messages, for each
message (command, indication etc.) you shall get an ACK at L2 transport
level. That should be good enough.
You could have something similar at L3 as well.
Is there a need to define ACK opcode at MIHF level? (Nope)
Best regards,
-Vivek
> -----Original Message-----
> From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On Behalf Of
> Yoshihiro Ohba
> Sent: Friday, February 17, 2006 12:53 AM
> To: Eunah Kim
> Cc: STDS-802-21@listserv.ieee.org
> Subject: Re: [802.21] Ad-hoc on ES/CS discussion
>
> Hi Eunah,
>
> The ACK concept originally came up during private discussion with
> Qiaobing, Mathieu, etc. Specifically the issue was that MIH_Switch
> command can take time to process. Without ACK, the sender of
> MIH_Switch.request cannot tell whether the request gets lost or the
> request has been received but is taking time to process. Now with
> ACK, the sender can avoid unnecessary retransmission of the request
> once it receives an ACK for the request. ACK is also useful for event
> indications.
>
> Yes, ACK is useful only if the underlying transport is unreliable.
> That is why the use of ACK is optional, i.e., 'a'-flag can be always
> unset in case the underlying transport is reliable.
>
> I agree that some TIMER is needed to retransmit the message when
> ACK is requested but not returned in time.
>
> Best regards,
> Yoshihiro Ohba
>