Re: [802.21] [Mipshop] Re: Architectural Considerations for Handover InformationServices (was: Re: CARD Discussion Query Discussion)
I have some comment on the first two points.
In most cases an application does not directly deals with encoded data
carried in a protocol, it translates the encoded data to its internal
structure (e.g., struct in C language). If TLV is used as the
encoding format, the conversion is something like:
(1) [Internal Structure] <-------------------------> [TLV]
If we use XML text as encoding format in the protocol, then the
application will perform data conversion between internal structure
and XML text:
(2) [Internal Structure] <-------------------------> [XML text]
If we use XML binary encoding instead of XML text in the protocol to
reduce the size of the encoded data, then the application will perform
data conversion between internal structure and XML binary:
(3) [Internal Structure] <-------------------------> [XML binary]
Assuming that all of the three cases above use the same internal
structure, and that the XML binary format is actually a TLV format,
the processing overhead in (1) and (3) are the same. So I would claim
that if XML binary is used, the first two points below make no
difference between XML and TLV unless we assume different applications
for the two. I would also claim that if XML binary is used, then XML
can be viewed as an abstract information representation format (as
RDF).
Note that an application does NOT need to have additional conversion
to XML text something like:
[Internal Structure] <-----> [XML text] <------> [XML binary]
Hope this helps,
Yoshihiro Ohba
On Fri, Oct 21, 2005 at 03:46:31PM -0400, Singh Ajoy-ASINGH1 wrote:
> Hi, Srini,
>
> Good points! Please find my inline replies.
>
> Regards,
> Ajoy
>
>
> O) Computing/processing or power requirements on the small devices
> o) Does TLV take much less than XML?
>
> Ajoy-> http://www.zapthink.com/report.html?id=ZAPFLASH-11162004
>
> I would suggest please see above link that describes performance issue
> associated with XML encoding. As per above link, the size of XML encoded
> message can be 10 to 50 times larger than binary encoded message.
>
> O) Bandwidth Efficiency (how many bytes, IP packet(s) in a req-resp)?
> o) Text or bin based, if XML bin, how does it compare to TLV
> sizes?
>
> Ajoy-> Although binary encoding might help with size of XML data to some
> extent, but it adds lot of processing overhead. You may also find that
> benefit gained from compression is being easily offset by processing
> power. For example, if you have 20 millisecond frames to send some
> signaling frame and you may find that compressing XML frame itself is
> taking more than 20millisecond then even if you can accommodate
> compressed packet in 20millisecond frame, you will need two such frames
> to send compressed data.
> I think several issues associated with compression and binary encoding
> is identified in above link.
>
> O) Implementation complexity (parsers, code size and memory, at least on
> terminals)
> o) with XML, there is code reusability since other applications
> need them anyway
>
> Ajoy-> code usability in an interesting point! But depending upon
> architecture of mobile phone it may or not be possible to re-use
> application layer code for handler signaling purpose.
>
> O) Flexibility offered in query mechansims (structured vs something)
>
> Ajoy-> I think first of all we should ask how complex query mechanism is
> really required? I am not sure if we really have handle on that yet.
> Also,
> even if such query mechanism is required, there is no reason why such
> query mechanism cannot be defined using TLV encoded. I am not ruling our
> XML for some use cases. It is possible that in some use cases, XML may
> be ok, but we need to better understand that before getting carried away
> by perceived benefit of XML encoding.
>
> O) Extensibility (if new info to be added) - protocol level or data
> format level?
>
> Ajoy-> We are talking about container protocol. How you organize data
> using the container protocol depends upon application using the
> protocol? You can make it generic enough and very extensible also.
> IMHO, I would like to cite example of EAP, AAA, L2TP. These protocols
> have been very extensible and have been hugely deployed. I am not sure
> if using TLV encoding makes something less extensible.
>
> o) Do we have to go through IANA or other simple publication?
>
> Ajoy-> IANA can setup registry for such protocol and we can request
> number space from that registry. If required you can always define some
> vendor specific type. CARD already has IANA assigned registry.
>
>
> >-----Original Message-----
> >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com]
> >Sent: Friday, October 21, 2005 10:31 AM
> >To: Sreemanthula Srinivas (Nokia-NRC/Dallas);
> >STDS-802-21@listserv.ieee.org
> >Subject: RE: [802.21] [Mipshop] Re: Architectural
> >Considerations for Handover InformationServices (was: Re: CARD
> >Discussion Query Discussion)
> >
> >Srini,
> >
> >Please find inline comments.
> >
> >Regards,
> >Ajoy
> >
> >
> >Since you made a note about small devices, I wanted to express
> >our opinion coming from another small devices manufacturer.
> >
> >Ajoy-> Do you really believe that XML based handover signaling
> >is a good
> >for mobile devices? I would like to hear some thought from you.
> >
> >If you did not do predictive fetching (say from WLAN) how can
> >you ensure that the current radio link conditions are good
> >enough for a successful IS query exchange?
> >
> >Ajoy-> Predictive fetching is ok, but you can't pre-fetch information
> >well ahead of time. You can only pre-fetch information about
> >your neighborhood.
> >So, there is time sensitivity associated with it. I think
> >similar concept is also used in CARD. Even if you pre-fetch
> >information about neighborhood you have to consider efficient
> >encoding mechanism to make it really usable. Signaling does
> >not come free, it requires radio resources.
> >
> >
> >
> >>-----Original Message-----
> >>From: ext Qiaobing Xie [mailto:Qiaobing.Xie@MOTOROLA.COM]
> >>Sent: Thursday, October 20, 2005 4:56 PM
> >>To: STDS-802-21@LISTSERV.IEEE.ORG
> >>Subject: Re: [802.21] [Mipshop] Re: Architectural Considerations for
> >>Handover InformationServices (was: Re: CARD Discussion Query
> >>Discussion)
> >>
> >>I just want to emphasize a point Hong-Yon has made
> >>(repeatedly) - that the information in the DB is not dynamic
> >of nature
> >>does NOT mean that the access to the information by the UE is
> >not going
> >>to be time sensitive. The most common and sensible
> >engineering approach
> >>for a small device that needs to access a DB is to fetch the needed
> >>info on-demand.
> >>Predictive-fetching is not an easy thing to do (one would
> >need to have
> >>a good prediction algorithm) and duplicating the entire info on the
> >>device is simply impractical.
> >>
> >>regards,
> >>-Qiaobing
> >>
> >>Subir Das wrote:
> >>> Peretz,
> >>> I agree with your view. We do not expect that such
> >information will
> >>> change with real time and during handover. Also as you have
> >>> mentioned, we are enabling handover decision process with
> >>the IS. The
> >>> major part of this handover process such as policy, network
> >>selection
> >>> , etc, are out of scope.
> >>>
> >>> -Subir
> >>>
> >>>
> >>>
> >>> Peretz Feder wrote:
> >>>
> >>>>On 10/20/2005 8:40 AM, Hong-Yon Lach wrote:
> >>>>
> >>>>
> >>>>>I have heard examples in which I would consider the information as
> >>>>>dynamic, such as the "neighbouring network/access points
> >>available that match ..."
> >>>>>
> >>>>>
> >>>>
> >>>>neighboring info could change every few hours indeed, but
> >>wouldn't you
> >>>>agree it is considered static for an HO process that should
> >>be in the few msec range?
> >>>>
> >>>>
> >>>>
> >>>>>and examples in which the information is very static (does
> >>not change
> >>>>>much with time).
> >>>>>
> >>>>>The dynamic nature of information, depending on the
> >>specific piece of
> >>>>>information, could be different according to deployment, and could
> >>>>>change over time.
> >>>>>
> >>>>>
> >>>>
> >>>>Yes and even every few hours is good enough to be labeled static.
> >>>>
> >>>>
> >>>>
> >>>>>When IS is used in the preparation of handover, it would
> >be nice to
> >>>>>minimise such preparation time, because the longer it is the more
> >>>>>likely the risk of losing current network coverage and making
> >>>>>handover less seamless. Maybe IS is not meant to be used in
> >>such context?
> >>>>>
> >>>>>
> >>>>
> >>>>That is my understanding, which I expressed in many f2f
> >>meetings w/o much objection.
> >>>>
> >>>>
> >>>>Anyway, it will be a good step
> >>>>
> >>>>
> >>>>>forward to know what we are assuming/doing/enabling and
> >>what we are not.
> >>>>>
> >>>>>
> >>>>
> >>>>We are enabling the decision process, wherever it is located to be
> >>>>equipped with all the pertinent info for a HO proper decision. this
> >>>>includes policy, neighbors, provisioning, loading, etc.
> >>>>
> >>>>
> >>>>
> >>>>>Yoshihiro has given example about
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>From: Peretz Feder <pfeder@lucent.com>
> >>>>>>Organization: Lucent Technologies
> >>>>>>Date: Thu, 20 Oct 2005 08:10:54 -0400
> >>>>>>To: Hong-Yon Lach <hong-yon.lach@motorola.com>
> >>>>>>Cc: <STDS-802-21@listserv.ieee.org>
> >>>>>>Subject: Re: [802.21] [Mipshop] Re: Architectural
> >>Considerations for
> >>>>>>Handover InformationServices (was: Re: CARD Discussion Query
> >>>>>>Discussion)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>On 10/20/2005 5:00 AM, Hong-Yon Lach wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Apparently, we still have very different ideas in mind
> >>when we talk
> >>>>>>>about IS concerning what it is. A lot of discussions so far
> >>>>>>>concerns how it should be supported. Peretz, I think you pointed
> >>>>>>>out the consequence that we can only disagree about the
> >>assumption of IS.
> >>>>>>>
> >>>>>>>
> >>>>>>We are not agreeing on its dynamic nature. The rest we do.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>How IS is to be used and should be supported depends on what
> >>>>>>>information IS is dealing with. If we do not have
> >>consensus on the
> >>>>>>>nature/type/purpose of information to be coped with in
> >>IS, I don't
> >>>>>>>see how 802.21 can produce a requirement on IS and how
> >>MIPSHOP knows what it is doing for IS.
> >>>>>>>
> >>>>>>>
> >>>>>>IS is dealing with all the relevant info that can assist the HO
> >>>>>>decision. To assume that in a middle of a few msec
> >hanodoff the IS
> >>>>>>DB can be queried for pertinent HO info. and exchange all of that
> >>>>>>over L3 is a very loaded assumption, as it assumes that the IS DB
> >>>>>>will be updated at such resolutions and its info be
> >>relevant to a a
> >>>>>>few msec process.
> >>>>>>
> >>>>>>
> >>>>>>Your bleak statement is not so black and white. IS info is
> >>relevant
> >>>>>>and can be very well defined but it is not dynamic in nature.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Cheers,
> >>>>>>>Hong-Yon
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>From: Peretz Feder <pfeder@LUCENT.COM>
> >>>>>>>>Organization: Lucent Technologies
> >>>>>>>>Reply-To: Peretz Feder <pfeder@LUCENT.COM>
> >>>>>>>>Date: Thu, 20 Oct 2005 01:03:18 -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 10/18/2005 6:11 PM, Qiaobing Xie wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>Yoshihiro Ohba wrote:
> >>>>>>>>>...
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>- In reality, 3GPP2 has XML-based method (e.g., XCAP) in its
> >>>>>>>>>>dependency list.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>If I remember it right XCAP/XML is used there for
> >>maintaining the
> >>>>>>>>>address book/buddy list that sort of things. I can
> >imagine that
> >>>>>>>>>sort of events only happen at most no more than a few
> >>times a day
> >>>>>>>>>for any given user and probably only happen when the
> >>user is NOT
> >>>>>>>>>in a call. In contrast, IS query/response likely will
> >>be part of the h/o call flow...
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>You are assuming IS is a dynamic information that can influence
> >>>>>>>>Handover per the IS query response. Many .21 members do
> >>not agree
> >>>>>>>>with this position. IS should be treated as static information
> >>>>>>>>that is provided to the HO decision entity in advance.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>regards,
> >>>>>>>>>-Qiaobing
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>Yoshihiro Ohba
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>
> >>>>>
> >>
> >
>