[Robustness] group formed

Callaghan, Robert Robert.Callaghan at ICN.SIEMENS.COM
Mon Nov 1 15:41:34 EST 1999


Hi, Ed and All,

I fully agree with you that we need to address both together to have an
end-to-end solution. In fact, this is also AT&T's goal because we want to
provide services on end-to-end basis consisting both cellular-PSTN/ISDN and
H.323 (IP).

In fact, you have covered some functions: "HomeZone ID, VisitedZone ID, Home
Aera and Visited Area." That is, we are NOT considering any generalized
solution that excludes the fundamental concept of "Zone" and "Domain" of
H.323.

The point is that we can consider more functions as much as we want, but we
still needs to work within the framework of H.323.

When I say that we need to provide solution in the context of H.323, I mean
that we need to find solution in the framework of H.323 as much as we can
(that might include all abstractions of cellular-PSTN network, if possible,
in H.323 as well). It provides a systematic way to solve the problem
step-by-step.

Once we complete this first step, we then apply this solution in the conext
of cellular-PSN/ISDN-H.323 (IP). We will able to test and examine how far we
have been able to satisfy the requirements in the first step. If we do not
satisfy all requirements, then we need to extend the functionalities of the
first step.

Let us examine the case of location area (LA). As I mentioned in my earlier
email, LA can be considered in H.323 as a subset of zone without relating to
the LA of the cellular-PSTN network. In this situation, LA defined is H.323
may not be useful to provide interoperability between cellular-PSTN and
H.323 (IP). Should we not abstract the LA in H.323 in such a way that also
provides interoperability in the context of both cellular-PSTN and H.323
(IP)? Does not the two-step process provide better granularity to have the
complete solution?

H.323 Annex H has two primary sections: H.323 Mobility and Interoperability
(H.323-Cellular-PSTN).

When I say two-step process, I mean two-step working mode of Annex H.
However, we will standardize the H.323 Annex H after completing both H.323
Mobility and Interoperability (H.323-Cellular-PSTN).

Did we not agree that we may not be able to visualize all functions to start
with and we may have to come back to add more functions as we go more deep
into the solution? Kindly see AT&T contributions APC-1651/1652/164/1665 how
many MORE functions that we need to define even in H.323. Do I start arguing
right now why you are not including all function right away?

I have not even written a contribution considering cellular-PSTN-H.323 (IP)
interworking yet.

Hope this will clarify further.

Best regards,
Radhika


> -----Original Message-----
> From: Edgar Martinez [1] [SMTP:martinze at CIG.MOT.COM]
> Sent: Monday, November 01, 1999 12:34 PM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      Re: H323mobility:meeting
> Importance:   High
>
> Dear Roy and Jaakko,
>
> The information in Annex-H Draft all came from both TD16 and
> TD42b. The HomeZone ID and VisitedZone ID are new concepts
> used for H.323 mobility which is related to the functions we
> all agreed was needed to provide mobility for the application point of
> view.
> The new definition should not clash with the meaning of ZONE or
> Domain in H.323. In any event, we need to defined the properties
> of  the HomeZone ID, VisitedZone ID, Home Aera and Visited
> Area. In the context of H.323 mobility and Interworking with PSTN.
>
> ---
> New subject:
>
> >Our first goal is to define a mobility architecture in the context of
> H.323.
> >Our second goal is to interworking between the packet-based H.323
> mobility
> >architecture and circuit-switched based cellular-PSN/ISDN mobility
> >architecture.
>
> Motorola is looking at a full end-to-end fixed, wireless
> and mobile full IP solution. Which includes interworking
> as a major basic requirement.
>
> We are not defining or designing a new IP system. Our
> job is simply to add to the existing  IP infrastructure wireless access
> and the mobility applications. And support interworking with the legacy
> mobile systems. We and others are looking at providing the full package.
>
> If we do not address the full solution now, I feel we leave the door
> open for Hybrid systems, so-called network overlay or  work arounds.
>
> I will oppose that Annex-H is complete. If we do not address the
> interworking
> sections (as proposed in the TOR) within the same timeframe that we are
> defining
>
> how to add the mobility functions to H.323.
>
> Regards,
> Ed
>
> "Roy, Radhika R, ALARC" wrote:
>
> > Hi, Ed, Jaakko, and All,
> >
> > In H.323, zone and domain are well defined.
> >
> > If we can solve mobility problems within the framework of H.323 as far
> as
> > practicable, we do not need to create new terminology in the context of
> > H.323 for now. Contributions (APC-1651/1652) have also been presented
> also
> > how H.323 mobility problems can be solved with the context of zones and
> > domains.
> >
> > I understand that location area (LA) is also used in the cellular
> wireless
> > network.
> >
> > If the new terminologis like location area (LA) are created for
> interworking
> > between cellular-PSTN and IP networking environments, we definitely need
> to
> > look into how "LA" is fitted in the context of zone or domain. However,
> zone
> > and domain are the fundamental concept of H.323 that always needs to be
> > related.
> >
> > Our first goal is to define a mobility architecture in the context of
> H.323.
> > Our second goal is to interworking between the packet-based H.323
> mobility
> > architecture and circuit-switched based cellular-PSN/ISDN mobility
> > architecture.
> >
> > In H.323, a zone may consist of many networks (e.g., many IP
> subnetworks).
> > Do we need to create LAs within a zone? Will the LA be a good fit with
> that
> > of cellular network for interworking at this point of time because we
> have
> > not yet solved the basic problem in the context of H.323?
> >
> > I had some initial discussion with Jaako in the last Red Bank meeting,
> but
> > we could not complete our discussion. My personal view has been that we
> may
> > need something like LA to further optimize the mobility problem within a
> > zone. For example, paging may be one of the reasons. However, I have
> > realized that this LA concept may be more important in the context of
> H.323
> > (IP) and cellular-PSTN interworking. So, my feeling has been that we may
> > need more functions similar to LA when interworking is concerned
> (Motorola's
> > contribution APC1646 is an example). The idea has been that we should
> > consider all those extensions in H.323 mobility architecture when we
> deal
> > with interworking (second phase).
> >
> > Definitely, LA concept has some merits and we need to discuss it.
> >
> > Best regards,
> > Radhika R. Roy
> > AT&T
> > + 1 732 420 1580
> > rrroy at att.com
> >
> > > -----Original Message-----
> > > From: jaakko.sundquist at NOKIA.COM [SMTP:jaakko.sundquist at NOKIA.COM]
> > > Sent: Monday, November 01, 1999 7:23 AM
> > > To:   ITU-SG16 at MAILBAG.INTEL.COM
> > > Subject:      Re: H323mobility:meeting
> > >
> > > Hi Ed,
> > >
> > > I haven't read your draft yet, but I just want to make a short comment
> on
> > > the definitions that you proposed.
> > > You mention the concepts of HomeZone ID and VisitedZone ID. This
> implies
> > > already to a certain architecture, namely one where the "home area"
> and
> > > "visited area" of a User are defined to be identified with the
> accuracy of
> > > one zone. In my contribution to the Red Bank meeting (APC 1659) I
> proposed
> > > similar "home area" and "visited area" concepts based on
> Administrative
> > > Domains, which in my mind makes more sense as the Domains have so far
> in
> > > H.323 been the entities that are responsible for maintaining any
> > > information
> > > of their users.
> > > So I propose that we think about the architecture first before
> defining
> > > these terms.
> > >
> > > - Jaakko Sundquist
> > > -------------------------------------------------------
> > >      In a hole in the ground there lived a hobbit.
> > >  Not a nasty, dirty, wet hole, filled with the ends of
> > >      worms and an oozy smell, nor yet a dry, bare,
> > > sandy hole with nothing in it to sit down on or to eat:
> > >      it was a hobbit-hole, and that means comfort.
> > > -------------------------------------------------------
> > >
> > >                 -----Original Message-----
> > >                 From:   EXT Edgar Martinez [1]
> > > [mailto:martinze at cig.mot.com]
> > >                 Sent:   Monday, November 01, 1999 3:33 AM
> > >                 To:     ITU-SG16 at mailbag.cps.intel.com
> > >                 Subject:        H323mobility:meeting
> > >
> > >                 Dear All,
> > >
> > >                 I have put together the first proposed draft and
> outline
> > > for
> > >                 H.323 Annex-H. You can pick-up a copy in:
> > >               http://people.itu.int/~emartine/temp/
> > >
> > >                 Editor's Special Note:  The interworking  referred in
> this
> > > annex is
> > >                 the interwork of legacy systems to H.323 systems. Not
> to
> > > be
> > > confused
> > >                 with interworking H.323 systems to circuit switched
> hybrid
> > > systems
> > >                 or circuit switched adjuncts. The work proposed
> therewith,
> > > does not
> > >                 impact
> > >                 the legacy systems or impose new requirements to the
> > > Legacy
> > > systems
> > >                 to support H.323 terminals or H.323 systems.
> > >
> > >                 Need to add more sections to the Annex-H  to comply
> with
> > > TOR
> > > e.g.,
> > >                 Interworking:
> > >
> > >                 Network interworking
> > >                 connections between H.323 systems and mobile networks
> > > (e.g.,
> > > GSM, ANSI
> > >                 41, ...)
> > >                 connections between mobile H.323 systems and PSTN or
> other
> > > networks.
> > >
> > >                 Terminal interworking
> > >                 Use of non-H.323 mobile terminals (e.g., GSM handset,
> > > H.324
> > > terminal,
> > >                 H.320 terminal, etc.) to communicate with H.323
> systems.
> > >
> > >                 Tandeming minimisation
> > >                 Non-transcoding of media streams
> > >
> > >                 Also, it would be nice if we can add to the
> > >                 the defiention section:
> > >
> > >                 Home Location Funtion (HFL)
> > >                 Vistor Location Funtion (VFL)
> > >                 Authentication user Funtion (AuF)
> > >                 HomeZone ID (HZid)
> > >                 VisitedZone ID (VZid)
> > >
> > >
> > >
> > >
> > >                 --
> > >                 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/
>
> --
> 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/



More information about the sg16-avd mailing list