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



Vladimir and all,
 
Here is my response to your Reply Comment items on the two HO Ad-Hoc Consensus contributions.  Per your later email instructions, I will omit response to your comment item#1 for C80216e-04_144 since it was made based on a misunderstanding.
 
Thanks,
Phil
 

Document: C80216-04_146
Reply Comment: from Vladimir Yanover, Accepted-Modified
 
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]
You are absolutely correct that this is not a common mechanism in the standard.  While it would be preferable to do as you suggest, that would result in significantly larger bit allocations (for the TLV encoding of each message element) than would be the case using the current structure.  And we are very, very sensitive to increasing the size of this message since it is sent once per second on the worst possible coding. If you can suggest an alternative that would conserve bit count, I am sure to endorse it. If not, I think we should go with this mechanism and see if we can come-up with a better way in the future.

2. In "HO Process Optimization" section list network entry steps rather than related messages
 
We could do that, though it might be less precise to uninformed readers of the standard. I would like to hear other opinions on that.

3. State [in Remedy part] that "Configuration Change Count" [of MOB-NBR-ADV] covers also DCD/UCD parameters
 
I agree that it is useful to make the distinction and will apply the change.

4. Not clear why "DL Physical Frequency" [of BS] is excluded. Is it a part of TLV Encoded Neighbor information?
 
We had a long discussion about this, and other PHY Frequency identifiers that are not in DCD/UCD (either not in any, or not for some PHY types) but are useful in making so MSS don't have to scan the entire spectrum or guess at the channel configuration options. The answer was that since 16e is concerned only with licensed frequency and since licensed operators would have appropriate information available to configure MSS, MSS could get this operator specific information from a SIM card, configuration file, or other configuration programming to static memory. Thus, providing the information once a second in this message was redundant and a tremendous waste of air time.

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.
 
I agree and will make the appropriate change.

 
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.
 
Marked as satisfied per your email.
 
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
 
There is a contribution document that deals with this. I think it is a merge document between C80216e-04_200 & 206. The document is pending approval, hopefully, as a Security Ad-Hoc Consensus contribution. But it is appropriate for us to have it here with expectation that we are going to solve the security authentication and messaging mechanics.
 
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
 
Actually, there is. We discussed this at length as well. We don't want the MSS re-entering the network and requesting a new IP Address (assuming that a new IP Address would be required) if it has data pending from its previous IP Address attachment because this could cause higher layers to kill the traffic back on the network, depending on the network configuration, or for the MSS to reject it the traffic since it no longer uses the obsolete IP Address. The idea was to have a mechanism to delay the MSS requesting for a new IP Address until after all pre-HO cached or forwarded data had been transmitted at the new Serving BS. Since we don't have a MAC management message mechanism for a BS to direct an MSS to acquire/re-acquire a Network Address, this was the approved mechanism.
 
4. [Remedy #6,7] Language related to network entry steps [rather than to specific messages] should be used.
 
We could do that, though it might be less precise to uninformed readers of the standard. I would like to hear other opinions on that.
 
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].
 
It is not clear from your comment to which item your are referring. Please be more specific. The only general comment I can make in the area of capabilities exchange is that MSS capabilities almost certainly will not change during HO, but Serving BS and Target BS might, likely will not, but might.