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