Mob ad hoc group progress

Roy, Radhika R, ALARC rrroy at ATT.COM
Thu Apr 6 15:56:55 EDT 2000


Hi, Paul and All:

I appreciate your clarifications.

I also like to re-emphasize that all other emails sent by me in response to
other members also complement your explanations. Please also see my other
mails how I have interpreted the word "intra-network" mobility management.

If there are any questions, please let me know.

Best regards,

Radhika R. Roy
AT&T
H.323 Ad Hoc Mobility Group
+1 732 420 1580
rrroy at att.com

> -----Original Message-----
> From: Guram Paul-LPG019 [SMTP:lpg019 at EMAIL.MOT.COM]
> Sent: Thursday, April 06, 2000 8:42 AM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      Re: Mob ad hoc group progress
>
> 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