Re: [STDS-802-16-MOBILE] Harmonization of
Phil,
Please find my comments:
The document did not suggest anything new, but rather harmonized the two
approached which are available from the Shenzen meeting.
I don't think that the sharing level should be dynamic, i.e. we should
decide upon the levels and try to fix the profiles.
The main difference between the approach of "C802.16e-04_87r2" and
"C802.16e-04_105_Enhanced Handover Re-entry" is that I support of using
the current existing messages (maybe in a shorten format - without all
TLVs) in a concatenated manner rather than to use the RNG-REQ message as
a platform to transfer other messages such as REG-REQ and SBC-REQ.
The sharing level approach was raised and agreed in the Shenzen meeting.
I was just trying to come up with appropriate normative text to be
included in the standard in order to advance by having a baseline and
stop talking in high level of should, would and could.
Probably additional change may be to put the
Backbone_Communication_level indicator in an RNG-RSP message from the
Target BS.
I'll be happy to see more concrete suggestions.
Regards,
Itzik.
-----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 8:16 PM
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.
>