Re: [802.21] terminology clean up needed for link parameters and QoS parameters
Nada,
...
>> 2) For eash link type, a set of link specific measurements that we can
>> set thresholds for - I don't see much value for supporting a set of
>> generic link measurements (you have to have a real link that take the
>> measurement before you can get it)
>>
> We do have MIH generic parameters related to QOS that we can pass to the
> link layer. These can be considered link generic. The mapping from
> generic to specific can either occur at the MIH or link layer. Although
> today's links may not be able to understand the MIH generic QOS
> parameters, the motivation is that future generation links or extensions
> will include them. This is a compromise that we agreed to and hope we
> don't have to undo it.
I am ok with the idea of keeping the generic set for future-proofing.
But I'd like suggest a few things in the description to avoid possible
confusion:
1. When dealing with link measurements, we do not pass the parameter to
the link; instead, we pass thresholds set against a parameter to the
link and hope that the link will a) take the measurement, b) compare the
measurement with the thresholds, c) decide to indication a
threshold-crossing event.
2. Avoid label them "QoS". Just define them as a set of generic link
measurements that future generation of links will likely support.
regards,
-Qiaobing