jaakko.sundquist at NOKIA.COM jaakko.sundquist at NOKIA.COM
Tue Nov 2 03:40:52 EST 1999

Hi again Ed, Radhika et al

As you had quite a bit of conversation during my out-of-office hours, I'll
try to include all my comments on the discussion in this one mail.

First of all, I do not understand Ed's comment about the HomeZone ID &
VisitedZone ID not clashing with the meaning of zone. Surely these are meant
to be some identifiers for certain zones. I did not, btw. propose the
concepts Home Area and Visited Area, these terms are in my opinion not good
terms and I just tried to illustrate my point with using them in the earlier
mail. Thus I propose that we do not use them. What I was trying to say in
the earlier mail is this: we have not agreed where the HLF and VLF (or AuF
for that matter) should be placed in the architecture. The concept of
HomeZone implies that each User has one zone which is his/her/its home, thus
also implying that the HLF must be associated with the GK of that zone and
no other GK (of course other GKs could have their own HLFs). Similarly each
GK would have their own VLFs. When I introduced the concepts of Home Domain
and Visited Domain, I was thinking about the HLF and VLF being
functionalities that are used by all the GKs in the Domain, thus I would
rather associate them with e.g. the BE than the GK. The point is that we
have not defined or even really discussed the architecture yet, so let's not
define terms that already point to a certain direction in the architectural

As for the Location Area (LA) concept, my contribution (APC-1659) did not
actually present it as a subset of a zone. I tried to define it in such a
way that I would not restrict the possible Network Points of Attachment that
can belong to a LA. The result in the end was, I agree, quite complicated,
allowing the LA to be either a subset, a superset (one LA includes NPoAs in
many zones) or equal to a zone (LA = zone). I think we have to discuss
further how the LA should be defined (complexity vs. scalability), but I do
think that the concept is a valuable one and should be adopted.

I also think that the two-step approach of first defining the
functionalities for "pure" H.323 Mobility and only after that the functions
needed for PLMN interworking may not be the best approach. I think that we
need to consider the interworking case also when defining the pure H.323
case. This way we can take both cases into account, thus reducing
unnecessary work in the second phase, i.e. the interworking phase. I'm not
saying that we should define the interworking as a whole simultaneously with
the pure H.323 mobility, but I would like to always consider the effects of
our decisions to the interworking issue, when we are defining the pure H.323

Lastly, I read Ed's draft for Annex H and I just have one small comment. In
the scope it says something about the fact that the NPoA can change. I think
we agreed that it should have stated that the NPoA can change also during a
call, thus allowing handovers. I would like to see this in there just to
avoid having the same discussions again. I'm sorry that I didn't catch this
one already in Red Bank.

- 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