Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-16] [STDS-802-16-MOBILE] [Handoff] HO Ad-Hoc Consensus document, reply comments



Title: Message
Hi Phil and all,
 
I understand that we will need the HO adhoc agreement to include the additional NBR-ADV information into the consensus text. My intention is to get HO adhoc consensus on this.
 
Please see my response to your comments below in 'green'.
 
Regards,
 
Mo-Han
-----Original Message-----
From: Phillip Barber [mailto:pbarber@broadbandmobiletech.com]
Sent: Tuesday, July 06, 2004 10:32 PM
To: STDS-802-16@listserv.ieee.org
Cc: Fong, Mo-Han [CAR:DP31:EXCH]
Subject: Re: [STDS-802-16-MOBILE] [Handoff] HO Ad-Hoc Consensus document, reply comments

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.
[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.
 
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.
 
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.
 
 
Thanks.
 
Mo-Han 
-----Original Message-----
From: Phillip Barber [mailto:pbarber@BROADBANDMOBILETECH.COM]
Sent: Tuesday, July 06, 2004 8:48 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [STDS-802-16-MOBILE] [Handoff] HO Ad-Hoc Consensus document, reply comments

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

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