Mob ad hoc group progress

Thu Apr 6 04:16:39 EDT 2000

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
> > >