Re: [802.21] [Mipshop] Re: Architectural Considerations for Handover InformationServices (was: Re: CARD Discussion Query Discussion)
Ajoy,
On Mon, Oct 17, 2005 at 07:33:14PM -0400, Singh Ajoy-ASINGH1 wrote:
> Yohsi,
>
> This tells me that some filtering mechanism will be required.
> I do see some need to define few filters as part of .21 transport, but
> not necessary the detailed query mechanism itself. If you define few
> filters and then application will be able to use filters to query
> meaningful information to meet their requirements.
It is surely a possible approach. But a question is then how we can
converge on an acceptable set of filters? I am doubtful about it.
Regards,
Yoshihiro Ohba
>
> Regards,
> Ajoy
>
>
> 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
>
>