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.