Re: [STDS-802-16-MOBILE] Harmonization of
A thorough analysis of the C802.16e-04_87r2 proposal is necessary but from what I see it looks like a very interesting proposal that may achieve simplification by categorization. So, at present I support the C802.16e-04_87r2 proposal.
Branislav
> -----Original Message-----
> From: owner-stds-802-16-mobile@listserv.ieee.org
> [mailto:owner-stds-802-16-mobile@listserv.ieee.org]On Behalf
> Of Phillip
> Barber
> Sent: Wednesday, June 16, 2004 11:16 AM
> To: STDS-802-16-MOBILE@listserv.ieee.org
> Subject: Re: [STDS-802-16-MOBILE] Harmonization of
>
>
> Itzik and all,
>
> I strongly disagree with this approach. As far as impacting
> state machines,
> I think you are dramatically overstating the effect. Indeed,
> I think it far
> easier to implement RNG-RSP HO transaction optimization
> flags, specific for
> each step of network re-entry, than to use some type of
> defined arbitrary
> logical coding scheme where HO optimized profile 'a' looks
> like this, and
> 'b' looks like this. HO optimized profile sets require a
> different set of
> procedures for each optimized profile, divergent and
> independent SDL models,
> and you account for each different profile separately. Thus,
> if you add a
> new profile, you have to add a new process. Messy and unecessary. HO
> transaction optimization flags represent a simple
> modification to existing
> HO SDL (i.e. If can skip SBC-REQ/RSP, skip it, Else process
> SBC-REQ/RSP).
> And support of the HO optimization flags would by inference
> support ALL
> optimized HO mechanisms that achieve optimization through
> minimizing network
> re-entry handshaking, whether those optimized HO mechanisms
> are currently
> defined or are to yet to be envisaged. Also, there is nothing in HO
> transaction optimization flags that keeps you from padding multiple
> unsolicited RSP messages into a single frame, just as you
> suggest for HO
> optimized profiles, all other considerations being equal.
>
> Sorry about not being more available over the last two weeks,
> but have been
> traveling and completely buried. My time will improve after
> returning to
> the States tomorrow.
>
> Thanks,
> Phil
>
> ----- Original Message -----
> From: "Itzik Kitroser" <itzikk@RUNCOM.CO.IL>
> To: <STDS-802-16-MOBILE@listserv.ieee.org>
> Sent: Wednesday, June 16, 2004 11:19 AM
> Subject: [STDS-802-16-MOBILE] Harmonization of
>
>
> > Hello all,
> >
> > I have uploaded document named "C802.16e-04_87r2" to the
> handoff ad hoc
> > upload directory.
> > It is my attempt to harmonize documents "C802.16e-04_105_Enhanced
> > Handover Re-entry" and "C802.16e-04_87r1"
> >
> > I have used the descriptive text of C802.16e-04_87r1 and added
> > informative and normative definitions of Communication shared levels
> > concepts from "C802.16e-04_105_Enhanced Handover Re-entry"
> >
> > One point though, I don't agree with the concept which was
> presented at
> > C802.16e-04_105_Enhanced Handover Re-entry of changing the RNG-REQ
> > message and adding to it TLVs with different processes.
> > I think that such approach breaks communalities of MAC
> behavior with TGd
> > and other MAC state machines.
> > The approach that was taken is to clearly define the communication
> > sharing level, and which procedure is required according to
> the working
> > level.
> > The optimization of the process is done in two levels;
> first, all the
> > network entry messages may be transmitted in a consecutive
> way, in one
> > frame (assuming to have enough allocation from the BS).
> > Second, according to the sharing level, some of the network
> entries may
> > be skipped. I agree that this adds additional MAC behavior,
> but it does
> > it in a high level and not changes the local behavior per
> process (e.g.
> > state machine).
> >
> > I did not receive any additional inputs from Phil and
> Jung-Won Kim, and
> > I'm using this medium to seek for comments from the entire
> ad hoc group.
> >
> > Thanks,
> > Itzik.
> >
>