|
I will be writing a detailed response to your
specific issues later today.
As for the Reply Comment, sorry, my bad. I
was looking in ReplyData view and the presentation format confused my simple
mind. The comment was submitted (by me) as Technical Binding. Your
Reply Comment for the comment contributing C80216-04_144 was to
'Reject'. Sorry about the confusion.
Thanks,
Phil
----- Original Message -----
Sent: Wednesday, July 07, 2004 6:00
AM
Subject: Re: [STDS-802-16]
[STDS-802-16-MOBILE] [Handoff] HO Ad-Hoc Consen sus document, reply
comments
Phil, All
In
my "reply comment" related to C80216-04_144, item #1 was based on
misunderstanding.
Your
are welcome to address other items.
Prakash, what is "Rejected, Technical Binding" after my name? "Reply
comment" cannot be "Technical
Binding".
Vladimir
I am not sure I agree with the benefit of
the elements you are seeking to include in NBR-ADV, if the rest of the HO
Ad-Hoc agrees, I will add them to the HO Ad-Hoc Consensus
contribution.
See my comments
in-line.
Thanks,
Phil
----- Original Message -----
Sent: Tuesday, July 06, 2004 8:45
PM
Subject: RE: [STDS-802-16]
[STDS-802-16-MOBILE] [Handoff] HO Ad-Hoc Consensus document, reply
comments
Phil, Prakash,
For the two issues I raised in my reply comments, I think we
should be able to resolve them over emails. My understanding was
since there weren't enough time to go through the consensus
contributions during the last HO adhoc call as was originally planned in
the agenda, any remaining issues should be raised in the reply
comments.
Regarding my comments on contribution 146, I would like to see the
service level support and available resource information added to the
MOB-NBR-ADV, as proposed in contribution 224. We have discussed this
during the last HO adhoc call and identified several options as Prakash
has summarized in the HO adhoc call minutes. I am in favour of putting the
information into a new TLV type so that it can be optional. Also, to
allow the option of only broadcasting service level support, we can set
the 4-bit resource available field to '1111' as was suggested during the
call.
'Service level supported' is a confusing name (could be confused
with SLP use in 16e); should change it to 'Scheduling Service Supported'
to be consistent with language in 802.16-2004. Are we really getting
enough benefit out of providing this information to justify the bits, even
if it is just four bits? I am not sure. Can the HO policy manager
benefit that much from knowing what type of Scheduling Service the Target
BS supports, obtained by an untimely NBR-ADV, versus the available
mechanisms of getting real SLP responses back from MSS-to-Target BS
ranging or MSS-to-Serving BS-to-Target BS HO-REQ/RSP and backbone
inquiries?
Regarding radio resource availability advertising, we have had
discussions regarding the type and value of providing similar information
in the past, with no consensus. The problem usually has to do with
the accuracy and timeliness of the information. For instance, your
contribution's use of 'Available radio resource'; this can
easily be a very misleading number since most networks will likely
allocate excess capacity to Best Effort traffic, using up most
or all available subchannels/symbols in a given
frame, giving the illusion of saturated capacity when, in fact,
substantial high-demand service capacity may remain. Also, capacity
constraints can fluctuate dramatically in short-time intervals, making
snap-shots reported in one second intervals
unreliable.
Regarding my comments on contribution 144, I would like to get
some clarification on whether HO Indication is required for
non-contention based ranging since the target BS must have known that
the MSS is performing handover, from the fact that the target BS sends a
Fast_UL_ranging_IE to allocate the UL resource.
Right now, the only mechanism for a Target BS to become aware that
it needs to place a Fast_IE slot for non-contention based ranging is
through MSS-to-Serving BS HO-Ind with a Serving BS-to-Target BS backbone
message requesting the allocation. However, there is a contribution
seeking to make Fast_IE allocations available for ranging/Association
through the SCN-REQ/RSP mechanism. And there is another contribution
(actually, two contributions, I think) seeking to add PHY specific HO
ranging codes to OFDMA. With an OFDMA HO ranging code, an MSS could
signal directly to the Target BS its need for a Fast_IE, non-contention
based ranging opportunity, without having to request through the Serving
BS at all.
Thanks.
Mo-Han
I am 100% certain that I can resolve these
issues/questions to Vladimir and Mo-Han's satisfaction, but these are
consensus contributions and I need approval of the group to do so.
There is not going to be any time for me to negotiate acceptable
changes, make them, post them for review, revise, and
re-submit.
This is better handled via email, rather
than by teleconference, to give me an opportunity to expound upon the
rationale of the group for various decisions.
Thanks,
Phil
----- Original Message -----
Sent: Tuesday, July 06, 2004 7:09
PM
Subject: Re: [STDS-802-16]
[STDS-802-16-MOBILE] [Handoff] HO Ad-Hoc Consensus document, reply
comments
Given that these contributions have been out
there for a while, a reject reply comment could have been avoided. An
option is to have a short telecon tomorrow morning to see if these
issues can be addressed.
Vladimir,
Phil, Mo-Han, others? - can we resolve over email or should we try to
have a call tomorrow?
-Prakash
I received the following reply comments
requesting/requiring changes to the listed HO Ad-Hoc Consensus
documents and am seeking input on applying changes, if any, to the
contributions. These are Consensus contributions and I am
reluctant to unilaterally make changes to the documents without
circulating and receiving comments.
Document: C80216-04_146
Reply Comment: from Vladimir Yanover,
Accepted-Modified, Technical Binding
Accept the contribution with the
following changes:
1. Instead of "Length - Length of message
information within the iteration of N_NEIGHBOR in bytes" [which is not
a regular format element in 802.16] create a TLV that contains all
needed fields [which are PHY dependent]
2. In "HO Process
Optimization" section list network entry steps rather than related
messages
3. State [in Remedy part] that "Configuration Change
Count" [of MOB-NBR-ADV] covers also DCD/UCD parameters
4. Not clear
why "DL Physical Frequency" [of BS] is excluded. Is it a part of TLV
Encoded Neighbor information?
5. Delete "TLV specific" [length of
TLV Encoded Neighbor information] which expalins nothing. "Variable"
is enough. BTW it appears in many places in the
standard.
Document: C80216-04_146 Reply
Comment: from Mo-Han Fong, Accepted-Modifed, Technical
Binding
Add the information on service level
supported and available resource of the neighbor BS (refer to
contribution C80216e-04_224).
Document: C80216-04_144
Reply Comment: from Vladimir Yanover,
Rejected, Technical Binding
1. The contribution suggests
non-contention based MSS Initial Ranging. For that there must be a
mechanism to allocate UNICAST UL transmission opportunity for an MSS
not having yet Basic CID [e.g. using 48-bits MAC address]. Currently
802.16 lacks such mechanism, so Remedy #1 cannot be
implemented.
2. [Remedies #2-4] HMAC is a function of
AK, so success in processing of HMAC means that both sides probably
use the same AK. But it does not mean automatically that TEK state
machines at both sides are synchronized. This issue must be
investigated more thoroughly and probably more information must be
exchanged to ensure complete PKM synchronization between MSS and
target BS
3. [Remedy #5] There is no relation
between establishment of IP connectivity [it is for management
purpopses only!] and transfer of network data from old BS to new BS
and further to the MSS
4. [Remedy #6,7] Language related to
network entry steps [rather than to specific messages] should be used.
5. For capabilities exchange: I didn't
find any analysis of situation when capabilities received over
backbone do not fit those of the MSS [e.g. because of transmission
error or software problem].
Document: C80216-04_144
Reply Comment: from Mo-Han Fong, Accepted-Modifed, Technical
Binding
HO Indication may not be required for non-contention based
ranging because the target BS must have known that the MSS is
performing handover, from the fact that the target BS sends a
Fast_UL_ranging_IE to allocate the UL resource.
I am sincerely dissappointed to be receiving Technical Binding
comments on a Consensus contribution that was widely distributed and
available for comment previously, with solicitation and no additional
comments for at least two weeks.
Thanks,
Phil
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.
************************************************************************************
|