Comments on MTD-107a

Roy, Radhika R, ALARC rrroy at ATT.COM
Tue Dec 14 08:20:16 EST 1999


Hi, Laurent:

We would like to have the solution in H.323 layer that is independent of the
lower layer in the context of Rec. H.323. It is not only for the radio layer
(link), but also for the network and transport layer.

Let us examine that there are certain situations where the abstraction of
mobility in the radio layer (link) has an impact on the H.323 layer due to
mobility. The resources in the H.323 layer should be taken care-of
accordingly in mobile environments. Most the radio link layer mobile
interactions will be transparent to the H.323 layer while certain situations
of the radio link layer will have an impact due to mobility. The paging of
the LRQ message is an example.

With respect Motorola's contribution, we may have to discuss: To see whether
the H.323 solution is independent of the radio link layer or not.

I would also refer to see AT&T's contributions submitted in the last Red
Bank meeting (PACs-1651/1652/1664/1665). I would be please to answer any
questions in connection to the proposed solution in the light of the above.

Best regards,
Radhika R. Ro
AT&T

> -----Original Message-----
> From: Laurent.Thiebaut at alcatel.fr [SMTP:Laurent.Thiebaut at alcatel.fr]
> Sent: Tuesday, December 14, 1999 4:11 AM
> To:   Edgar Martinez [1]
> Cc:   H.323 Mobility; Roy, Radhika R, ALARC
> Subject:      Re:Re: Comments on MTD-107a
>
>
>
> Dear Mr Martinez and SG16 H323 mobile group
> The "message" of MTD-107 contribution is to decorrelate H323 mobility from
> radio mobility with the global aim  to support the same H323 mobility for
> both fixed and radio terminals.  That is why MTD-07 proposes:
>    to suppress some radio mobile concepts from H323 mobility, taking into
> account that radio mobility tools/concepts such as paging, hand-over,
> location area, temporary radio mobile identity, .. are used by radio
> access networks in a way that is
>    transparent to the H323 (mobile) layer. This does not mean that moves
> at radio level have no indirect impact on H323 mobility such as change of
> NPOA or change of Serving GK but these indirect impacts are decorrelated
> from the radio technology (GPRS,
>    cdma2000, ...)
>    to introduce the notion of double registration allowing to bring the
> independence between radio networks and H323 mobile network and hence
> independence between radio access technology (GPRS,, cdmaOne, ...)  and
> H323 mobile network.
>
> Note that the solution proposed in MTD-107 allows various operational
> situations such as a separation between the administrative domain of the
> (possibly radio) access and the administrative domain of H323 mobility.
> This separation is rendered easy by the
> decoralation of the (possibly radio) access functions and the  H323
> mobility functions.
>
> On the other hand putting the GK in the SGSN or in any radio related
> function (as I understand is proposed in Motorola's MTD-305) does not
> bring the independence of H323 mobility from radio access (network and
> technology).  Furthermore  putting BTS or IP
> Radio Access Network in the scope of H323 mobility (as I understand is
> proposed in Motorola's MTD-305) implies very high ties between H323 mobile
> and radio technology.
>
> Mr Martinez, may be I have mis-understood MTD-305, in which case I would
> please ask you to give further explanations.
>      Best regards
>         Laurent T.
> --------------------------------------------------------------------------
> -
>       V    Laurent Thiebaut      tel: +33 (0)1 3077 0645
> A L C A T E L                    e.mail:laurent.thiebaut at alcatel.fr
> --------------------------------------------------------------------------
> -
>
>
>
>
>
> "Edgar Martinez [1]" <martinze at cig.mot.com> on 14/12/99 01:44:04
>
>
>
>  To:      "H.323 Mobility" <ITU-SG16 at mailbag.cps.intel.com>
>
>  cc:      "Roy, Radhika R, ALARC" <rrroy at att.com>, Laurent
>           THIEBAUT/FR/ALCATEL at ALCATEL
>
>
>
>  Subject: Re: Comments on MTD-107a
>
>
>
>
>
>
> Dear Radhika and Mr. Thiebaut,
>
> In reference to Alcatel's MTD-107a (v.s.) Motorola's MTD-305c.
>
> We (Motorola) would like to move 3GPP option 1 to a full IP solution
> within the H.323 mobility framework. Unlike MTD-107a, Motorola is working
> on one Universal IP solution that will support both fixed and mobile
> terminals
> and user and network services for voice, data and multi-media.
> Not just GPRS mobile data services.
>
> Right now 3GPP R'00 option 1 has two networks a GPRS and an IP network,
> which are shown side by side. 3GPP option 2 adds a third dimension a
> circuit
> switch side.
> Where 3GPP option 2 is composed of different  three networks, GPRS, IP
> and Circuit switched.
>
> As matter of fact, UMTS R'99 has no IP, UMTS R'99 has the MSC and
> SSGN radio interfaces attached via an array of BSCs and RNCs and a
> mix of Iu-ps and Iu-cs connections.  One can say that option 2 is just
> R'99 with
>
> access to some H.323 IP elements like a gateway and gatekeeper
> and that's all we get. See MTD-107a, MTD-08, 3GPP's TR23.922
> and TR23.002 to see for yourself.
>
> The framework for MTD-305c is for the H.323 system to be able to
> interwork with the legacy network's both mobile and fixed systems,
> while also providing  new technology and services to the IP network.
>
> "Roy, Radhika R, ALARC" wrote:
>
> > Hi, Laurent:
> >
> > Please see my reply provided below.
> >
> > My view point is: Let us keep doors open for all probable solutions. Let
> > people implement their solutions as they find optimal for their specific
> > environments.
> >
> > Best regards,
> > Radhika R. Roy
> > AT&T
> >
> > > -----Original Message-----
> > > From: Laurent.Thiebaut at alcatel.fr [SMTP:Laurent.Thiebaut at alcatel.fr]
> > > Sent: Monday, December 13, 1999 1:01 PM
> > > To:   Roy, Radhika R, ALARC
> > > Cc:   'paul.k.reddy at intel.com'; 'vineet.kumar at intel.com';
> > > 'jaakko.sundquist at nokia.com'; 'peeter.pruuden at nokia.com';
> > > 'senthil.sengodan at nokia.com'; 'marc.roelands at siemens.atea.be';
> > > 'martinze at cig.mot.com'; 'lpg019 at email.mot.com'; 'orsic at lucent.com';
> > > 'stephen.terrill at ericsson.com'; 'gosta.linder at lme.ericsson.se';
> > > 'Anders.Svennevik at era.ericsson.se'; 'mike at synacom.com';
> 'stu at synacom.com';
> > > 'paul.jones at ties.itu.int'; 'baronson at acm.org';
> > > Ameneh.Zahir-Emami at alcatel.fr; Nicolas.Tran at alcatel.fr
> > > Subject:      RE: Comments on MTD-107a
> > >
> > >
> > >
> > > Hi Radhika,
> > >    I do not understand what you mean by "take care-of some special
> needs
> > > in mobile environment" as a need for Temporary IDs. My understanding
> is
> > > that  H.323 alias ("E.164, email, URL,and others" as you mention) are
> not
> > > modified when the user moves because
> > >    it is  these aliases that allow to reach the user even when the
> user
> > > moves (and its NPOA changes). Could you please clarify what you mean?
> >         [Roy, Radhika R]  What I envision that "Temporary ID" can also
> be
> > another " H.323 alias" considering the mobile environment. So, it is an
> > extension of the present H.323 alias addresses.
> >
> > >    for paging: my understanding is that through a RRQ, the mobile
> gives
> > > the association between its alias(es) and its NPOA (IP) address to its
> > > Serving GK that stores the association in internal tables.  When there
> is
> > > a mobile terminated call, thanks to
> > >    HLF-VLF interactions (as described in Nokia's MTD104), the Serving
> GK @
> > > is determined. Then the set-up message is sent to the Serving GK.
> Using
> > > the internal table populated at RRQ, the Serving GK sends the set-up
> > > message to the called mobile with the
> > >    right NPOA (IP) address. This packet is received by the Access
> Network
> > > that may have to page the mobile, but this paging is transparent to
> H323.
> > > Could you please explain me what you see as wrong in the scenario I
> have
> > > given.
> >         [Roy, Radhika R]  This may be another alternative solution as
> you
> > have mentioned. At present, LRQ messages are sent between the GKs for
> > address resolution. Extending the same scenarios, paging of LRQs in
> mobile
> > environment may be needed.
> >
> > >  Best regards
> > >         Laurent T.
> > >
> --------------------------------------------------------------------------
> > > -
> > >       V    Laurent Thiebaut      tel: +33 (0)1 3077 0645
> > > A L C A T E L                    e.mail:laurent.thiebaut at alcatel.fr
> > >
> --------------------------------------------------------------------------
> > > -
> > >
> > >
> > >
> > >
> > > "Roy, Radhika R, ALARC" <rrroy at att.com> on 08/12/99 19:12:32
> > >
> > >
> > >
> > >  To:      Laurent THIEBAUT/FR/ALCATEL at ALCATEL
> > >
> > >  cc:      "'paul.k.reddy at intel.com'"
> > >           <paul.k.reddy at intel.com>,
> > >           "'vineet.kumar at intel.com'"
> > >           <vineet.kumar at intel.com>,
> > >           "'jaakko.sundquist at nokia.com'"
> > >           <jaakko.sundquist at nokia.com>,
> > >           "'peeter.pruuden at nokia.com'"
> > >           <peeter.pruuden at nokia.com>,
> > >           "'senthil.sengodan at nokia.com'"
> > >           <senthil.sengodan at nokia.com>,
> > >           "'marc.roelands at siemens.atea.be'"
> > >           <marc.roelands at siemens.atea.be>,
> > >           "'martinze at cig.mot.com'" <martinze at cig.mot.com>,
> > >           "'lpg019 at email.mot.com'" <lpg019 at email.mot.com>,
> > >           "'orsic at lucent.com'" <orsic at lucent.com>,
> > >           "'stephen.terrill at ericsson.com'"
> > >           <stephen.terrill at ericsson.com>,
> > >           "'gosta.linder at lme.ericsson.se'"
> > >           <gosta.linder at lme.ericsson.se>,
> > >           "'Anders.Svennevik at era.ericsson.se'"
> > >           <Anders.Svennevik at era.ericsson.se>,
> > >           "'mike at synacom.com'" <mike at synacom.com>,
> > >           "'stu at synacom.com'" <stu at synacom.com>,
> > >           "'paul.jones at ties.itu.int'"
> > >           <paul.jones at ties.itu.int>, "'baronson at acm.org'"
> > >           <baronson at acm.org>, Ameneh
> > >           ZAHIR-EMAMI/FR/ALCATEL at ALCATEL
> > >
> > >
> > >
> > >  Subject: RE: Comments on MTD-107a
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi, Laurent:
> > >
> > > Paging: A simple answer will be to locate the mobile user for
> resolving
> > > the
> > > address needed in the LRQ message.
> > >
> > > Temporary ID: H.323 aliases are open enough to include E.164, email,
> URL,
> > > and others. In the same token, if mobile users also need to introduce
> > > other
> > > IDs similar such as Temporary IDs, Personal IDs, etc. to , we should
> be
> > > open to those suggestions.
> > >
> > > Best regards,
> > > Radhika R. Roy
> > > AT&T
> > >
> > > > -----Original Message-----
> > > > From:   Laurent.Thiebaut at alcatel.fr
> [SMTP:Laurent.Thiebaut at alcatel.fr]
> > > > Sent:   Wednesday, December 08, 1999 11:09 AM
> > > > To:     Roy, Radhika R, ALARC
> > > > Cc:     Roy, Radhika R, ALARC; 'paul.k.reddy at intel.com';
> > > > 'vineet.kumar at intel.com'; 'jaakko.sundquist at nokia.com';
> > > > 'peeter.pruuden at nokia.com'; 'senthil.sengodan at nokia.com';
> > > > 'marc.roelands at siemens.atea.be'; 'martinze at cig.mot.com';
> > > > 'lpg019 at email.mot.com'; 'orsic at lucent.com';
> > > > 'stephen.terrill at ericsson.com'; 'gosta.linder at lme.ericsson.se';
> > > > 'Anders.Svennevik at era.ericsson.se'; 'mike at synacom.com';
> > > 'stu at synacom.com';
> > > > 'paul.jones at ties.itu.int'; 'baronson at acm.org';
> > > > Ameneh.Zahir-Emami at alcatel.fr
> > > > Subject:     Re: Comments on MTD-107a
> > > >
> > > >
> > > >
> > > > Hi, Everyone, this is just to answer to Roy's remark
> > > > Hi Radhika,
> > > >    I agree with you when you say that "the lower layer mobility may
> > > cause
> > > > an impact on
> > > >    the higher layer (e.g., H.323) as well. If it is so, the proper
> > > > abstraction
> > > >    in the higher layer (e.g., H.323) should be there to take care of
> > > this
> > > >    situation."
> > > >    That's just the reason why we have deleted the notion of
> ?Location
> > > Area
> > > > Identity (set of Network of Attachments associated)? and ?Temporary
> > > > Identity?. but added the notions of  "change of NPOA or of H323
> Point of
> > > > Attachment may need to be dealt with
> > > >    within H323 scope".
> > > >    I'd better see alias @" in the list of concepts used by H323
> mobility
> > > > instead of "Temporary Id" that looks (for me with too much of a
> mobile
> > > > culture I admit) like the temporary Identifier allocated on radio to
> > > hide
> > > > the permanent user identity
> > > >    Could you explain the need of paging
> > > > Best regards
> > > > L. Thiebaut
> > > >
> > > >
> > >
> --------------------------------------------------------------------------
> > > > --------------------------------------------------------------------
> > > >
> > > >
> > > > Hi, Everyone:
> > > >
> > > > We are in receipt of the contribution from Alcatel (MTD-107a:
> Contact -
> > > > Laurent Thiebaut). For the interest of time, I take the liberty to
> offer
> > > > my
> > > > comments.
> > > >
> > > > I fully agree with the proposal of Laurent that H.323 Mobility
> should
> > > > focus
> > > > only on the H.323 mobility layer. In fact, the terms of reference of
> the
> > > > H.323 mobility group has also confirmed this. However, some specific
> > > texts
> > > > that Laurent have proposed may create some confusions. Let me
> expalin as
> > > > follows :
> > > >
> > > > If the lower layer mobility (e.g., radio link or network layer) is
> > > > transparent to the H.323 layer, nothing needs to done in the H.323
> > > > application layer. However, the lower layer mobility may cause an
> impact
> > > > on
> > > > the higher layer (e.g., H.323) as well. If it is so, the proper
> > > > abstraction
> > > > in the higher layer (e.g., H.323) should be there to take care of
> this
> > > > situation.
> > > >
> > > > For example, switching of cells (e.g., cellular IP) may not cause
> any
> > > > impact
> > > > in the H.323 layer. In this situation, this mobility is transparent
> to
> > > the
> > > > H.323 layer. In some situation, the swiching of cells may also cause
> an
> > > > impact on the H.323 layer (e.g., H.323 point of attachment). In this
> > > case,
> > > > resources of the H.323 layer should also be taken care-of
> accordingly.
> > > >
> > > > Temporary IDs may also be needed in the H.323 layer. Contributions
> are
> > > > provided why these IDs are needed in the H.323 layer. These are the
> > > alias
> > > > addresses and can have an astraction in the H.323 layer. That does
> NOT
> > > > mean
> > > > in anyway that the solution of the H.323 is becoming specific to the
> > > radio
> > > > link layer.
> > > >
> > > > Similarly, LRQ message sets have the addresses that have been
> abstracted
> > > > in
> > > > the H.323 layer. Contributions have been provided why the paging of
> the
> > > > LRQ
> > > > message is needed in the H.323 layer.
> > > >
> > > > (However, I agree with him that location area may NOT be needed in
> H.323
> > > > because the concepts of H.323 zones/domains will be sufficient. In
> same
> > > > token, we also do not need the concept of cells in H.323.)
> > > >
> > > > I find that texts proposed in the contribution are too restrictive.
> > > >
> > > > Finally, I propose that Laurent should keep an eye to the H.323
> solution
> > > > that will be agreed upon should be transparent to the lower layer
> (e.g.,
> > > > radio link or network layer) as we make more progress in this area.
> > > >
> > > > Best regards,
> > > > Radhika R. Roy
> > > > AT&T
> > > > + 1 732 420 1580
> > > > rrroy at att.com
> > > >
> > > >
> > > >
> > > >
> > >
> > >
>
> --
> 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