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@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@MAILBAG.INTEL.COM]On Behalf Of Edgar Martinez [1] Sent: Tuesday, November 23, 1999 9:37 PM To: ITU-SG16@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.323H.323 Annex I: Packet-based Multimedia Telephony overError Prone
Channel
H.246 Annex E: Interworking between Existing H.323 Systems andExisting 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@att.com
-- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@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/