Hi, Marc: You are right. Best regards, Radhika

-----Original Message----- From: Roelands Marc [SMTP:Marc.Roelands@SIEMENS.ATEA.BE] Sent: Friday, November 05, 1999 5:36 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: H323mobility: Summary of discussion

Hi Jaakko,

Just a small remark on your location area argumentation: "what a LA is for: it is a grouping of NPoAs that are geographically located close to each other" assumes that NPoAs are restricted to a single geographical point of attachment, which, as I understood it, was not the definition we aggreed on. The NPoA in practice will be the IP address, which cannot a priori be restricted to a single geographical area (remember the Mobile IP discussion...).

Regards, Marc

-----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Thursday, November 04, 1999 14:48 To: ITU-SG16@MAILBAG.INTEL.COM Subject: H323mobility: Summary of discussion

Hi, Radhika et al,

It seems that I did not make all my points so clear in my last message (as I said I was pretty tired when I wrote it). Also the discussion between me and Radhika (& Ed) seems to be getting out of hand. Thus I'll try to summarize the points in the discussion and include my views in this message.

As I see it, we have been discussing about three basic issues: - The architectural placement of the HLF and VLF functionalities. The discussion also has included (or actually it started from) the question whether the terms: Home Zone and Visited Zone, with respective identifiers should be defined or not. - The two-step approach of first specifying the pure H.323 Mobility and as a second step the issues related to PLMN interworking. The discussion has been on whether (at least some of the) PLMN interworking issues should be considered while working on the pure H.323 Mobility. - The concept of the Location Area (LA). Whether we need that concept or not and if we need it, should it be considered already in the first step (see the above point).

I'll address all these points below.

THE PLACEMENT OF HLF/VLF AND THE HOME/VISITED ZONE DISCUSSION

I think we both/all agree on one thing: The HLF and the VLF must be defined in the standard in such a way that it is possible for multiple GKs to access the same HLF/VLF. This allows for an approach in which the HLF/VLF is distributed among many GKs while simultaneously allowing the HLF/VLF to be associated with only a single GK, if this kind of a centralized design is desired.

The thing that we disagree on is: I do NOT want to define the terms Home Zone and Visited Zone (or similar) yet. I did not seem to make that clear in my last message. The reasons why I do not want to define this kind of terms, at least yet, are as follows.

The term Home Zone leads in my mind to a definition in which every User is associated with one and only one zone as the User's "Home". I.e. the HLF containing the permanent information about the User can be accessed through the GK of the Home Zone and no other GK. Now, I do not think, Radhika, that this is what you intended, but if we talk about a Home Zone, this is the kind of thing that first comes to my mind. I currently have the idea that you meant that each User may have multiple Home Zones, is that right, Radhika? If that is the case, I do not fully understand why we would need the concept of the Home Zone at all (but maybe I'm just missing something). The important thing in all these Home/Visited concepts is: how to identify and access the HLF of a certain User and by accessing the HLF, update all the relevant information in the HLF and in the VLFs. If there are multiple Home Zones for a User, all the GKs of these zones can be used to access the HLF of the User, i.e. the HLF is identified by the Home Zone identifier (if this is not the case, what is the purpose of the Home Zone). Now, how is it determined, which GK should be Used in this case? The User must always give some "pointer" with which the HLF can be identified when the User enters a zone (or LA, if we use them). In this case the Home Zone ID would be that identifier. If always one of these Home Zones is given as the access point to the HLF, this leads to a highly centralized model with this one single zone and its GK as the central point. If, on the other hand, any of these zones can be given, how is this zone picked, randomly? Furthermore, how does a GK of a User's Home Zone know that it is in fact a "Home GK" for that User, if the User gives some other Home Zone ID than the one of the Home Zone where he is located? All the above reasons, in my opinion, lead to the fact that the HLF must be identified with an identifier that is NOT related to any single zone or GK. This is why I proposed the concept of Home Domain (I use the concept of an Administrative Domain because, as Radhika mentioned, it is already defined in H.323) in my contribution to the Red Bank meeting (APC-1659). In this case the Home Domain would identify the HLF of a User and thus the GKs in the Home Domain could identify that they are in fact a part of the Home Domain and the HLF to which they have access, is the HLF of the User. If the User would be located in some other (Visited) Domain, his HLF could be identified by the Home Domain (thus this model would be BE centric. The Administrative Domain is, of course, not the only alternative to group the zones, which form the "Home" of a User together, I just used it, because it is already defined. We could also define a HLF Identifier which is not related to a Domain, but the GKs of the zones forming the User's "Home" would recognize if the HLF to which they have access is the correct HLF based on this identifier.

THE TWO-STEP APPROACH DISCUSSION

The two-step approach, as I understand it, means that we will first work on a pure end-to-end H.323 Mobility solution and after that has been done we will define the interworking with legacy (and future) mobile networks. Although I do agree that in general this is a good order to do these two things, I would like to see some general interworking aspects taken into consideration in the first phase. One example of these may be the Location Area concept. I do not want to go into details of the interworking issues in the first step, but I'm afraid that if we do not think about the interworking at all in the first step, we will end up defining some functionalities in two different ways, one being the result of the first step and the other an addition to this as the result of the second step when the solution of the first step is not capable of handling some general interworking procedure, for example.

I hope, I made my point clear despite the above text being somewhat rambling...

THE LOCATION AREA DISCUSSION

This is actually an example of the problem I have with the "strict" two-step approach. Radhika is proposing that we try to solve the mobility in the first step without the LA concept. I think it would be very beneficial, if we at least consider it already in the first step. Furthermore, I am quite sure we will need the concept in the second step, or else we will end up with a very badly scalable system. As I said in my earlier message, the LA concept will help to make the H.323 mobile systems more easily scalable, the price for this is, of course, the increased complexity that the LAs bring to the system. To express shortly, what a LA is for: it is a grouping of NPoAs that are geographically located close to each other. A zone also consists of NPoAs, but these NPoAs can actually be geographically far from each other. In other words, a zone is a set of NPoAs that are grouped together for administrative purposes, not because they are close to each other (which they need not be). When we are dealing with wireless mobile terminals, this grouping based on the geographical location becomes important and thus my opinion is that we should consider the LA concept already in the first phase.

- Jaakko Sundquist ------------------------------------------------------- In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort. -------------------------------------------------------