H323mobility:meeting

Orsic, Milo (Milo) orsic at LUCENT.COM
Tue Nov 2 10:27:50 EST 1999


Hi Ed,
Please do not include anything in the H.323 Annex H
until a given concept has been discussed and jointly accepted.
I commend you for your enthusiasm to get it done, but
let us follow the established procedures.
Thanks,
My best regards,
Milo Orsic
Lucent Technologies


> ----------
> From:         Edgar Martinez [1][SMTP:martinze at CIG.MOT.COM]
> Reply To:     Mailing list for parties associated with ITU-T Study Group
> 16
> Sent:         Monday, November 01, 1999 9:23 PM
> To:   ITU-SG16 at mailbag.cps.intel.com
> Subject:      Re: H323mobility:meeting
>
> Hi Radhika,
>
> I am glad to see that we all agreed mobility on H.323 is not
> rocket science.
>
> On the call scenarios I did not see any conflicts with
> h.225 call control. Once the mobility/location issue is resolve, that is
> once
> the application knows where to route the calls. In other words, when the
> RAS
> procedures and  the location updates are done, we know where to route the
> call,
> using basic h.225 call control. And it was covered in Motorola's APC 1646.
> By
> the way,
> I like to include the Call scenarios you identified in the H.323 annex-H
> document.
> To test out "OUR" H.323 combined contributions for the architecture.
>
> Also see last comments below.
>
> "Roy, Radhika R, ALARC" wrote:
>
> > Hi, Ed:
> >
> > I guess that we talking about the same thing.
> >
> > Who told that mobility functions are different in H.323 (IP) or other
> > networks? The basic functionality is the same from end users' point of
> view.
> >
> > In H.323, the H.323 (e.g., H.225.0, Q.931/932) signaling messages are
> used.
> > The cellular-PSTN networks use their signaling messages. The call
> scenarios
> > can be as follows:
> >
> > 1. Mobile H.323 Terminal to Mobile H.323 Terminal
> > 2. Mobile H.323 Terminal to Fixed H.323 Terminal and vice versa
> > 3. Cellular-PSTN Terminal to Mobile H.323 Terminal (3a) and vice versa
> (3b)
> > 4. Cellular-PSTN Terminal to Fixed H.323 terminal (4a) and vice versa
> (4b)
> >
> > For cases 1 and 2, mobility solutions can be provided using the H.323
> > mobility only (pl. see AT&T's and Nokia's contributions that deal in
> terms
> > of H.323 only).
> >
> > For scenarios 3 and 4, the question of interworking between H.323 (IP)
> and
> > cellular-PSTN comes.
> >
> > Because of H.323, we have certain constraints imposed by its
> architecture.
> > For example, H.323 mobility solution may look as follows:
> >
> > *       H.323 mobility is applicable for both wireless and wire-line
> > mobility.
> > *       H.323 mobility is addressed in the application layer and can be
> > implemented to any packet-switched networks (e.g., IP, etc.).
> > *       H.323 mobility management is done using the RAS (extended to
> > incorporate mobility) signaling scheme. RAS is usually used for the
> pre-call
> > control signaling and, is completely separated from the call control
> > (Q.931/932) signaling. However, in H.323, it is mandatory that RAS
> signal
> > has to go through the gatekeeper (GK). RAS signaling can be used anytime
> > independent of the call control scheme. In this respect, H.323 mobility
> can
> > be managed anytime (before the call, during the call, and/or after the
> call)
> > as it is necessary.
> > *       In H.323, Q.931/932 is used for the call control. H.245 is used
> > primarily to control media (audio, video, and/or data) within a call.
> > *       The wireless or wire-line network layer (e.g., IP) can use any
> > scheme as appropriate for implementation of the application layer H.323
> > mobility.
> >
> > (How will a complete end-to-end solution look like that satisfy
> scenarios 1,
> > 2, 3, and 4? As an HYPOTHETICAL end-to-end solution, I would request
> combine
> > the solution provided in AT&T's contribution [APC-1651] in H.323 domain
> and
> > Motorola's contribution [APC-1646] in cellular/PSTN-H.323 excluding some
> > redundant functions.
>
> > I guess that Motorola's solution does NOT address
> > scenarios 1 and 2 adequately.
>
> Once the RAS procedures are done, we know where to route the call using
> basic
> h.225 call control.
>
> Motorola is not forcing any solution if one looks at the References
> section
> of APC-1646 you will see we try to us the best solutions, and sections 4.1
> to
> 4.1.2 is
> based on AT&T's Document - TD-9 August  2-6 1999 Berlin contribution. As
> the
> Editor of Annex-H and the lack of contributions at that time, the
> reference
> below
> was all I had to work with.
>
> [1] ITU-T Recommendation H.245 (1998), Control protocol for multimedia
> communication.
> [2]  ITU-T Recommendation H.323 (1999), "Packet-Based Multimedia
> Communications
> Systems."
> [3] Internet Draft <draft-teoyli-mobileip-mvpn-02.txt> February 1999,
> Mobile IP
> extension
> for Private Internets Support (MPN), W. T. Teo National University of
> Singapore
> and Y.
> Li Nortel Networks, Inc.
> [4] W. Liao, "Mobility Internet telephony: Mobile Extensions to H.323,"
> INFOCOM'99,
> New York, NY, USA, 2-6 August, 1999.
> [5] RECOMMENDATION  ITU-R  M.1073-1 DIGITAL  CELLULAR  LAND
> MOBILE  TELECOMMUNICATION  SYSTEMS (Question ITU-R 107/8) (1994-1997)
> [6] HANDOVER  PROCEDURES ITU-T  Recommendation  Q.1005 (Extract from the
> Blue
> Book)
> ©  ITU  1988, 1993
> [7] E. Martinez, Motorola, "Annex - H (User and Service Mobility in H.323)
> Proposed Architecture,
> " APC-1560, ITU-T SG16 Q.11-15 Rapporteur Meeting, Berlin, Germany, 2-6
> August,
> 1999.
> [8] H.323 Mobility Ad Hoc Group, "Terms of Reference for H.323 Mobility",
> Temporary Document
> No. 34 (Berlin) 5 August 1999
>
> Best Regards,
>
> Ed
>
>
> > The bottom line is that a solution will look
> > like this: Add some new messages in H.323 and extend the existing H.323
> > messages. I guess that AT&T's APC-1651 can satisfy almost all
> requirements
> > specified in Motorola's APC-1646. I hope that APC-1641 will also be able
> > interwork with GSM/GPRS, ANSI-41, etc. The requirements for TIPHON
> matrix
> > will also be satisfied. If needed, one can also use mobile IP or other
> > schemes for implementation in the IP network layer. I am personally also
> > interested about the location area concept as proposed by Nokia. Of
> course,
> > I am waiting to see other contributions and on-going discussions.)
> >
> > Hope this will clarify further.
> >
> > Thanks,
> > Radhika
> >
> > > -----Original Message-----
> > > From: Edgar Martinez [1] [SMTP:martinze at CIG.MOT.COM]
> > > Sent: Monday, November 01, 1999 3:14 PM
> > > To:   ITU-SG16 at MAILBAG.INTEL.COM
> > > Subject:      Re: H323mobility:meeting
> > >
> > > Hi Radhika,
> > >
> > > The Annex-h document was push back to 2001.
> > >
> > > The mobility H.323 additions is not allot of work.
> > > The mobility applications and concepts been around
> > > for long time.
> > >
> > > I would hope the following to re-use 100% of the IP
> > > network already defined in Standards. And borrowing and applying
> > > mobile applications already defined to H.323 . Which can
> > > coexist with other mobile "SERVICES" from IETF, GSM/GPRS
> > > and even 3GPP. All on the same IP network using one access protocol
> > > preferably the H.323 access protocols. Once we have a solid IP network
> > > infrastructure which includes other "SERVICES"  like: reliable IP
> > > transport,
> > > QoS, charging/billing, security, IN interworking and  naming and
> > > address translations. Adding mobility and Interworking services
> > > to H.323 seems like a drop in the bucket. Now do we need to defined
> > > everything, I argue that only the parts needed to be address are
> > > common to all mobile systems.
> > >
> > > In TIPHON document 7001 we provide a matrix of existing mobile
> > > Services on networks. Which compares the mobility aspects
> > > for terminal, user and service mobility.
> > >
> > > In the same token if one looks at H.323 interworking
> > > IN on IP, ISDN, ISUP and HTTP services, they're  focus
> > > is on re-using common elements. And one access protocol
> > > H.323, why is mobility any different?
> > >
> > > Ed
> > >
> > > "Roy, Radhika R, ALARC" wrote:
> > >
> > > > 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/
> > >
> > > --
> > > 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