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)



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. 

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