Re: H323mobility: meeting

2 Nov 1999

      Hi, Ed and All:
Thanks for your reply.
To answer your question: "To test H.323 Mobility architecture combining both
AT&T's and Motorola's contributions," let me suggest the following:
1. Let us discuss off-line via a conf call because contributions are really
lengthy.
2. We can then send our individual comments in the SG16 reflector: What you
have found in common and what we have not agreed.
In this way, we might be able to focus to the appropriate points more
clearly. After that SG16 members can also provide their comments.
In addition, we will also be discussing in the upcoming conf calls on-going
basis.
Hope this will be acceptable to you.
Best regards,
Radhika
...
-----Original Message-----
From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM]
Sent: Monday, November 01, 1999 10:24 PM
To:   ITU-SG16@MAILBAG.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:

Mobile H.323 Terminal to Mobile H.323 Terminal
Mobile H.323 Terminal to Fixed H.323 Terminal and vice versa
Cellular-PSTN Terminal to Mobile H.323 Terminal (3a) and vice versa

(3b)
...

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@CIG.MOT.COM]
Sent: Monday, November 01, 1999 3:14 PM
To:   ITU-SG16@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@CIG.MOT.COM]
Sent: Monday, November 01, 1999 12:34 PM
To:   ITU-SG16@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@att.com
> -----Original Message-----
> From: jaakko.sundquist@NOKIA.COM
[SMTP:jaakko.sundquist@NOKIA.COM]
...
...
...
...
...
> Sent: Monday, November 01, 1999 7:23 AM
> To:   ITU-SG16@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

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@cig.mot.com]
>                 Sent:   Monday, November 01, 1999 3:33 AM
>                 To:     ITU-SG16@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@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@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@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@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/