RE: stds-802-16-mobile: Handoff/Sleep-mode Ad Hoc working document
Dear Vladimir and all,
Supporting make-before-break mode can be not very trivial when related to
simultaneous data reception from different BS.
Although, it does not necessary mean that make-before-break imply such
mechanism only.
The Make-before-break philosophy can be used for context transferring (e.g.
handoff to target BS) while not interrupting the data session from the
Serving BS, and achieving "smooth" session transition from serving to target
BS (which can be supported with mobile IP). I believe that such ideas can be
quite easily employed without a need to duplicating packets, and/or
timestamping PDUs for synchronization. Please also notice the
differentiation of such "logical" make-before-break handoff and "physical"
soft-handoff a-la CDMA style, for example.
I'll try to upload a contribution on such suggestion.
Regards,
Itzik.
> -----Original Message-----
> From: Vladimir Yanover [mailto:vladimir.yanover@alvarion.com]
> Sent: Monday, July 14, 2003 13:33
> To: 'itzikk@runcom.co.il'; stds-802-16-mobile@ieee.org
> Subject: RE: stds-802-16-mobile: Handoff/Sleep-mode Ad Hoc
> working document
>
>
> Itzik and All,
>
> In this question on make-before-break I'm trying to understand
> what is this
> X that should be made
> before the previous X gets broken. In cellular telephony X is a phone call
> or it may be similar data
> streaming service with data units arriving to destination with low jitter
> ("low" means "of order of
> wireless frame"). In these terms make-before-break means that at some time
> interval two data flows
> are delivered to the terminal from two BSs with identical data units, both
> arriving to MSS more or less
> synchronously.
>
> Now, lets consider 802.16 MAC connection which carries Service Flow where
> Tolerated Jitter parameter is
> set to value of order of MAC frame (e.g. 4 frames). Then in
> make-before-break MSS probably has
> to receive data from two BSs simultaneously: e.g. at even frames
> from BS#1,
> at odd frames from BS#2.
> It seems quite complicated as needs interaction of SS and two BSs, special
> type of scheduling (to know
> that the MSS is absent each 2nd frame). We have probably to
> employ some sort
> of time stamps or numbers
> for SDUs to discard duplicates and to check the level of synchronization
> between two streams from two BSs
> [who assigns these numbers?] etc.
> Now, what happens at the backbone? The backbone should have an ability to
> recognize
> POTENTIAL new location of the MSS, DUPLICATE packets and forward copies to
> new location while the
> original data stream goes to the old location. I am not aware of mobile IP
> protocols that would enable such activity.
> So we would need to specify by ourselves all the corresponding entities at
> the backbone and their operations.
>
> I would like to understand how can we benefit from this mode and then
> whether the benefit is worth the effort.
>
> On the other hand, if an MSS has prepared everything [using Association
> procedure] for final jump to new BS,
> the jump itself may take 1 or 2 frames. It seems to be the best possible
> value for the jitter component added by
> the HO itself.
>
> Vladimir
>
> -----Original Message-----
> From: Itzik Kitroser [mailto:itzikk@runcom.co.il]
> Sent: Tue, July 08, 2003 11:05 AM
> To: Vladimir Yanover; stds-802-16-mobile@ieee.org
> Subject: RE: stds-802-16-mobile: Handoff/Sleep-mode Ad Hoc
> working document
>
>
> Dear Vladimir,
>
> My position is that make-before-break should be defined and
> considered (and I intend to propose text for that).
> The differentiation between make-before-break and break-
> before-make, can be viewed from several aspects, for example:
> 1. All L1 and L2 procedures required to perform the HO
> 2. Session continuation, which might be out of the scope of
> our work, but maybe a reference of how L2 and L1 are used
> (notifications) to provide L3 information for ensuring
> efficient transition.
> 3. Protocol requirements (here you can see a difference
> between real-time data and bursty oriented data) and how the
> type of HO effects/relates-to those requirements.
>
> I think that we have to fill the 1.3.1.2.4 "HO completion"
> section, in the make-before-break, an example of required
> definition is HO transaction completion signaling, for
> transferring session context to the target BS. Any text
> about "post HO" operation which are required for completion
> of the HO procedure (and provide hooks for L3 HO protocol),
> is welcome, regardless of the HO type.
>
> Itzik.
>
> > -----Original Message-----
> > From: owner-stds-802-16-mobile@majordomo.ieee.org
> > [mailto:owner-stds-802-16-mobile@majordomo.ieee.org]On
> Behalf Of
> > Vladimir Yanover
> > Sent: Tuesday, July 01, 2003 12:29
> > To: stds-802-16-mobile@ieee.org
> > Subject: RE: stds-802-16-mobile: Handoff/Sleep-mode Ad Hoc
> working
> > document
> >
> >
> > Hello,
> >
> > A question on 1.3.1.2.4 "HO completion": Post HO operations
> > It is mentioned that Post-HO operations are mostly
> applicable
> > if make-before-break HO is supported.
> > The question is whether we expect that a definition of
> > make-before-break HO
> > will be provided. Meanwhile there are no such definition.
> May be,
> > the reason
> > is that differentiation between make-before-break and break-
> before-make is
> > not applicable
> > to data communication at the same extent as to GSM/3G voice
> channels?
> > So I ask whether there are Post-HO issues not specific for
> > make-before-break?
> > It would be useful to see what is the position of Ad-Hoc
> group.
> >
> > Vladimir
> >
> >
> > -----Original Message-----
> > From: Itzik Kitroser [mailto:itzikk@runcom.co.il]
> > Sent: Thu, June 26, 2003 11:07 PM
> > To: stds-802-16-mobile@ieee.org
> > Subject: stds-802-16-mobile: Handoff/Sleep-mode Ad Hoc
> working document
> >
> >
> > Hello All,
> > I have uploaded a revision of the Handoff and sleep mode
> working document.
> > <http://download.mobile.wirelessman.org/C80216e-03_NNr1.pdf>
> > This is the latest version of the Tge document (only with
> handoff
> > and sleep
> > mode relevant text) with modification I made following the
> > discussion in the
> > group.
> >
> > There are plenty of open items, just follow the red text or
> TBDs, Plus the
> > contributions which we did not finished discussing.
> >
> > I quite disappointed from the participation level in this
> group, since it
> > seems that only four active members are doing an active
> discussion.
> >
> > The deadline for Tge comments is 14 of July. In order to
> have a decent
> > document until this deadline, people should actually start
> doing active
> > work, and not just passive reading.
> >
> > I'm especially waiting for contributions regarding the
> empty
> > sections which
> > can be found inside the current tge draft (and in the
> working document).
> >
> > Please, any of you who are willing to put the effort,
> please submit
> > comments/contributions ASAP.
> >
> > Regards,
> > Itzik.
> >
> >
> > > -----Original Message-----
> > > From: owner-stds-802-16-mobile@majordomo.ieee.org
> > > [mailto:owner-stds-802-16-mobile@majordomo.ieee.org]On
> Behalf Of Itzik
> > > Kitroser
> > > Sent: Thursday, May 22, 2003 11:28
> > > To: stds-802-16-mobile@ieee.org
> > > Subject: stds-802-16-mobile: Handoff/Sleep-mode Ad Hoc
> working document
> > >
> > >
> > > Hello All,
> > >
> > > I have uploaded a working document for the Handoff and
> > sleep-mode ad hoc.
> > > The document can be found at:
> > > <http://download.mobile.wirelessman.org/C802.16e-
> 03_NN.doc>
> > >
> > > Anyone which is interested in the handoff and/or sleep-
> mode issues is
> > > welcome to provide feedback.
> > > If anyone would like to add items to discuss, please also
> response.
> > >
> > > Regards,
> > > Itzik.
> > >
> > >
> > >
> >
> >
> >
> >
> > This mail passed through mail.alvarion.com
> >
> >
> **************************************************************
> ****
> > **********
> > ********
> > This footnote confirms that this email message has been
> scanned by
> > PineApp Mail-SeCure for the presence of malicious code,
> vandals & computer
> > viruses.
> >
> **************************************************************
> ****
> > **********
> > ********
> > This mail was sent via mail.alvarion.com
> >
> >
> **************************************************************
> ****
> > ******************
> > This footnote confirms that this email message has been
> scanned by
> > PineApp Mail-SeCure for the presence of malicious code,
> vandals &
> > computer viruses.
> >
> **************************************************************
> ****
> > ******************
> >
>
>
> This mail passed through mail.alvarion.com
>
> ******************************************************************
> **********
> ********
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals & computer
> viruses.
> ******************************************************************
> **********
> ********
> This mail was sent via mail.alvarion.com
>
> ******************************************************************
> ******************
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals &
> computer viruses.
> ******************************************************************
> ******************
>