H323mobility: Summary of discussion

Roelands Marc Marc.Roelands at SIEMENS.ATEA.BE
Fri Nov 5 05:35:36 EST 1999


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



More information about the sg16-avd mailing list