H323mobility: Summary of discussion

[Edgar Martinez [1]]

I agreed with most of Jaakko comments and also
make vaild points, and will like to
add the following.

I believe that the (Home) in Home  Zone should be taken out.
What we are talking about is the User's Point of Attached in
any given Zone. The HLF is ready and  Data base
which has the User's profile and the current user's location.
We can get a new name to HLF and call it the Location Profile
Register (LPR) or Location Profile Function (LPF).

I also believe that the (Visited) in Visited Zone sould also
be taken out because again we are talking about
the Users current Point of Attachment in any given Zone.
The VLF has the means to update the
Location Profile Register (LPR) from
any given Zone. We can get a new name to VLF
call  it the  Location Update Register (LUR) or
Location Update Function (LUF).

Now we can also support concepts of Zone ID's
such as Current Zone ID and Previous Zone ID.

Finally,

And I strongly agree with looking at the interworking
in parallel with H.323 mobility. The time we spent
now looking at interworking will be compensated in the
long run. I sure does working on ISUP, IN  and Qsig, inetrworking
with H.323 would agree and we should learn from their experience.
And not leave it for a last minute add-on.

Lets take the contribution as they come, if one wants to put in
interworking fine. If one wants to put in contributions only H.323
mobility also fine. Both are in order and within our scope.

The general strategy should focus on ensuring that the H.323
Mobility and interworking options are enabled, rather than spending
too much effort blocking alternative options (Our limited resources
frankly don't allow this luxury). But there really is no substitute for
doing the work - preparing input papers and presenting them
to move things forward.

Best Regards,

Ed

Jaakko Sundquist wrote:

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

--
Edgar Martinez - Principal Staff Engineer
Email mailto:martinze at cig.mot.com
FAX 1-847-632-3145 - - Voice 1-847-632-5278
1501 West Shure Drive, Arlington Hgts. IL 60004
Public: TIPHON & Other Stds - http://people.itu.int/~emartine/
Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/