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@alcatel.fr [SMTP:Laurent.Thiebaut@alcatel.fr]
Sent: Monday, December 13, 1999 1:01 PM
To: Roy, Radhika R, ALARC
Cc: 'paul.k.reddy@intel.com'; 'vineet.kumar@intel.com';
'jaakko.sundquist@nokia.com'; 'peeter.pruuden@nokia.com';
'senthil.sengodan@nokia.com'; 'marc.roelands@siemens.atea.be';
'martinze@cig.mot.com'; 'lpg019@email.mot.com'; 'orsic@lucent.com';
'stephen.terrill@ericsson.com'; 'gosta.linder@lme.ericsson.se';
'Anders.Svennevik@era.ericsson.se'; 'mike@synacom.com'; 'stu@synacom.com';
'paul.jones@ties.itu.int'; 'baronson@acm.org';
Ameneh.Zahir-Emami@alcatel.fr; Nicolas.Tran@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@alcatel.fr
--------------------------------------------------------------------------
-
"Roy, Radhika R, ALARC" <rrroy@att.com> on 08/12/99 19:12:32
To: Laurent THIEBAUT/FR/ALCATEL@ALCATEL
cc: "'paul.k.reddy@intel.com'"
<paul.k.reddy@intel.com>,
"'vineet.kumar@intel.com'"
<vineet.kumar@intel.com>,
"'jaakko.sundquist@nokia.com'"
<jaakko.sundquist@nokia.com>,
"'peeter.pruuden@nokia.com'"
<peeter.pruuden@nokia.com>,
"'senthil.sengodan@nokia.com'"
<senthil.sengodan@nokia.com>,
"'marc.roelands@siemens.atea.be'"
<marc.roelands@siemens.atea.be>,
"'martinze@cig.mot.com'" <martinze@cig.mot.com>,
"'lpg019@email.mot.com'" <lpg019@email.mot.com>,
"'orsic@lucent.com'" <orsic@lucent.com>,
"'stephen.terrill@ericsson.com'"
<stephen.terrill@ericsson.com>,
"'gosta.linder@lme.ericsson.se'"
<gosta.linder@lme.ericsson.se>,
"'Anders.Svennevik@era.ericsson.se'"
<Anders.Svennevik@era.ericsson.se>,
"'mike@synacom.com'" <mike@synacom.com>,
"'stu@synacom.com'" <stu@synacom.com>,
"'paul.jones@ties.itu.int'"
<paul.jones@ties.itu.int>, "'baronson@acm.org'"
<baronson@acm.org>, Ameneh
ZAHIR-EMAMI/FR/ALCATEL@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@alcatel.fr [SMTP:Laurent.Thiebaut@alcatel.fr]
Sent: Wednesday, December 08, 1999 11:09 AM
To: Roy, Radhika R, ALARC
Cc: Roy, Radhika R, ALARC; 'paul.k.reddy@intel.com';
'vineet.kumar@intel.com'; 'jaakko.sundquist@nokia.com';
'peeter.pruuden@nokia.com'; 'senthil.sengodan@nokia.com';
'marc.roelands@siemens.atea.be'; 'martinze@cig.mot.com';
'lpg019@email.mot.com'; 'orsic@lucent.com';
'stephen.terrill@ericsson.com'; 'gosta.linder@lme.ericsson.se';
'Anders.Svennevik@era.ericsson.se'; 'mike@synacom.com';
'stu@synacom.com';
'paul.jones@ties.itu.int'; 'baronson@acm.org';
Ameneh.Zahir-Emami@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@att.com