----- 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