Re: [802.21] terminology clean up needed for link parameters and QoS parameters
Hi, Nada,
...
> I agree. Some housekeeping is needed with respect to the parameters that
> seem to be causing confusion.
Great!
...
>> 1) Network QoS attributes (as used in Network QoS IE) - they are
>> *static* values assigned to a network (not a link) by its owner.
> I agree that this a type of parameter, but I will observe here that
> Network QOS IEs do not have to be restricted to static parameters,
> although these are likely to be prevalent. If measurements are available
> and can be used, I don't see the problem with supporting this.
Right now, anything we put in the IS server is static. But it is
entirely possible our IS service can be extended in the future to cover
more dynamic information.
> a) -
> - define for each link specific parameter list, a subtype consisting of:
> 1) network static/qos, 2) measurements, 3) state/configuration
> - use subtype appropriately in IE, link primitives and MIH primitives
>
> OR
>
> b)-
> - define a link specific list for each IE, link and MIH primitive. This
> will consist in all link specific parameters related to that primitive.
Another approach could be that we support:
1) A generic set of Network QoS Attributes for MIH IS - I don't see a
huge value for us supporting network specific QoS attributes.
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)
3) A generic set of link states that we can control (set and get) - many
link states are generic already by their nature (OPERATION_MODE,
BATTERY_LEVEL, etc.).
regards,
-Qiaobing