H.323 Annex I

Roy, Radhika R, ALARC rrroy at ATT.COM
Wed Nov 24 16:00:37 EST 1999


Hi, Barry and All:

I understand Barry's points. The scope of mobility work can be from H.323
application layer to the link layer.

The fundamental question is: What should be the scope of Annex I in the
context of H.323 (H.225.0, H.245)?

My guess is that we are not addressing all problems related to mobility
unless we can use in the context of H.323.

The scope of mobility in the IP layer is very big. It includes mobile IP,
cellular IP, and others. IETF is doing fine in addressing those problems.
Even IMT-2000, 3GPP, 3GIP, TIPHON, IMTC, and other forums are also
addressing the mobility problems. An enormous amount of work has been
started worldwide to address mobility problems.

Let those standard bodies/fora address their mobility problems as they want.

Our objective is to limit our scope within H.323 mobility. What Ed wanted, I
guess, to clarify that unless any work is related to H.323 mobility, we
should not address those items. Therefore, H.323 Annex H should be focused
FIRST.

Now we have to make sure that the work of Annex I is being related to H.323
(please also see my email). So far, Annex I has NOT clarified this. I tend
to agree with you that the work of H.323 Annex I can go forward in parallel
with H.323 Annex H.

In H.323 Annex H work, we also find that there is an item called "Network
point of Attachment." The network point of attachment may include IP (or
ATM) addresses. If people want to implement H.323 mobility over the IP
network, I believe that H.323 Annex I can link its work to mobile IP and
cellular IP. Annex H may also identify some issues for implementing to the
IP network using the mobile IP and cellular IP. (Forums like IMTC, TIPHON,
3GPP, and 3GIP may also take the H.323 mobility work for implementation to
the IP network. ATM Forum may also use this work for implementing to the ATM
network.)

So, I am proposing that you and other interested companies continue to
develop H.323 Annex I bringing contributions. If needed, we can also arrange
separate Ad Hoc meetings solely dedicated to Annex I.

Best regards,
Radhika

        -----Original Message-----
        From:   Barry Aronson [SMTP:baronson at ieee.org]
        Sent:   Wednesday, November 24, 1999 9:49 AM
        To:     ITU-SG16 at MAILBAG.INTEL.COM
        Subject:        Re: H.323 Annex I

        Ed,

        (First, I assume you mean H.323 Annex I when you write H.246 Annex
I.)

        Regarding H.323, I don't see at all how Annex I is dependent on
Annex H. In
        fact, they are (and should be) orthogonal.

        Put simply, Annex I deals with everything from H.225, inclusive, on
down in
        the context of error prone channels and mobile environments (e.g.,
cellular
        networks). This includes IP. There may be some recommendations
regarding
        error resiliency in the codecs, but this should be approached
cautiously.
        Ideally, an H.323 application will use exactly the same interface
and
        messages currently used with regard to H.225 as it will when
enhanced with
        Annex I. The changes will be quite localized, which will help with
adoption
        and interoperability with existing systems. Annex I will be
extremely useful
        without Annex H because H.323 defines a very simple call model that
utilizes
        the Network Address and Call Signaling Channel TSAP Identifier of
the called
        terminal -- no gatekeeper is needed. With Mobile IP name services
don't have
        to be updated. In fact, Gatekeepers could be used with Annex I by
using
        Mobile IP and automatic Gatekeeper discovery (presumably, a cellular
        terminal has been thoroughly authenticated long before having an IP
        connection). Even if this model is never used, separating Annex I in
this
        way is greatly beneficial from a standards development point of
view. Work
        can proceed without being affected by other development.

        Annex H deals with a terminal, user, or service that has moved
either
        discretely or continuously. Clearly, user and service mobility can
occur in
        a non-wireless setting. Therefore, there should be no dependency on
Annex I
        for these functions. Conversely, there is no reason to address user
and
        service mobility in Annex I. Terminal mobility may occur without the
        functionality provided in Annex I. For example, there could exist a
large,
        homogeneous IP network running on Ethernet in which it was possible
to move
        one's laptop from one link layer point of attachment to another and
cause a
        change in IP address (due to being in a different subnet) and H.323
        Gatekeeper zone, but still be a functioning host (through DHCP,
etc.). Now,
        in this situation, Annex I could come into play since Mobile IP
falls under
        Annex I and Mobile IP could deal with the changed IP address.
However, this
        may not be the best solution. Since the new IP address will remain
in effect
        until another discrete location change (ignore dynamic IP addresses
as this
        problem exists for stationary terminals), it seems more efficient to
update
        the name servers or Gatekeepers than to use Mobile IP. The question
is, what
        procedures can be defined in Annex H that would assist this? Also,
these
        techniques do not necessarily have to be efficient in the cellular
world
        (Annex I will take care of that situation) since having an efficient
way to
        deal with semi-permanent (hey, an oxymoron!) subnet changes would be
a huge
        win.

        Although I started by stating that Annex I and H were orthogonal, it
seems
        there is an overlap in the area of terminal mobility. This gets back
to the
        original division proposed by Dale in Santiago: Annex I was to be
Terminal
        Mobility and Annex H User and Service Mobility. If we went back to
that, it
        might simplify things. On the other hand, there is a rational for
dividing
        along the lines of  radio-link/cellular/mobile vs. generic mobility,
even if
        terminal mobility was covered in both. Resolving conflicts would be
easy.
        Just insert statements like "when connected via radio link and/or
the
        network point of attachment could change during a call, the
procedures
        defined in Annex I shall be followed". But then again, it would be
nice if
        there was a clear procedure in one recommendation that dealt with
terminal
        mobility. Thoughts anyone?

        Barry Aronson
        Toshiba Corp.
        33 Lake Shore Dr.
        Beverly, MA 01915-1907
        USA

        Voice:  +1 978 232 3994
        Fax:    +1 978 232 9220
        Mobile: +1 978 902 0768 (mostly worldwide)
        E-mail: baronson at ieee.org
        H.320 and H.324 video conference available on request

        > -----Original Message-----
        > From: Mailing list for parties associated with ITU-T Study Group
16
        > [mailto:ITU-SG16 at MAILBAG.INTEL.COM]On Behalf Of Edgar Martinez [1]
        > 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/
        >



More information about the sg16-avd mailing list