Re: [STDS-802-16] [STDS-802-16-MOBILE] [Handoff] HO Ad-Hoc Consen sus document, reply comments
Phil, All
See my comments below
Thanks
Vladimir
-----Original Message-----
From: Phillip Barber [mailto:pbarber@BROADBANDMOBILETECH.COM]
Sent: Wednesday, July 07, 2004 10:18 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
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.
[VY] See below the structure: same bit count + 1 byte per BS.
BTW, is it really critical to optimize message transmitted once a second in
BB system capable to transmit e.g. 1000 network packets per sec
[5 MHz channel, packet ~ 400 bytes, low modulation]?
In #146
---------------------------------------------
For (j=0; j< N_NEIGHBORS; j++){
Length
Neighbor BS ID
Preamble Index
PHY Profile ID
HO Process Optimization
DCD Configuration Change Count
UCD Configuration Change Count
TLV Encoded Neighbor information
}
-----------------------
Suggested
For (j=0; j< N_NEIGHBORS; j++){
compound TLV
}
<compound TLV> {
Type <---------------- here is the only difference
Length
Value {
Neighbor BS ID
Preamble Index
DL Physical Frequency ???
PHY Profile ID
HO Process Optimization
DCD Configuration Change Count
UCD Configuration Change Count
TLV Encoded Neighbor information
}
}
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.
My understanding is that referencing to NW entry steps is more precise as
addresses also response messages, timers etc.
Probably we should be more oriented to readers that do understand relation
between step of NW entry and messages used in this step.
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.
[VY] If so, why cannot preamble index and all other data be distributed
same [unspecified] way?
If we already broadcast this data at MAC level, most valuable data must be
present
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.
[VY] I disagree with such interpretation of 802.16 procedures. Suggested in
THIS contribution text says that if HMAC is OK, then "PKM-REQ/RSP sequence
may be omitted " without any further conditions. The contribution is
associated with separated comment. Each comment must be considered an
individual item to be accepted/modified/rejected.
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.
[VY] It is not clear to me whether you agree that IP address [6.3.9.10
Establish IP connectivity] is used exclusively for
management i.e. for packets carrying at secondary management connection
[SNMP, TFTP etc.]?
For example, in 6.3.9.9.1 "The SS may include the IP Version (11.7.4)
parameter in the REG-REQ to indicate which versions of IP it supports on the
Secondary Management Connection." There was a long discussion in TGd how to
make optional both acquisition of the IP address and creation of SM
connection.
Therefore network traffic must use IP address[es] another than the one
acquired during NW entry or re-entry. The standard does not explain which IP
addresses are used for traffic transfer and how were they acquired.
Therefore, even if IP address for SM connection became outdated, "traffic"
IP address[es] may still be valid, e.g. if configured statically which is
legal and completely acceptable in mobile network.
Specifically the contribution says "MSS may re-establish IP connectivity and
new Serving BS may send a backbone message to request the old Serving BS or
other network entity to stop forwarding pre-HO pending MSS DL data." My
concern is that this sentence may be acepted as binding of "re-establishment
of IP connectivity" [which is a name of certain part of network entry and
relates to management-only IP address] with transfer of network data
[presumably using
another IP addresses]
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.
[VY] My understanding is that referencing to NW entry steps is more precise
as addresses also response messages, timers etc.
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.
[VY] Correct acquisition of SS capabilities at Target BS is much more
critical than e.g. correct acquisition of MAC address [of MSS that may
potentially perform HO]. If MAC Address was erroneous, the MSS fails to
perform shortened Initial ranging but recovers by "usual" contention-based
procedure. If BS is wrong about MSS capabilities, there is no recovery
mechanism. Then communication might be harmed with no understanding of
reason at both sides. So transferring MSS capabilities over backbone should
be accompanied e.g. by some mechanism of error check or double check after
network entry etc.
This mail was sent via mail.alvarion.com
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************