Re: [802.21] terminology clean up needed for link parameters and QoS parameters
Hi Qiaobing,
I agree. Some housekeeping is needed with respect to the parameters that
seem to be causing confusion.
Qiaobing Xie wrote:
> All,
>
> There are several comments related to the definition and usage of link
> parameters in LB#1c.
>
> Currently we have the following definitions use link parameters list.
>
> In IE definition:
> - 6.4.5.2.6 Network QoS IE
>
> In MIH_Link_SAP definition:
> - 7.5.3 Link_Configure_Thresholds
> - 7.5.9 Link_Parameters_Report.indication
> - 7.5.14 Link_Get_Parameters
>
> In MIH_SAP definition:
> - 7.6.10 MIH_Link_Parameters_Report
> - 7.6.15 MIH_Get_Status
> - 7.6.17 MIH_Configure_Link
>
I will observe that all these parameters are used to "characterize" the
link and perhaps that's why ended up
in the same list.
> Even though we currently call them all "link parameters", we are in
> fact dealing with 3 types of very different entities:
>
> 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.
> 802.21 only query those values through MIIS. They can NOT be set with
> any primitive.
Sure.
>
> 2) Link measurements (as used in Link_Configure_Thresholds) - they are
> *dynamic* values which change overtime. 802.21 primitive can set
> thresholds on them but NEVER set their values! An example is link SINR.
>
> 3) Link states (as used in MIH_Configure_Link) - they are configurable
> values associated with a link. An MIH User can set and get the values
> with primitives but it makes NO sense to set thresholds on them since
> they are NOT changing. An example is OPERATION_MODE.
>
> My suggestion is to name them separately (Network QoS attributes, Link
> measurements, Link states), encode them separately, and perhaps deal
> them separately.
>
This is a good classification of the different types of parameters we
have to deal with.
At this point, we have a good classification in the draft based on MIH
generic versus Link specific.
I can easily see a way to combine (1), (2) and (3) you have above with
the link specific
part of the parameter list.
The MIH generic parameters apply to IEs, MIH_LINK_SAPs and MIH_SAPs. The
link specific
will be determined based on usage in these different contexts.
Couple of ways to proceed:
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.
-Nada
> regards,
> -Qiaobing
--
Nada Golmie, Ph.D.
Manager, High Speed Network Technologies Group
National Institute of Standards and Technology
100 Bureau Dr. Stop 8920
Gaithersburg, MD 20899
Email: nada@nist.gov
Phone: (301) 975-4190
Fax: (301) 590-0932
Web: http://w3.antd.nist.gov