Information for traveling to the SG16 meeting in Brazil

[Patrick Luthi]

Dear experts,

Further to Mr. Roy message, I would like to make some comments :

1- Considering that any H.323 mobile user IS CONSIDERED ALSO AS A MOBILE
USER by his network access provider and all his other service providers,
there are two ways to design the H.323 functional architecture to support
mobility :
        way A : define specific functional entities for mobility management
in H.323 systems (HLF, VLF and AuF) without                     regarding
mobility issues in external systems. Physically, each FE represents the
database (containing ONLY data          related to H.323 user and services)
and the associated processes (access, updating...). Relevant interfaces
between theses FEs and other FEs like GK, BE and IWF are defined. A specific
protocol is defined also only for               H.323 MM purpose.
        way B : Consider the mobility management as a service to make PER
USER, and NOT PER USER AND PER SYSTEM. define the               database
containing data related to H.323 user and services. This database may be
considered as a subset of the           global database related to the H.323
mobile user (this global database contains also data related to the network
access providing, billing, and other services). This global database and its
associated processes (access,                   updating...) are common to
different systems (related to the different access and service providers)
and are seen            as common FEs (AuF, HLF, VLF). Define also relevant
interfaces between H.323 FEs and HLF,VLF,AuF-like FEs that
doesn't belong only to H.323 functional architecture. A common protocol (or
a protocol primarly designed for                H.323   systems but
containing extensions to be supported on interfaces between FEs from
different                               systems, e.g. protocol compatible
with different protocol stacks, different address formats, etc...).

Regarding that any actual user subscribes more and more services that are
more and more complex to implement, adopting the way A implies to solve
serious problems of Mobility Management performance, because the HLF, if
supposed to contain only data related to H.323 user mobility, need to access
and update data in external databases, implying message and parameter
conversion, interface multiplication, etc..., for different purposes (e.g.
service interaction). Currently, the way A is chosen in H.MMS.1. I agree
with Mr. Roy arguments by preferring the way B.

2- Because some interfaces are used both for MM in H.323 systems and between
H.323 and mobile systems, the same protocol should be used for
simplification. The protocol defined defined in H.MMS.1 (H.225.0 annex G),
because H.323-oriented by nature, can't be optimized for a using in H.MMS.2.
I also agree with Mr. Roy arguments and propose to keep all definitions and
protocol design in H.MMS.1, but change only the name of the protocol, so it
would be possible to make right extensions to this protocol for H.MMS.2.

Best regards,

Francois bougant
ITU-T SG16 WP2 Q.5 participant
H.MMS.2 recommandation editor
France Telecom R&D

-----Message d'origine-----
De : Roy, Radhika R, ALCOO [mailto:rrroy at ATT.COM]
Envoyé : lundi 2 avril 2001 00:36
À : ITU-SG16 at MAILBAG.INTEL.COM
Objet : Issues and Solutions: H.MMS.1 (Mobility for H.323)


Hi, Folks:

Further to my earlier message, I am sending a note related to the
fundamental issues of the present H.MMS.1 (Mobility for H.323) draft. The
note also includes the proposed solutions for all those issues.

Please note that we discussed all those issues in the last November'00 SG16
meeting. We do not want that the same should be repeated in the upcoming
SG16 May-June'01 meeting. In this regard, I also draw the special attention
of editors of H.MMS.1 and H.225.0 Annex G, Rapporteurs of Q5/16 and Q2/16,
and Mr. Tosco as well.

Issues and Solutions of H.MMS.1 (Mobility for H.323):

1. Problem A: The document (Section 10, H.NMS.1 Mobility for H.323
Multimedia Systems [MD-112, AVD-2053a]) still shows that HLF, VLF, and AuF,
as if, are another sets of H.323 functional entities (like GKs, BEs, MCUs
and terminals) that are entitled to use H.323/H.225.0 (RAS,
Q.931/932)/H.225.0 Annex G protocols. However, like many other services such
as directory, billing, and others, HLF, VLF, and AuF are the backend
services and the protocols used by those entities must NOT be called a part
of the H.323/H.225.0 protocol because these backend services protocols can
be used by other application protocols (e.g., H.234, H.310) as well.

Problem B: If the mobility management protocol is called H.225.0 Annex G, it
cannot be used or extended for the global mobility management purpose (e.g.,
H.MMS.2).

Problem C: More functionalities like Authentication, Charging/Billing,
Directory, Policy, and other entities are needed for mobile (and even for
non-mobile) functions. We cannot use make them as a part of H.323 protocol.

Problem D: We cannot make one HLF/VLF/AuF  protocol for H.323, another
HLF/VLF/AuF  protocol for H.324, and another for H.310, and another for
IMT-2000. The same protocols MUST be allowed to be used by any applications
whenever needed without providing any restrictions.

Solution for problems A, B, C, and D: No functional entity like HLF, VLF,
AuF, Charging/Billing, Policy, Directory or others will be defined as the
H.323 functional entity. Rather, each of this entity will be a backend
functional entity and the protocol among these entities must be independent
of the H.323/H.225.0 Annex G protocol. The protocol used among HLF, VLF, and
AuF entities may have all capabilities, functionalities and features as
described in the document, but MUST be called a different protocol (e.g.,
M.management) so that all application protocols including H.323 will be at
liberty to use it. So, the said protocol MUST NOT be called H.225.0 Annex G
or its extension. In other words, we are changing the name only (not the
capabilities, functions, or features). Similar will be the case for
Charging/Billing, Policy, Directory or others.

2. Problem: Mobility management procedures (Section 10, H.NMS.1 Mobility for
H.323 Multimedia Systems [MD-112, AVD-2053a (Figure 11a)]) still indicate
that there is only one HLF that communicates directly with the VLFs located
in two separate administrative domains. This breaks the fundamental concept
of the administrative domains as standardized in H.323 because an
administrative domain is autonomous and can communicate only through the BEs
(with one HLF, this principle is violated and breaks the basic foundation of
H.225.0 Annex G).

Solution: Similar to inter-zone (e.g., Figure 13 of AVD-2053a), the
communications between the two administrative domains MUS be made via the
BEs no matter whether there is one or multiple HLFs. Communications
scenarios with at least one HLF in each administrative domain needs to be
shown.

Best regards,
Radhika R. Roy
AT&T


Technology Consultant
Room 3D-2C09
200 S. Laurel Avenue
Middletown, NJ 07748
+1 732 420 1580
rrroy at att.com

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

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

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