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

Roy, Radhika R, ALCOO rrroy at ATT.COM
Sun Apr 1 18:35:32 EDT 2001

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.,

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., 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

Best regards,
Radhika R. Roy

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

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at

More information about the sg16-avd mailing list