Re: [802.21] [Mipshop] Re: Architectural Considerations for Handover InformationServices (was: Re: CARD Discussion Query Discussion)
Qiaobing and all,
On Wed, Oct 19, 2005 at 03:01:12PM -0500, Qiaobing Xie wrote:
> Yoshihiro Ohba wrote:
>
> > Qiaobing,
> >
> > Could you elaborate on the "major portion"? Do you mean the major portion
> > is 5 to 9 sec, or the major portion is a part of 5 to 9 sec?
>
> A "major portion" of the overall 5 to 9 sec, but there is no general way
> to precisely measure it (see below).
Thanks for the clarification. Do you have publically available
literature for the measurement?
>
> > Also, which is more dominant delay factor in SIP/XML signaling,
> > transferring text over the air (transmission delay) or processing text
> > on cellular phones (processing delay)?
>
> Both are major - which one is more dominant depends on the particular
> design and platform. Transferring text SIP over the air for call control
> is unacceptable, this is why both 3GPP and 3GPP2 are critically counting
> on rohc/sigcomp from IETF to compress the SIP messages before it goes
> over the air. It is a *big* effort for several years (a look in
> rohc/sigcomp can tell). The sigcomp compressor/decompressor is
> complicated and CPU intensive and is dictionary based. The achievable
> compression ratio for SIP still leaves a lot to be desired, and I don't
> know whether it can do anything good for embedded XML documents. At the
> same time, the processing delay due to the compression/decompression
> algorithm is a common issue for most small device design due to their
> limited computing power. This hasn't take into account the processing
> time for XML handling itself.
Since XML structure is much simpler than SIP, it would be much less
complicated than SIP compression to remove XML tags and convert into a
binary representation to be compact.
For other processing delay than compression, I think it is mostly
application-specific, and we should not compare on that part.
>
> > In terms of the sensitivity of IS, as long as IS can be executed
> > between handovers and in the middle of the call and in the background
> > without disrupting the call, the delay requirement of IS is not
> > necessarily much more sensitive than the call setup time, in my
> > opinion.
>
> Unfortunately, most handoffs are not predictable, i.e., they depends on
> how a UE moves, for example, when a UE moves into a new unfamiliar
> network and urgently wants to make a h/o decision, the IS becomes the
> most needed! If IS can only satisfy the UE during time insensitive
> periods, its usefulness will be severely limited, IMO.
The UE can collect information on a new network via your currently
available network connectivity, and this is doable since we are dealing
with heterogeneous handovers. Even if handovers are not predictable
in many cases, the proactively collected information can still help
improve performance of reactive handovers as well as proactive
handovers.
Since I sensed people understand the need for a schema-based semantic
query and the need for a binary encoding for over-the-air message
exchanges, let me ask one question:
If we use an existing schema-based semantic query (i.e., RDF/XML) for
query part, and use a compact binary encoding (i.e., TLV) for IS
protocol exchange, is it acceptable for us?
Best regards,
Yoshihiro Ohba
>
> regards,
> -Qiaobing
>
> >
> > Yoshihiro Ohba
> >
> >
> > On Wed, Oct 19, 2005 at 09:42:08AM -0500, Qiaobing Xie wrote:
> > > Michael,
> > >
> > > I know there are places where xml is involved in call control, e.g., an
> > > optional xml document can be embedded in a SIP invite message in some
> > > PoC VoIP call control messages in OMA. However, all
> > > implementations/empirical data that I am aware of points to that as the
> > > cause of a major portion of the call setup delay of PoC (~5-9 sec as
> > > reported). It is widely recognized that is a penalty we all are paying
> > > for the extensibility, flexibility, and text-based nature of SIP/XML
> > > call control signaling and tremendous effort and resources have been
> > > spent to reduce the VoIP call setup latency across the industry.
> > > Fortunately, that only happens once at the setup of a call (I am not
> > > aware of any significant SIP/XML signaling used mid-session).
> > >
> > > In my view, handoff is much more time sensitive than the call setup from
> > > a user's perspective and handoff can happen repeatedly in a call. Making
> > > XML handling part of the handoff procedure may not be a good idea at
> > all.
> > >
> > > regards,
> > > -Qiaobing
> > >
> > > Michael.G.Williams@nokia.com wrote:
> > >
> > > >
> > > >Colleagues,
> > > >
> > > >The folks from the IETF have been saying that the IS consuming more
> > > >bandwidth is not a problem, while the IEEE folks are saying bandwidth
> > > >and latency are key concerns. We need some meeting of the minds and
> > > >implementations/empirical data to help out here.
> > > >
> > > >Best Regards,
> > > >Michael
> > > >
> > > >-----Original Message-----
> > > >From: ext Qiaobing Xie [mailto:Qiaobing.Xie@MOTOROLA.COM]
> > > >Sent: Tuesday, October 18, 2005 3:11 PM
> > > >To: STDS-802-21@listserv.ieee.org
> > > >Subject: Re: [Mipshop] Re: Architectural Considerations for Handover
> > > >InformationServices (was: Re: CARD Discussion Query Discussion)
> > > >
> > > >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...
> > > >
> > > >regards,
> > > >-Qiaobing
> > > >
> > > > >
> > > > > Yoshihiro Ohba
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > Mipshop mailing list
> > > Mipshop@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/mipshop
> > >
> >
>