Mob ad hoc group progress

Guram Paul-LPG019 lpg019 at EMAIL.MOT.COM
Thu Apr 6 08:42:04 EDT 2000


Hi mob group

Interesting debate.  Just to say that the following is my understanding of
our next phase of work (please correct me if I am mistaken):

Considering that,

1. All-H.323 scenario does not have any interworking gateways involved to
other non H.323 networks, and we need to start on simple work first  (the
word Scenario is used as per Tiphon),
2. Intra network means pertaining to one single network.  A single network
consists of one administrative domain. One administrative domain may have
one or more zones.  We also have defined home and visited administrative
domains, HLF,VLF, AuF, and now have an equal understanding of these terms,
3. Annex H deals with terminal and user and service mobility issues which we
know inherently implies mobility management,

we, I think, agreed to progress on from Figure 1 MD011 Intra-network
all-H323 scenario and specify call establishment/release etc. procedures for
all of the possible roaming combinations (some examples are outlined in
Stephen Terrill's last email).  This will naturally include specifying the
mobility management functions/interfaces, perhaps stating possible locations
of VLF etc., identifying functionality/interfaces not covered or not
required in the existing architecture diagram, and such issues.  So this
scenario will be defined by us in its entirety in the coming weeks.

Paul

        ----------
        From:   Jaakko Sundquist[SMTP:jaakko.sundquist at nokia.com]
        Reply To:       Jaakko Sundquist
        Sent:   06 April 2000 09:40
        To:     ITU-SG16 at mailbag.cps.intel.com
        Subject:        Re: Mob ad hoc group progress

        Hi all,

        Comments to Radhika's posting below...

        Hi, Everyone:

        We are again not in sink what is going on with respect to progress
of our
        work. Let me try again.

        That is just what I was trying to say...


        We have talked about Nokia's contribution MD-011. We have taught
that this
        provides a reference to start with. In that contribution, we have
Figure 1:
        Intra-zone all H.323 scenario. We have decided that we will go one
step at a
        time.
        First of all the scenario is called all-H.323 scenario. The figures
just try
        to explain what kind of call models that scenario involves. What we
have
        decided is to go one scenario at a time (not one "call model" at a
time).
        Furthermore, it was evident in the last teleconference that the
cases
        illustrated in the figures were not adequate and they need to be
enhanced.


        Now what does this Figure 1 provides us? We are NOT sure unless we
explain
        in detail what this scenario means to us. We cannot go to the next
step
        unless we analyze what the scenario of Figure 1 provides us. It may
or may
        not provide new insights from H.323 mobility point of view, but it
is our
        starting point. We have to complete it first before we go for the
next step.
        In this simple case, a mobile entity will move from its home network
to a
        foreign network. This also requires mobility management: Change in
network
        point of attachment and its possible impact in H.323 system.

        This is just what I mean. What do you mean by the above text? First
of all I
        don't know what you mean by home and foreign network. Are you saying
that
        inside one zone there are multiple networks (so that moving from the
home
        network to a visited network is possible while all the time being
located
        inside the same zone)? You are right in saying that we need to
analyze this
        call model also, but first we need to identify the different cases
for the
        user's location, i.e. both users at home domain, user-A at home
domain &
        user-B in a visited domain, etc.
        Related to the above, we have already defined the terms Home
Administrative
        Domain, Visited Administrative Domain and Serving Administrative
Domain in
        the draft H.323 Annex H. I think that these definitions are very
good
        (thanks to Milo, you see that we do agree on some things once in a
while ;-)
        and they clearly bind the subscription of a user (or a subscriber)
to a
        Domain. My opinion is that this means that the Administrative
Domains are
        the areas that divide the H.323 system into home and visited areas
from the
        point of view of the user. In other words, I wouldn't necessarily
even
        define terms, such as, Home Zone or Home Gatekeeper, because the
above
        definitions already bind the home of a user to the whole domain, not
a
        particular zone. If we want to define the term Home Zone, I think it
should
        mean ANY zone inside the Home Administrative Domain, similarly a
definition
        for the Home Gatekeeper could be made.
        Based on the above, we can assume that when a user is in his/her
Home
        Administrative Domain, the HLF that contains his/her information is
also
        inside that Domain and inter-domain communications are not needed
for the
        Mobility Management of that user. Similarly, if the user is in a
Visited
        Administrative Domain, inter-domain communications are needed for
the
        Serving Administrative Domain to contact the user's HLF. This will
also lead
        to different location management cases for e.g. the intra-zone
all-H.323
        call model.


        Once we complete Figure 1, we will go for the next one: Figure 2
Inter-Zone
        all H.323 scenario. Of course, this is a complicated one to provide
better
        scenario for mobility management: Change in network point attachment
+
        Change in zone (logical) point of attachment as well.

        I think that this is a good way for an individual to work, but
personally I
        would like to see contributions that address more of these call
models at a
        time. We can, of course, deal with the contributions in the order
that
        Radhika is proposing, I have nothing against that.

        A side note: We have defined VLF and HLF. VLF may be assumed to be
        co-located within the GK. But let people explain the interactions
including
        VLF and HLF the way they prefer in their contributions. The
contributions
        themselves will justify how VLF and HLF should perform their
functions. Let
        us not mandate anything beforehand unless things are explained in
the
        contributions.

        One thing I would like to ask the ad hoc group members, is that
should we
        assume at this point that the VLF is co-located with the gatekeeper
(as a
        "composite network element" illustrated in Figure 3 of the draft
H.323 Annex
        H). I think this could be a good assumption in the first version of
Annex H,
        because it seems that most of us are thinking that way already. It
would
        only mean that we wouldn't have to specify anything for the
reference point
        E, but leave it open in the first version of the annex, similarly as
was
        done with reference point B in the H.225.0 Annex G. Other composite
network
        elements could also be identified for the first version of the
annex. I
        think that this kind of grouping could conciderably simplify our
work for
        the first version by reducing the number of interfaces that we need
to
        specify. We should probably encourage contributions proposing the
composite
        network elements and perhaps discuss these contributions in a
teleconference
        (maybe not the next, but the one after that).

        - Jaakko



More information about the sg16-avd mailing list