Re: [802.21] [Mipshop] Re: Architectural Considerations for Handover InformationServices (was: Re: CARD Discussion Query Discussion)
OK, I think there is some understanding of the need for a semantic
query even for TLV.
Yoshihiro Ohba
On Mon, Oct 17, 2005 at 08:55:19PM +0200, Hong-Yon Lach wrote:
>
>
> > From: Yoshihiro Ohba <yohba@TARI.TOSHIBA.COM>
> > Reply-To: Yoshihiro Ohba <yohba@TARI.TOSHIBA.COM>
> > Date: Mon, 17 Oct 2005 13:58:51 -0400
> > To: <STDS-802-21@listserv.ieee.org>
> > Subject: Re: [802.21] [Mipshop] Re: Architectural Considerations for Handover
> > InformationServices (was: Re: CARD Discussion Query Discussion)
> >
> > On Mon, Oct 17, 2005 at 11:05:45AM -0400, Singh Ajoy-ASINGH1 wrote:
> >>
> >>
> >> I am not claiming that the size of XML encoded message will be smaller
> >> than TLV encoded one.
> >>
> >> Ajoy-> OK
> >>
> >> I am claiming that if Solution 1 that provides less semantic query
> >> (one may call it simple query) needs to carry x1 bytes of actual
> >> information with its encoding overhead o1 bytes, while Solution 2 that
> >> provides more semantic query (one may call it complex query) needs to
> >> carry x2 (<x1) bytes of actual information with its encoding overhead
> >> o2 (> o1) bytes, to make the same handover decision, then what we need
> >> to compare in terms of information volume is [x1+o1 vs. x2+o2],
> >> instead of [x1 vs. x2] or [o1 vs. o2]. And when we are discussing
> >> information encoding, we are just discussing [o1 vs. o2], and choosing
> >> a solution based only on this factor is wrong.
> >>
> >> If we view Solution 1 as TLV-based and Solution 2 as XML-based, then I
> >> think [x1 > x2] && [o1 < o2], and depending on how we encode XML,
> >> diffence between o1 and o2 can be small.
> >>
> >> Ajoy-> Could you please provide examples to justify your claim? I think
> >> some
> >> example will be helpful here. We can always define good enough query
> >> mechanism using TLV encoding that would be enough here. Btw, why do we
> >> need extremely advance query mechanism for inter-technology handoff? But
> >> we need to go through this discussion before we start designing any
> >> query mechanism.
> >
> > For example, assume that the UE wants to get a list of neighboring
> > 802.11 APs around a given AP, where the neighboring APs support
> > 802.11i and have roaming relationship with my home operator. Note
> > that this example is described in Annex of
> > 21-05-0347-00-0000-XML_IS_Introduction.doc.
> >
> > In Solution 1, if there is no semantic query then the response may
> > contain a list of APs each carrying all information elements
> > associated with APs and that may or may not support 802.11i (and the
> > list may also contain APs of different MAC types). The information
> > elements include a list of roaming operators. If there are 20 APs,
> > each AP has 100 roaming operators and each roaming operator name is 20
> > bytes, the total information volume to carry just a list of roaming
> > operator information elements can be 40K bytes (i.e., x1 > 40K).
> > Then, the UE needs to have an intelligence to choose an AP that
> > satisfies the exact condition using the responded information.
> >
> > On the other hand, in Solution 2, the UE can specify the exact
> > condition in a semantic query and will get a response just containing
> > the list of APs that matches the exact condition. Assuming that an AP
> > is represented in 10 bytes, and there are two matching APs, then x2 =
> > 20. The UE can pick up just one of the two APs randomly, because it
> > is the information server that has most of the intelligence to execute
> > the query.
> >
> [hong-yon] This is a good example. In solution 1, I don't understand why the
> query cannot ask for the list of APs that satisfy a list of criteria (e.g.
> Having agreement with a specific operator, etc). Such query can be
> constructed, with or without XML. So I think that solution 1 can do exactly
> the same as solution 2.
>
> > Next, we need to estimate o1 and o2. If we use TLV-encoding for
> > Solution 1, and assume 2 byte Type field and 2 byte Length Field, and
> > each operator name is carried in a separate IE, then o1 = (2+2)*100*20
> > = 8K bytes. If we use XML for Solution 2, o2 is the number of bytes
> > of XML tags surrounding the list of APs, say 50 bytes.
> >
> > In that case, x1 + o1 = 48K, and x2 + o2 = 70. So I would say
> > Solution 2 is much better in this particular example.
>
> [hong-yon] As described above, there is no reason solution 1 cannot make a
> semantic query and get exactly what is needed as solution 2; that is x1=x2.
> In this case, in the overheads calculation, you will get a smaller o1 than
> o2; that is (o1+x1) is smaller than (o2+x2).
> >
> > Of course, if we can define more efficient query for TLV-encoding, x1
> > can be much smaller. In fact I've made the following analysis in the
> > same Annex of the document I mentioned above (I hope this is a fair
> > analysis):
> >
>
> [hong-yon] I think TLV-encoding has nothing to do with whether a query can
> be made smart or not.
>
> > "
> > o The schema-less query needs clear semantics definition for each pair
> > of a specific QueryFilterType value and a QueryFilterParameters
> > pattern used for the QueryFilterType value.
> >
> > o The number of QueryFilterType values required for the schema-less
> > query exponentially increases as the number of static conditions used
> > combined in a single QueryFilterType value increases.
> >
>
> [hong-yon] For "schema-less" query, why is it not possibly to define generic
> QueryFilterType and generic QueryFilterParameters that can be combined in
> different manners?
>
> > o If only limited number of query patterns needs to be supported, then
> > the schema-less query may be acceptable. Otherwise, the schema-based
> > query is required to support more query patterns including simple and
> > complex ones.
> > "
> >
> [hong-yon] Ditto! I am not sure that this statement is necessary true.
>
> > Hope this helps,
>
> [hong-yon] It does, thanks. I think our fundamental difference is that you
> assume TLV-based approach cannot be semantically intelligent, and XML-based
> approach can be. My believe is that all are built on bits and they can be
> made as intelligent as needed.
>
> Cheers,
> Hong-Yon
> >
> > Yoshihiro Ohba
>
>
>