----- 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.
[Fong, Mo-Han] I agree that we should change the name to 'Scheduling
Service Supported'. Our intention of providing resource and
scheduling service supported information in MOB-NBR-ADV is
to allow the MSS to avoid unnecessary scanning and possible
associations to neighbor BSs that cannot support the service level
required by the MSS. Although it is true that the MSS will eventually
obtain the SLP information after association or HO messaging exchange,
there will be unnecessary interruption to MSS data transmission/reception
with the Serving BS due to association or unnecessary HO messaging
exchange.
[Phil] But you have to agree that
providing 'Scheduling Service Supported' is not remotely as meaningful as
getting MSS specific SLP based on Authorized/AdmittedQoSParamSet.
Getting information about scheduling service is only going to give an MSS
general information about the availability of one of three scheduling
services that may, or may not be typically associated with provisioning
the type of timing sensitive/insensitive traffic the MSS may be interested
in. I think you would be generous to categorize that type of information
as mildly informative, and I worry that presenting the information will
not change the scanning/ranging/association air interface loading and
backbone loading patterns of implementers. If we do not have reasonable
expectation that presentation of the information is going to have a
meaningful effect on traffic, I do not feel justified in adding it to the
message. I would very much appreciate additional input on this
matter. I need external corroboration of the usefulness of this
data.
Regarding the available radio resource information, the BS should
set the value according to the call admission policy (the same policy that
would be used when the BS decides whether to admit a MSS during HO or
network entry), which is typically based on average network loading rather
than based on instantaneous loading. In the call admission policy, the BS
should take into consideration of the average loading occupied by the
existing non-best-effort MSSs as well as the loading the BS intend to
offer to the existing best effort MSSs and then evaluate what is the extra
radio resource available.
[Phil] What you are describing could end up being very
vendor specific unless it is meticulously defined. And if it is
vendor specific, how do MSS know what algorithm is in use and assess the
value of the information? Over what time interval should the
'average' loading be evaluated? Should the 'average' be biased toward
current data? How does a BS value the 'average loading occupied by the
existing non-best-effort MSSs as well as the loading the BS intend to
offer to the existing best effort MSS'? While calculating air interface
loading for continous grant traffic is less problematic, how does a BS
value the loading for best effort traffic? Introducing
these types of metrics should not be accomplished lightly. We should
give very careful consideration to the language and use. Mo-Han Fong, I
would request very specific recommended language from you for
this message element explanation. Again, I would very much appreciate
additional input on this matter. I need external corroboration of the
usefulness of this data and proposed language.
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.
[Fong, Mo-Han] My understanding is if the MSS sends OFDMA ranging code, the
BS will send the CDMA_Alloc_IE, rather than the Fast_ranging_IE. The
Fast_ranging_IE is only applicable for the case when there is backhaul
communication between serving and target BS during HO or even during
association as proposed in another contribution. In that case, the MSS
does not need to send OFDMA ranging code. Please correct if that is not
the case. But if that is the case, then when the MSS receives a
Fast_ranging_IE, the MSS does not need to include the HO
indication TLV with the
RNG_REQ.
[Phil] I believe the point of the
differentiated OFDMA HO Ranging Code allocation would be to provide a
mechanism to notify the Target BS of a pending HO RNG-REQ so the Target BS
could allocate an appropriately sized, non-contention based UL slot
tied to the original HO Ranging Code and Ranging Slot. This is not
the same as a Fast_IE, but it would let us skip an essentially wasted
RNG-REG/RSP sequence where the MSS would not be able to identify that it
was in process of HO, and would not have space in the normal Initial Entry
Ranging BW allocation to accomodate all of the HO specific RNG-REQ TLV
items to inform the BS. Just using the regular Initial Ranging
codes, the extra RNG-REQ/RSP pair would be required. Per 6.3.6.5
Contention-based CDMA Bandwidth Requests for WirelessMAN-OFDMA, page 150,
line 46, it is not that the BS won't use the CDMA_Alloc_IE; the benefit of
using the HO Ranging Code is that the Target BS can make its first focused
UL BW allocation the right size to handle the oversized HO RNG-REQ that
includes all of that extra HO TLV info. So, the call flow would look
like (taken from Table 119):
|
BS |
|
SS |
|
[time to send the CDMA Initial Ranging
opportunity] |
|
|
|
send map containing CDMA Initial Ranging IE
with a broadcast Connection ID |
-----------UL-MAP------------> |
|
|
|
<---------Ranging
Code------- |
Transmit randomly selected HO Initial Ranging code in
a randomly selected Ranging Slot from available Ranging
Region |
|
[Receive Ranging
Code] |
|
|
|
Send RNG-RSP with Time & Power
Corrections and original HO
Ranging Code and Ranging Slot
Status = Continue,
repeat cycle
Status = Success, move
on |
------------RNG-RSP---------> |
Receive RNG-RSP message with HO Ranging Code and Ranging
Slot matching sent values Adjust Time & Power
parameters |
|
[time to send the next
map] |
|
|
|
send map containing anonymous UL BW
allocation suitable for HO processing of RNG-REQ including HO
specific TLVs, with original HO Ranging Code and Ranging
Slot |
------------UL-MAP-----------> |
|
|
[begin normal HO Process RNG-REQ/RSP MAC
management messaging] |
|
|
|
|
<----------RNG-REQ---------- |
Transmit RNG-REQ, including any HO specific
TLVs, and continue with regular or optimized network
entry/re-entry |
Also, the MSS would still want to
include the HO Indication TLV in RNG-REQ so the Target BS could then tell
that it really was a 16e mobile device attempt HO instead of a 16d fixed
device inadvertently using one of the HO Ranging codes, thinking it to be
just a regular Initial Ranging code.
By the way, looking at 6.3.6.4
Contention-based focused Bandwidth Requests for WirelessMAN-OFDM, it may
be possible to introduce HO Ranging Code allocations for OFDM as well,
though the low number of slots seems to make this problematic. I will have
to talk this over with an OFDM PHY guy.
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