H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q.13/1 6

[Roy, Radhika R, ALCOO]

Hi, Everyone (including Rapporteurs and WP 2 Chairman):

I appreciate that Istvan Sebestyen has rightly pointed out, " ... By this
development the "enterprise" and the "mobile carrier" solution are likely to
develop separately, which is not too good for compatibility and
interoperability."

I am just curious to know more technical insights: Enterprise vs. Carrier
solution for H.323 mobility. It is a very useful discussion to clarify
further what we are up to. May be I have missed some of the discussions.

H.323 is a transport independent multimedia application. So, H.323 mobility
solution is applicable for both wire-line and wireless (wireless LAN,
packet-switched [pico-, micro-, and macro-cell) network.

So, as Istvan pointed out, the H.323 mobility solution will be only one that
is applicable for all networking conditions.

The next question comes: Does H.323 Annex H is going to meet our objectives
as it stands now?

The answer is "No."

First of all: What is the mandate of Annex H? Its mandate is to extend H.323
to support mobility.

What do we mean by H.323 protocol? These protocols are H.323 base specs,
H.225.0 (RAS, Q.931, Annex G),and H.245 where the communications are
performed among the H.323 entities: Terminals, GKs, BEs, and GWs.

So, Q.13/16 has the charter to extend those protocols to support mobility
among its functional entities: Terminals, GKs, BEs, and GWs.

If you examine the write-up of the present Annex H, one can easily see that
there is almost no mention how the H.323 base specs, H.225.0 (RAS, Q.931,
Annex G) need to be extended to support mobility among H.323 entities like
Terminals, GKs, BEs, and GWs. Many contributions are there, and many emails
have been sent. But nothing is coming out of this.

Rather, it is interesting to see that some folks are trying to push
something that may not be the charter of Q.13/16, or even may not be the
charter of SG16. For example, communications between VLF and HLF, between
VLF and AuF, or between HLF and AuF. These are generic protocols and no
special treatment is needed because of H.323. For example, IMT-2000 is also
working in this area. We can use those protocols for this purpose, or if
needed, a joint work item can be developed between the SG16 and other SGs.
We are NOT sure why we are spending an enormous amount of time in doing this
in Q.13/16 while ignoring the basic work of Q.13/16 to extend the existing
H.323 protocol to support mobility for its existing functional entities.

Another wild suggestion is being made: Use of the H.323 Annex G for the
VLFs, HLFs, AuFs, etc. This suggestion shows how we are creating confusions
in the development of mobility protocol. VLFs, HLFs, AuFs, etc. are known as
the backend servers, and these protocols are known as the backend services
(BES) protocols. H.323 has NOT developed any BES protocol so far.

Please note that H.225.0 Annex G protocol is being used for communications
between the GKs/BEs, and "NOT" for communications between the Backend
servers like VLFs, HLFs, AuFs, etc.

The protocols for communications between VLF and HLF, between VLF and AuF,
or between HLF and AuF should be a separate sets of protocols, not the
extension H.225.0 Annex G. However, these protocols may use some useful
functional features that are suitable for the backend services protocols
(e.g., hopcount, etc.), but these MUST be termed as the NEW backend services
protocols.

Many contributions have been made to explain those things. I have not seen
any progress that we have made so far in this direction.

So, the final proposal is this for H.323 Annex H:

1. First, finish the extension of the existing H.323 base specs, and H.225.0
(RAS, Q.931, Annex G)to support mobility among the H.323 entities:
Terminals, GKs, BEs, and GWs. (see the contributions that are being made so
far).

2. Second, develop a clear mandate whether the backend protocols like VLF
<-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of Q.13/16 only, or
these protocols need to be worked with other SGs. (see the contributions
that are being made so far).

3. Third, any protocols that re being used between VLF <-> HLF, VLF <-> AuF,
HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or its extension
because these are separate protocols and serve completely different purposes
although may useful properties (e.g., hopcount, etc.) of the Annex G
protocol can be used for these protocols.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Sebestyen Istvan ICN M CS 27
[mailto:Istvan.Sebestyen at ICN.SIEMENS.DE]
Sent: Tuesday, September 05, 2000 6:21 AM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: response to open letter from Tom Taylor
Importance: High


Dear Colleagues,

... By this development the
"enterprise" and the "mobile carrier" solution are likely to develop
separately, which is not too good for compatibility and interoperability.

Kind regards,
Istvan Sebestyen

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com