Mob ad hoc group progress
Roy, Radhika R, ALARC
rrroy at ATT.COM
Thu Apr 6 15:50:53 EDT 2000
Hi, Steve:
You are right.
Figure 1 is by no means is finalized. We have taken this as a starting point
for discussion. That does not mean we have to take Figure 1 as it is. In
fact, I am bringing contributions in this area. I will have a different
figure 1 (modified) in my contribution. I will explain all things in the
context of intra-domain mobility management. There will be many more figures
to highlight many things that we think need to be there to make the
intra-zone mobility management complete.
I expect that all people bringing contributions will do the same. Let me
clear this again. Figure 1 of Nokia's contribution MD011 is NOT a complete
one. It is up to as a team to decide when we analyze all facts based on
contributions that are coming for the upcoming conf call.
Similar is the case for Figures 2, 3, and others. These figures are
providing some kind of guidelines or references to streamline our work so
that we can bring contributions along those lines in explaining the things.
In the same token, we will explain VLF and HLF for each case.
Finally, the contributions will explain pros and cons and we will go from
there to decide as a group what makes sense to make standard for H.323
mobility.
I appreciate your note.
Best regards,
Radhika
> -----Original Message-----
> From: Stephen Terrill [SMTP:stephen.terrill at ERICSSON.COM]
> Sent: Thursday, April 06, 2000 4:17 AM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: Mob ad hoc group progress
>
> Hi Roy,
>
> Just a note, I assume that when refering to "figure 1", I understood from
> the phone meeting that it was a modified figure 1 as we agreed to as it
> wasn´t clear in respect to whether the two subscribers where roaming
> and/or home etc. I trust that was what you were refering to in your
> thinking.
>
> Regarding the VLR and GK being co-located, I think that is still a
> discussion.
>
> Best Regards,
>
> ..//steve
>
> "Roy, Radhika R, ALARC" wrote:
>
> > Hi, Everyone:
> >
> > We are again not in sink what is going on with respect to progress of
> our
> > work. Let me try again.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > Then Figure 3: Inter-Domain all H.323 scenario.
> >
> > And so on ...
> >
> > If we do not do this, we might again go into circle.
> >
> > I guess that this should be very clear to everyone. I would assume that
> > people should bring contributions along this line: Figure 1, 2, ....etc.
> >
> > Let us not by-pass any step for sake of clarity and completeness.
> >
> > 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.
> >
> > I like to see all members provide their comments on this.
> >
> > Best regards,
> > Radhika R. Roy
> > AT&T
> >
> > > -----Original Message-----
> > > From: Jaakko Sundquist [SMTP:jaakko.sundquist at NOKIA.COM]
> > > Sent: Wednesday, April 05, 2000 6:06 AM
> > > To: ITU-SG16 at MAILBAG.INTEL.COM
> > > Subject: Re: Mob ad hoc group progress
> > >
> > > Hi all,
> > >
> > > Once again there seems to be quite a lot of confusion about the terms
> we
> > > are
> > > using. First of all, we did not make it altogether clear in the last
> > > teleconference, what is meant by a scenario. My contribution on the
> issue
> > > tried to group both the "call scenarios" and the "location management
> > > scenarios" into one set of scenarios. We did notice during the
> > > teleconference that this was not an adequate approach and now some of
> the
> > > problems occuring in this email discussion reflect that.
> > > For example, when Radhika is talking about starting with the
> intra-zone
> > > scenario, I'm not quite sure what he is meaning. I understand that the
> > > "call
> > > scenario" he is talking about, is the one in which both terminals are
> > > registered to the same gatekeeper. However, this "call scenario" in
> itself
> > > does not really bring anything new to H.323 unless there is something
> that
> > > we need to address with the "location management scenarios". Now,
> while
> > > the
> > > "call scenario" does indeed fall into the category of intra-zone
> > > communications, the "location management scenario" for finding the
> address
> > > of the B-subscriber of the call might not, i.e. the VLF and HLF that
> need
> > > to
> > > be contacted may not be located in the same zone or even domain.
> > > Furthermore, we haven't even decided that the VLF and HLF should be a
> part
> > > of any zone. I know that most of us actually think that the VLF is
> always
> > > located with the gatekeeper, but so far we haven't made that decision
> and
> > > certainly we haven't coupled the HLF functionality always with the
> > > gatekeeper. Thus it is quite unclear what is meant by intra-zone
> "location
> > > management scenarios" and I would suggest that we do not even try to
> > > define
> > > this term. Instead intra vs inter domain "location management
> scenarios"
> > > make much more sence.
> > > (Note that I'm using the terms "call scenario" and "location
> management
> > > scenario" quite freely here. If we want to use such terms, they
> definitely
> > > must be clearly defined.)
> > >
> > > Also, I would like to point out that talking about intra-zone,
> inter-zone,
> > > etc. scenarios, is actually not what was originally meant by a
> scenario.
> > > The
> > > idea to introduce scenarios into the H.323 Mobility work came from
> Tiphon,
> > > where 5 different scenarios are identified. These scenarios do not
> take
> > > into
> > > account, whether the call (or other connection) takes place inside one
> > > zone
> > > (intra-zone), between two zones (inter-zone) or between domains
> > > (inter-domain). The scenarios in Tiphon simply state which network
> types
> > > are
> > > involved in the connection, e.g. Tiphon scenario 1 is the VoIP-to-SCN
> > > scenario, Tiphon scenario 2 is the SCN-to-VoIP scenario, etc. These
> were
> > > the
> > > kind of scenarios I thought we were trying to identify in the last
> > > teleconference. Of cource, each of this kind of scenarios may involve
> > > calls
> > > that are intra-zone, inter-zone or inter-domain calls, but we
> shouldn't
> > > call
> > > (no pun intended) these different call models as scenarios.
> > > We have now chosen the all-H.323 scenario as the first one to examine
> > > (although we didn't even know what it means). In my mind this means
> that:
> > > * We only examine call cases, in which no gateways are included.
> > > * We examine gatekeeper discovery, registration and location
> > > updating
> > > cases, in which the user is accessing the H.323 system either in
> his/her
> > > home network (e.g. domain) or a visited network (e.g. domain).
> > > * We examine call establishment and call release cases, in which
> the
> > > A-subscriber is either in his/her home network (domain) or in a
> visited
> > > network (domain).
> > > * We examine call establishment and call release cases, in which
> the
> > > B-subscriber is either in his/her home network (domain) or in a
> visited
> > > network (domain). Note that the call can be intra-zone, inter-zone or
> > > inter-domain irrespective of whether the B-subscriber is in home or
> > > visited
> > > network.
> > > * We examine mid-call scenarios (e.g. some supplementary
> services),
> > > in
> > > which the user (either A- or B-subscriber) is either in his/her home
> > > network
> > > or in a visited network.
> > > * In the context of H.323 Annex H we do not address the
> inteworking
> > > functionalities (IWFs) between the HLF/VLF/AuF and some non-H.323
> network,
> > > unless some other document (such as H.246 Annex E) proposes additions
> to
> > > H.323 Annex H. (Note that, when we start work on some other scenarios
> in
> > > the
> > > future, we probably will have to take the IWFs into account.)
> > >
> > > Other issues that need to be addressed are at least the definitions
> for
> > > the
> > > home/visited network/domain/zone/gatekeeper, because it seems to me
> that
> > > some members are already using some of these terms in ways that
> already
> > > point to certain solutions, on which we have not yet agreed.
> > >
> > > I will try to work out a suitable contribution for the next
> teleconference
> > > to clarify these issues properly. If you have some comments to this
> mail,
> > > please respond. I know that this is a long posting with quite a lot of
> > > issues in it and I'm sure that I haven't explained myself too clearly
> in
> > > all
> > > parts of it, so please ask.
> > >
> > > ------------------------------------------------
> > > Jaakko Sundquist *
> > > +358 50 3598281 * Audere est Facere!
> > > jaakko.sundquist at nokia.com *
> > > ------------------------------------------------
> > >
> > > -----Original Message-----
> > > From: EXT Roy, Radhika R, ALARC [mailto:rrroy at ATT.COM]
> > > Sent: 04. April 2000 15:31
> > > To: ITU-SG16 at mailbag.cps.intel.com
> > > Subject: Re: Mob ad hoc group progress
> > >
> > > Paul:
> > >
> > > Thanks for clarifications.
> > >
> > > In the last conf call, we even cannot complete the simple intra-zone
> > > (intra-network, inter-network) scenarios first. You are right that we
> > > should
> > > concentrate on the scenarios (Registration procedures, Gatekeeper
> > > discovery,
> > > Location update, Call establishment, Mid-Call scenarios (e.g.
> > > supplementary
> > > services, user interaction, Call release).
> > >
> > > Definitely, we can go further: Inter-Zone (intra-domain) scenarios as
> well
> > > if we can agree on the first one. AT&T contributions already contain
> many
> > > of
> > > those aspects. Hope to bring new contributions explaining further in
> both
> > > scenarios.
> > >
> > > Best regards,
> > >
> > > Radhika R. Roy
> > > AT&T
> > >
> > > > -----Original Message-----
> > > > From: Guram Paul-LPG019 [SMTP:lpg019 at EMAIL.MOT.COM]
> > > > Sent: Sunday, April 02, 2000 3:52 PM
> > > > To: ITU-SG16 at MAILBAG.INTEL.COM
> > > > Subject: Re: Mob ad hoc group progress
> > > >
> > > > Radhika,
> > > >
> > > > Conf call is for Annex H only as before...nothing has
> changed...change
> > > can
> > > > only take place when the group agrees. Please do not read into the
> > > email
> > > > more than what it says. I was only trying to highlight, in a high
> level
> > > > report, the plight of Annex I since nothing much has moved in it,
> and it
> > > > is
> > > > an Annex which together with Annex H covers the mobility aspects.
> As
> > > far
> > > > as
> > > > Annex E is concerned, the point was that the mapping was the work
> of
> > > one
> > > > individual or one company, thus could have errors or omissions (more
> > > than
> > > > likely)...again only highlighting to people to check out this
> mapping.
> > > >
> > > > Contributions for next conf call to be for All H.323 intra-network
> > > > scenario
> > > > for:
> > > > Registration procedures, Gatekeeper discovery,
> Location
> > > > update, Call establishment, Mid-Call scenarios (e.g.
> > > > supplementary services,
> > > > user interaction), Call release. Also contributions
> on
> > > > any
> > > > impacts on the already specified architecture in the light of the
> > > present
> > > > work are welcome.
> > > >
> > > > Paul
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Roy, Radhika R, ALARC [mailto:rrroy at ATT.COM]
> > > > Sent: 01 April 2000 00:00
> > > > To: ITU-SG16 at mailbag.cps.intel.com
> > > > Subject: Re: Mob ad hoc group progress
> > > >
> > > > Hi, Paul and Mobility Group:
> > > >
> > > > I like to see that it should be clarified via emails
> > > > whether
> > > > H.323 Annex I
> > > > and H.246 Annex E will be a part of the conference
> call.
> > > > My
> > > > personal
> > > > preference is not to discuss annexes I and E during
> the
> > > > conference call
> > > > although email discussions will be preferred.
> > > >
> > > > If Annex I and E are included in the conference
> call, I
> > > > like
> > > > to see the
> > > > actual time in the agenda when these items will be
> > > > discussed
> > > > so that people
> > > > can best use their time in joining the particular
> time
> > > > slot
> > > > for each Annex.
> > > >
> > > > The proposal is as follows:
> > > >
> > > > 1. The upcoming conference call to be dedicated for
> > > H.323
> > > > Annex H.
> > > > 2. Let both editors of H.323 Annex I and H.246 Annex
> E
> > > > propose via emails
> > > > whether any issues to addressed.
> > > > 3. If annex I and E are included in the agenda of
> the
> > > > upcoming conference
> > > > call, I like to the time slots when these annexes
> will
> > > be
> > > > discussed so that
> > > > people can join the particular time slots of
> interest.
> > > > Alternatively,
> > > > separate conference calls can be arranged for
> annexes I
> > > > and
> > > > E.
> > > > 4. Are editors or any members of the mobility group
> sure
> > > > what would be the
> > > > scope of work (I guess that Annex E is stable for
> now -
> > > > thanks to the
> > > > editor) for those annexes?
> > > >
> > > > Paul: Would you please clarify what specific area
> that
> > > we
> > > > need to discuss
> > > > for the next conference call for H.323 Annex H? My
> guess
> > > > is
> > > > that we may
> > > > start with intra-zone communication first. I am
> planning
> > > > to
> > > > bring
> > > > contribution(s) describing this for mobility
> management:
> > > > Discovery,
> > > > Registration, Location Updates, and Call
> Establishment.
> > > >
> > > > I would appreciate comments form all members.
> > > >
> > > > Best regards,
> > > >
> > > > Radhika R. Roy
> > > > AT&T
> > > > H.323 Ad Hoc Mobility Group
> > > >
More information about the sg16-avd
mailing list