H.323 Annex I

[Gösta Linder (LME)]

I agree with Ed´s conclution/Gösta

-----Original Message-----
From: Roy, Radhika R, ALARC [mailto:rrroy at ATT.COM]
Sent: Wednesday, November 24, 1999 2:49 PM
To: ITU-SG16 at mailbag.cps.intel.com
Subject: Re: H.323 Annex I


Hi, Ed and All:

Ed has provided a very valuable comment. In fact, it has been one of the
main purposes of my email. The important part of his comment is that all
works have to be related to H.323 mobility solution. Any work that does not
related to H.323 mobility should not be undertaken.

In this respect, Annex H is becoming the fundamental basis of all works
because it provides the solution for the H.323 mobility.

In fact, the dust will be clear as soon as we finish Annex H. Once the
fundamental H.323 mobility work is finalized, other annexes can use this
work for implementation to the lower layers (i.e., layers 3 and 2) and in
specific interworking environments.

I personally agree with Ed.

I like to see the comments of other members.

Best regards,
Radhika

> -----Original Message-----
> From: Edgar Martinez [1] [SMTP:martinze at CIG.MOT.COM]
> Sent: Tuesday, November 23, 1999 9:37 PM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      Re: H.323 Annex I
> Importance:   High
>
> Dear All,
>
> I concur, with most of the attached email.
>
> And I have just a couple of comments. Until we resolve the pure case
> of H.323 mobility and  Interworking with PLMN in the application
> layer. H.246 Annex I and Annex E will be delayed, I believe that
> Annex I and Annex E are depended on H.323 Annex-H. Because,
> the required parameters and network functions for the H.323 pure
> mobility and Interworking case needs to be defined in H.323
> Annex-H. And expanded in H.246 Annex-I and Annex-E.
>
> If we do not get the H.323 mobility and interworking
> parameters and functions defined, H.246 annex-i and annex-e
> will be working in the dark.
>
> Because of the H.323 framework that we have to use
> (already defined e.g., GK, GW, Terminals etc.)
> and the already defined mobile networks (e.g., GSM, ANSI-41, GPRS)
> we need to  work top-down (not) buttom-up.
> Lets focus on H.323 Annex-H to make sure that it has the
> network elements that can be re-used in H.246 Annex-I
> and Annex-E.
>
> Ed
>
> "Roy, Radhika R, ALARC" wrote:
>
> > Hi, Everyone:
> >
> > We have now three annexes related to mobility:
> > *       H.323 Annex H: User, Service, and Terminal Mobility in H.323
> > *       H.323 Annex I: Packet-based Multimedia Telephony over Error
> Prone
> > Channel
> > *       H.246 Annex E: Interworking between Existing H.323 Systems and
> > Existing Mobile Networks
> >
> > Per my earlier email, I promised that I would be providing some notes
> > related to Annex I: Packet-based Multimedia Telephony over Error Prone
> > Channel.
> >
> > Every Annex in H.323 has some direct relationship to the H.323
> application
> > layer. Even the informational Appendix II - "Transport Level Resource
> > Reservation Procedures" - shows how the RSVP messages are being used in
> the
> > context of H.323 signaling messages.
> >
> > The way Annex I has been structured shows that it will provide
> information
> > related to bit rate, bit error rate, delay, jitter, and IP issues
> related to
> > radio networks (e.g., mobile IP [home/care-of IP, home/foreign IP
> network]).
> >
> > I understand that additional error correction and concealment techniques
> > that may help specifically H.323 are the main purpose of this annex. My
> > guess is that these proposed concealment techniques will be used
> somewhere
> > below the H.323 layer. If it is so, is not the case that H.323 does not
> need
> > to be aware of these lower layer techniques?
> >
> > Now the question is: Can this work of Annex I be directly related to the
> > H.323 application layer signaling messages?
> >
> > If the answer is yes, the next question is: Is this present structure of
> > Annex I good enough to satisfy our objectives?
> >
> > If the answer is no, will it be very helpful in H.323 even as
> informational
> > annex?
> >
> > However, I see that there is an additional scope related to this work of
> > Annex I to the H.323 layer signaling messages. IP related issues can be
> the
> > major topic that will really be very useful to relate the network layer
> > signaling schemes in mobile environment (e.g., mobile IP) to those of
> the
> > H.323 mobility.
> >
> > In this context, I see that there are some works that have been
> performed
> > related to the IP networking in mobile environment. It appears that
> mobile
> > IP has some problems: 1. If the mobile host moves very frequently and 2.
> > Inefficiency for keeping too many reserved IP addresses in the pool by
> the
> > foreign agent for allocation to mobile hosts.
> >
> > To work around those problems, there has been enhancement of mobile IP
> > (e.g., cellular IP) complementing the mobile IP solution.
> >
> > The important point is that they have been using the concept of cells,
> cell
> > IDs, and network IDs packet-switched based IP mobile networking
> environment.
> > A cell can be pico-, micro-, and macro-cell depending on the radio range
> > which is a function of power. Cells are usually inter-connected by the
> LAN
> > in the case of IP networking.
> >
> > (By the way, none has used the concept of so-called location area [LA]
> > concept in the IP networking either in the mobile IP or in the cellular
> IP.
> > I am curious to know why these prototype products and network
> architectures
> > do not contain the concept of LA? Can anyone provide more insights about
> > this? Personally, I would love to relate the LAs with cells. Indirectly,
> it
> > may also help to inter-work with that of the circuit-switched based
> > cellular-PSTN network.)
> >
> > The important point is that we can start with the existing standard of
> > IETF's mobile IP/cellular IP. We can see that switching a cell during
> > communications does not always mean changes in IP addresses. That is,
> this
> > handover (at layer 2) may be transparent to the IP network layer (layer
> 3).
> > No resources in the IP layer will be affected. If the switching in cells
> > causes the change in the IP address during communications, the handoff
> will
> > cause the resource allocation and de-allocation in the IP layer during
> and
> > after handoffs.
> >
> > Extending the same analogy, we can assume that switching of the cell may
> or
> > may not cause any change in the H.323 application layer. If it affects
> the
> > H.323 layer, the resources in the H.323 layer have to be allocated and
> > de-allocated in the H.323 layer during and after the handoff.
> >
> > The other important concept is that the cell IDs can also be related to
> > H.323 zone IDs and so on.
> >
> > It appears that the mobility solution can be related to the link layer
> > (layer 2) to the network layer (IP layer) mobility and the H.323
> application
> > layer and vice versa. As a test case, people may also try to see how the
> > application layer H.323 mobility solution (e.g., APC-1651, APC-1646) can
> be
> > implemented to the network/link layer mobile/cellular IP solution
> >
> > In this way, I see a wonderful ray of light how the work of Annex I can
> be
> > related to that of Annex H.
> >
> > Last of all, I would request the editor to expand the scope Annex I. If
> > needed, I may also propose to include this item in the upcoming/future
> > conference call.
> >
> > In the same token, I may also provide some comments related to H.246
> Annex E
> > in the future.
> >
> > I would request all SG16 members to look into this proposal and help us
> with
> > their comments.
> >
> > Best regards,
> > Radhika R. Roy
> > H.323 Ad Hoc Mobility Group
> > AT&T
> > +1 732 420 1580
> > rrroy at att.com
>
> --
> Edgar Martinez - Principal Staff Engineer
> Email mailto:martinze at cig.mot.com
> FAX 1-847-632-3145 - - Voice 1-847-632-5278
> 1501 West Shure Drive, Arlington Hgts. IL 60004
> Public: TIPHON & Other Stds - http://people.itu.int/~emartine/
> Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/