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@ATT.COM] Envoyé : lundi 2 avril 2001 00:36 À : ITU-SG16@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@att.com

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

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

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