H323mobility: Summary of discussion
Roy, Radhika R, ALARC
rrroy at ATT.COM
Fri Nov 5 08:44:10 EST 1999
You are right.
> -----Original Message-----
> From: Roelands Marc [SMTP:Marc.Roelands at SIEMENS.ATEA.BE]
> Sent: Friday, November 05, 1999 5:36 AM
> To: ITU-SG16 at 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
> 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
> the Mobile IP discussion...).
> -----Original Message-----
> From: Jaakko Sundquist [mailto:jaakko.sundquist at NOKIA.COM]
> Sent: Thursday, November 04, 1999 14:48
> To: ITU-SG16 at 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
> said I was pretty tired when I wrote it). Also the discussion between me
> 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
> second step the issues related to PLMN interworking. The discussion has
> 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
> 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
> 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
> 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
> my last message. The reasons why I do not want to define this kind of
> 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
> the GK of the Home Zone and no other GK. Now, I do not think, Radhika,
> 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
> 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
> HLF of the User, i.e. the HLF is identified by the Home Zone identifier
> this is not the case, what is the purpose of the Home Zone). Now, how is
> determined, which GK should be Used in this case? The User must always
> 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
> 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
> identified with an identifier that is NOT related to any single zone or
> 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
> 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,
> 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
> 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
> 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
> 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
> THE LOCATION AREA DISCUSSION
> This is actually an example of the problem I have with the "strict"
> 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
> 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
> 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
> 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.
More information about the sg16-avd