Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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
> 
>