Hi, Everyone:

Yesterday, we had a brief discussion with the above contribution. Please note the following:

1. MGA has been proposed as another alternative mechanism to take care-of the problems of GRQ/GCF/GRJ messages. The Bandwidth problems have been taken care-of because it can be unicast as well, if needed. If anyone has any more comments, please let us know.

(GRQ/GCF/GRJ messages have serious limitations in many mobile communications environments. For example, sending of GRQs to discover GKs while the mobile is moving from place to place. In addition, we have just discovered how authentication messages are causing problems when the multicast GRQs are sent to many GKs, and every GKs start processing these messages while the mobile has to choose an unique GK that will be its GK in that particular place given the fact it is changing its network point of attachment. How does a mobile can decide a unique GK in a dynamic environment when the multiple GKs respond back? Does the load (bandwidth) not increase lineally by 2*N [where N = # of users] for all GKs of all zones around the whole domain?)

2. GK needs to be allowed to communicate with HLF directly while service provisioning is done to populate the HLF to store the profile of the mobile users.

3. RRQ messages are NOT sent to the HLF. It is a "new" message that will be used between the GK and HLF, however, the mobility related information provided in RRQ will be communicated to the HLF via the "new" message.

In addition, the decision has been made that, like Annex G messages, LRQ messages should also be augmented to support mobility.

We already know (as explained in Annex H) that there can be many HLFs, VLFs, etc. in a given domain, and no architectural restriction will be provided in the protocol whether HLFs are centralized or distributed.

If you have any questions, please let me know.

Best regards, Radhika R. Roy AT&T

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