stds-802-16-mobile: RE: [Handoff] IEEE802.16e Handoff Ad hoc group

["Itzik Kitroser" <itzikk@runcom.co.il>]

Dear Changhoi and all handoffers,

First, I would like to remind you that we decided to use the
IEEE-802-16-mobile reflector for the handoff activities.
Roger has put information about it at:
<http://ieee802.org/16/tge/reflector.html>
If there are questions, problems, please send mail to myself or to Roger.


Second,
Here are some responses to comments made by Changhoi,

3.4.	Packet lost(and/or delay) during HO due to
(CHKOO : I don’t know why do we have to consider this item 3.4 and its
sub-items.
Actually, all kind of QoS parameters shall be maintained, supported and
treated in the same way of QoS requirements during general communication
cases)

Itzik: Actually my intention here was:
1. Definition of some framework of requirements parameters for the HO
process.
2. I think that the QoS parameters cannot be preserved, since a specific
Target BS1 with SNR X
   may refuse some connections, while Target BS2 with SNR X-delta will
accept all the connections.
   That the decision criteria might not be so obvious.

3.6.	Security
(CHKOO : I think this item would be out of HO adhoc work scopes at this
stage)

Itzik: This Item was brought to deal with shorten security mechanisms - like
exchanging L2 security context, or even faster Authentication process.

4.1.	Support of peeking mode – enable the MS to leave the serving BS and go
seek for new BSs
(CHKOO : see comment on “Peeping Interval”, and I believe that a message
including “Activation time” described 3.5.4 would fully cover this issue
regardless of MAC or any other message. And also, actually, before
completing the HO or during initiating the HO, the MS can thoroughly find
out the candidate BS as target BS(s))

Itzik: Peeping, or Scanning Interval (thanks to Gordon for better name) is a
way to perform off-line mobile topology study. The main idea is that if the
MS has some "free" or quite time, it may try to retrieve some Physical
and/or MAC information from the potential new Target BS. This may effect the
HO decision and/or make the process more efficient.

4.2.	Serving BS publishing offline macro-system information, i.e.
information about neighbors BSs
(CHKOO : Do you mean what the information exchanges among BSs or between BS
and MS ? In the former, the description in the 802.16e specification would
be redundancy)
Itzik: I meant your first option. I think that if you will require
interoperability, that this feature should be specified by the 802.16e group
(but maybe as addendum to the Air interface)

4.3.2. What transport protocol to use (UDP?)
(CHKOO : Do we need to consider this item? I think this would be operator
proprietary items)

Itzik: Please see my response to previous comment.

4.3.4. Post-HO or Pre-HO BS<-->BS information when HO is preformed
(CHKOO : this is strongly related with 4.2 and don’t need to be mentioned in
the specification)

Itzik: Please see my response to comment on 4.2.

All,
I will be glad to hear some more feedback/point of views.

Best Regards,
Itzik Kitroser.

>-----Original Message-----
>From: chkoo [mailto:chkoo@samsung.com]
>Sent: Tuesday, February 04, 2003 8:23 AM
>To: itzikk@runcom.co.il
>Cc: yigall@runcom.co.il; vladimir.yanover@alvarion.com;
>bob_nelson@ieee.org; russmckown@yahoo.com; GAntonello@wi-lan.com;
>leiW@wi-lan.com; ShawnT@wi-lan.com; Stephen.Dick@InterDigital.com;
>hogawa@cri.go.jp; yomo@mrit.mei.co.jp; Radu@redlinecommunications.com;
>awang@proxim.com; becal.suh@samsung.com; panyuh@samsung.com;
>hhuh817@orgio.net; liaojing@samsung.co.kr; zhongch@samsung.co.kr;
>suzuki.yoshihiro@jp.panasonic.com; taki@igel.co.jp;
>tal.kaitz@alvarion.com; avif@hexagonltd.com; okelman@Airspan.com;
>MSachemo@aol.com; jocelync@ieee.org; nchu@cwlab.com;
>zhxf@samsung.co.kr;
>wanghai@samsung.com; baraax.al.dabagh@intel.com; xli@broadstorm.com;
>marianna.goldhammer@alvarion.com; yossis@runcom.co.il;
>choihk@samsung.com; eltonj@samsung.co.kr; toeve@samsung.co.kr;
>oparrow@samsung.com; jungje.son@samsung.com; binde.kim@samsung.com;
>r.b.marks@ieee.org; Brian.Kiernan@InterDigital.com
>Subject: Re: [Handoff] IEEE802.16e Handoff Ad hoc group
>
>
>
>Dear Itzik and HO AdHoc fans
>
>Above all, I'd like to say "thankyou so much' to Mr. Itzik
>To make firm text and contricution for the HO related work, it may
>require that we clarify and resolve the unclear items described in the
>document sent from Mr. Itzik.
>So, I have made some comments and questions on the agenda like
>documents
>Mr. Itzik sent previously.
>
>
>Thanks
>Changhoi Koo
>
>
>Itzik Kitroser wrote:
>
>>Hello All,
>>
>>I'm happy to announce on the opening of the
>>IEEE802.16e Handoff ad hoc group.
>>
>>As you might notice, I have put a preamble '[Handoff]'
>>at the beginning of the subject line.
>>Please use it, since it may ease on email
>>processing for some of the participants.
>>
>>In the attached document you will find some starting points
>>I have composed based on the contributions given to
>>the IEEE802.16e group concerning this issue.
>>The main focus of this group should be on MAC and management issues,
>>although requirements to the PHY layer and interaction
>>issues should not be avoided.
>>
>>I would like to receive feedback on the list of
>>topics (i.e. missing items, redundant, not relevant etc.)
>>and call for initial drafts on the handoff subject.
>>The deadline for the initial drafts, as defined in the document,
>>is two weeks from today, 04/02/03.
>>
>>Please review the proposed schedule presented in the document,
>>again, any comments/suggestions are welcome.
>>
>>The IEEE802.16e has a tight schedule, and therefore the handoff ad hoc
>>group has a tight schedule as well. The prime objective of
>this group is
>>to try and provide text to the standard dealing with the
>handoff issue.
>>
>>Thanks,
>>Itzik Kitroser
>>
>>P.S.
>>(a) I have asked Roger to try and establish an email reflector to this
>>group,
>>    to make the addressing and mail sending process simpler.
>>(b) I have included the member’s names in the document.
>>    If you aware of somebody I might have forgot, please notify me.
>>
>>
>
>