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.
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.
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):
"
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.
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.
"
Hope this helps,
Yoshihiro Ohba