Re: [STDS-802-16-MOBILE] Harmonization of
Itzik and all,
The work that was done to formulate 105 at Shenzhen was done so that we
could all have a common language for discussion, and so that we all could
see the variety of issues surrounding HO models and optimization
opportunities that may be available. The structure and language of 105 were
never intended to be the actual structure and language of the SOLUTION
mechanism, only some problem definition.
I have given you my rationale for a more flexible solution mechanism based
on HO optimization flags in the RNG-RSP indicating to the MSS undergoing
current HO re-entry at a Target BS which entry process steps may be skipped
during the current re-entry attempt based on information obtained by the
Target BS over the backbone. This mechanism conveniently allows us to
bypass issues of how the Target BS got the information, why it got some
information and not other information, how the network may be organized to
accomplish common MSS context management, etc...all things that are either
beyond the scope of our current work, or evolving problem areas that will
continue to see change. The HO optimization flag mechanism solves the
outcome of the problem, what steps can safely be skipped on HO re-entry,
versus the problem itself, what are all of the permutation of optimization
models that can be addressed with specific and unique solution models for
each. By my estimation, solving the outcome of the problem is more
efficient than solving the problem in that we don't have to anticipate all
models--the solution accomplishes solving all solution combinations by
inference. I will get some language worked out today and out to the group.
But likely not before the conference call (I have to leave for the airport
in a very few hours here to catch my flight back to the States).
Here are my critiques of the two contributions you discuss as basis for the
merged contribution:
C802.16e-04_87r1 Handoff text clarifications and enhancements
Overview:
Contribution proposes revisions to HO Process language to support
message-loop short-cut optimizations that can be available with varying
degrees of MSS Context transfer across the backbone from Serving BS to
Target BS.
Comments:
Good idea, and right place to execute. In-line with previous discussions on
the matter.
Language could use a good scrubbing and re-work. Contribution needs to be
re-worked and merged with contributions promoting RNG-RSP flags indicating
which steps can be omitted during an optimized MSS HO, and with BS Context
Management ID and Sector ID logical identifiers.
C802.16e-04_105_Enhanced Handover Re-entry
Overview:
Contribution has several sections. First section creates distinction
between logical and physical BS for later use as multi-sectored BS; and
further creates definitions for three 'levels' of backbone communication
enabling three optimized sets of HO step reduction. The second section
discusses a bandwidth polling mechanism for use at the Serving BS and Target
BS during HO. The third section discusses how to actually use the various
'levels' of backbone communication aided HO messaging to reduce the re-entry
handshaking process.
Comments:
The contribution has some good points, but I dislike the method selected for
accomplishing the goals. Also, the document does not propose appropriate
language changes to the 6.3.20 HO Process section.
I think the definition of the 'levels' is unnecessary and disruptive. No
need to create arbitrary designations and then a detailed set of
instructions on implementing. I think it is preferable to simply employ a
set of flags in the RNG-RSP message at the Target BS where the Target BS,
based on information available over the backbone, informs the MSS of which
steps may be omitted during the current HO re-entry attempt at the Target
BS. This is a simpler approach and avoids having to specify every possible
optimized 'levels' solution with its specific application. Also, it avoids
having to specify uncomfortable concepts like shared MSS context
management-concepts beyond the scope of 16e. But we still get the benefit
anyway. It may be that the author simply intends that these messages
provide some insight to the MSS as to what to expect if it were to attempt
an HO to a given Target BS. If so, then putting it into the MOB_BSHO-RSP is
far too late in the process, where a decision has already, effectively been
made.
I agree that having the HMAC tuplet is a good idea in the RNG-REQ to give
quick validation for security (when appropriate backbone information is also
present).
The contribution's discussion of a mandated bandwidth request mechanism for
the Serving BS and Target BS during HO seems like over specification. There
is nothing that prevents these allocations in the current document. Should
implementers choose to do this optimization, they are certainly free to do
so. But I am not at all sure it is necessary for us to mandate its use.
And making it optional is pointless since it is already, essentially
optional by inference.
Thanks,
Phil
----- Original Message -----
From: "Itzik Kitroser" <itzikk@runcom.co.il>
To: "'Phillip Barber'" <pbarber@BROADBANDMOBILETECH.COM>;
<STDS-802-16-MOBILE@listserv.ieee.org>
Sent: Thursday, June 17, 2004 1:53 AM
Subject: 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.
> >
>
>
>