H323Mobility: About the work plan

Jaakko Sundquist jaakko.sundquist at NOKIA.COM
Wed Nov 10 09:54:01 EST 1999


Hi, Adam and All:

We have requested everyone to provide contributions with solutions. We will
then be able to understand what exactly they mean.

With respect to your questions, it is too early to answer. However, we will
be getting there soon as we are making progress to find a solution. Once we
define an H.323 mobility architecture, we will definitely be able to relate
all other wireless networks as well. Please note that H.323 mobility
architecture is good for both wire-line and wireless network.

By the way, if your provide a contribution, it will help us to understand
about your proposed solution.

Best regards,
Radhika R. Roy

> -----Original Message-----
> From: Adam Li [SMTP:adamli at ICSL.UCLA.EDU]
> Sent: Wednesday, November 10, 1999 4:41 AM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      Re: H323 mobility: Summary of discussion
>
> Hi, all,
>
> Barry Aronson's comment seems to make a lot of sense to me.
>
> I am new to the H.323 group, but I've been reading the email
> correspondences here for quite a while. May I ask a few dumb
> questions, and please correct me and elighten me if I am wrong?
>
> Question: Consider the wireless case, isn't that H.323M is
> going to be used over some wireless network (e.g. 3G IMT2000
> network)? If such network is already built to ensure that your
> data gets transmitted to you no matter you walk or drive from
> one zone to the other, why can't our H.323M terminal just
> sit at the handset and wait for our data get routed to us
> by the network? Or, why do we need to duplicate these
> functions that are already provided, and should be provided
> by the network layer?
>
> Maybe, all we have to do is to make sure we know the data is from
> the same entity when it changes its attaching point, since each
> H.323 entity is identified by the LAN address (H.323 7.1.1).
> A simple extension of assigning a temporary ID number to each
> entity or to each conference can solve that.
>
> Please enlighten if there is any special compelling reason that
> I might have overlooked for duplicating an entire mobile network
> functionality within H.323. Thanks in advance.
>
> Adam Li
>
>
> Edgar Martinez [1] writes:
> >
> > Comments: follow--
> >
> > Barry Aronson wrote:
> >
> > > All,
> > >
> > > I agree with Tom. We seem to be headed for designing an entire mobile
> > > network within H.323 -- definitely a case of the tail wagging the dog.
> If
> > > this was the desire, extending existing mobile networks (AMPS, GSM,
> etc.) to
> > > include H.323 terminals would be simpler.
> >
> > This is called the WAP solution, already done but it is still
> > two separate networks (MSC-CS and  PDN) routed/ split out
> > by a DSU from the BSC. And it does not address the fixed
> > Internet PC or any PSTN/ISDN interworking.
> >
> > > That is, of course, unless you
> > > wanted the terminals to be independent of the physical network from
> the
> > > network layer on up. H.323 could do this if there was an underlying
> packet
> > > based network -- probably IP. Using IP as a common network layer for
> both
> > > wireless and wired terminals is of course all the rage these days.
> Given
> > > that universal wireless terminals are been worked as part of IMT-2000
> (and
> > > 3GPP, 3GPP-2, etc.), wouldn't it make sense to define the Annex H
> issues
> > > being debated in the appropriate network groups?
> >
> > We are looking at the H.323 mobility at the appilation layer within
> > the approriate woking groups.
> >
> >
> > >
> > >
> > > Maybe I misunderstood, but I thought in Santiago the purpose of Annex
> H and
> > > I was to make H.323 work within the context of a mobile terminal
> and/or
> > > user, and also allow for service mobility.
> >
> > I feel a mobile IP debate is in the starts here but, We are looking at
> > the H.323 mobility at the appilation layer within the approriate woking
> > group.
> >
> > What the IETF needs to address is how mobile IP interworks with Mobility
> > whether is H.323, GSM, PLNM or otherwise..
> >
> > > I don't think any of what is
> > > being discussed for Annex H is necessary to achieve this.
> >
> > What being discussed here is, we are looking at
> > the H.323 mobility from the appilation layer.
> >
> > >
> > >
> > > Barry
> > >
> > > -----Original Message-----
> > > From: Mailing list for parties associated with ITU-T Study Group 16
> > > [mailto:ITU-SG16 at MAILBAG.INTEL.COM]On Behalf Of Tom-PT Taylor
> > > Sent: Friday, November 05, 1999 11:17 AM
> > > To: ITU-SG16 at MAILBAG.INTEL.COM
> > > Subject: Re: H323 mobility: Summary of discussion
> > >
> > > I think a basic point in this discussion is that mobility is "bigger
> than"
> > > H.323 and already has well-established architectural underpinnings.
> It's
> > > all very well to talk about an H.323 solution which we could then
> adapt, but
> > > we would more likely end up with an H.323-only solution as a result.
> The
> > > concern then would be whether vendors saw sufficient opportunity in
> building
> > > to this market, compared with the general market for mobility
> products.
> >
> > --
> > Edgar Martinez - Principal Staff Engineer
> > Email mailto:martinze at cig.mot.com
> > FAX 1-847-632-3145 - - Voice 1-847-632-5278
> > 1501 West Shure Drive, Arlington Hgts. IL 60004
> > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/
> > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/
> >
>
>
> --
> Adam H. Li
> Image Process Lab
> University of California - Los Angeles
> (Phone) 310-825-5178 (Fax) 310-825-7928



More information about the sg16-avd mailing list