Re: [802.21] [Mipshop] Re: Architectural Considerations for Handover InformationServices (was: Re: CARD Discussion Query Discussion)
> 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