Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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
From: owner-stds-802-16@listserv.ieee.org [mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Phillip Barber Sent: Tuesday, July 06, 2004 4:37 PM To: STDS-802-16@listserv.ieee.org Subject: [STDS-802-16] [STDS-802-16-MOBILE] [Handoff] HO Ad-Hoc Consensus document, reply comments 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 BindingAdd 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 |