Subject: Re: [MOBILE-IP] handover

From: James Kempf <[email-masked]>
Date: Wed, 26 Apr 2000 09:31:30 -0700

>I am against trying to come up with an approach that will be generic for ALL
>wireless link layers. I believe that we should make some assumptions, and try
>to solve the problem given that set of assumptions. If we run across another
>link layer that has a completely different set of capabilities, then we address
>it as need be.
>BTW, I see this as being NO different than IP over different link/physical
>layers. There isn't a generic solution, and we shouldn't make that assumption
>here either.

I strongly support Pat's ideas. I think it should be possible to come
up with an extensible protocol that allows some parameterization of
information available from the link layer, then do a few cases for
specific link layers to illustrate how it can be done. It's important
that the protocol be well defined, especially if we are to enable
switching between different wireless media. A purely generic solution won't have
the kind of performance that will be necessary for switching realtime streams.
If a particular link layer can't supply what's needed for fast handover,
then slower, more generic methods will need to be used, or the link
layer standard needs to be modified to provide what's needed.

However, there is a distinction between link layers that do cell switching
at L2 (like 802.11) and tell L3 about it afterwards, and those that
provide room for decision making in the L3 software about whether to
switch (like maybe CDMA with an IP replacement for hard handoff) which
is of concern. In the latter case, there is room for setting up
network resources like QoS before the mobile node hands off, in the former,
there isn't. This is something that will need to be addressed.

>That is were the open API works.
>
>You can define the API, e.g., with various attribites: SNR and
>quality indicators, etc. If some wireless links
>support these attributes then fine if others don't also
>fine.

The problem with standardized APIs is that vendors have too much
incentive to ignore them. Unlike protocols, a vendor can add "features"
or modify an API and not break interoperability, which is what
customers really care about. The only people who suffer are the programmers
writing software, who have to port to the different, incompatible APIs. Many
vendors use APIs to lock developers into their platform, and therefore
completely ignore attempts to standardize APIs.

This is not to say that a standardized API isn't desirable. It does
serve as an existence proof and helps to define how programmers access
a protocol. As such, it can expose areas in the protocol design that
are problematic, such as defining elements of the protocol that
must be handled in the operating system kernel even though the functionality
the protocol is trying to implement is of interest primarily to
application developers. And there is always the possibility that
vendors will buy into a standardized API, or at least part of it,
and make software developers' jobs easier.

                jak

---

From: Gerald Maguire <[email-masked]>
Date: Wed, 26 Apr 2000 18:48:51 +0200

Why not used the APIs defined by the SDR Forum? Since this includes
enough to completely define _and_ control a Software Defined Radio, it
should be sufficient to handle any of the existing radios.

Chip

---

From: "Andrew T. Campbell" <[email-masked]>
Date: Wed, 26 Apr 2000 15:12:24 -0700

Chip:

I think many of these issues of service diversity will
be solved by taking the concept of "software radio"
up through the MAC to the control plane and beyond
to make mobile and  wireless networks fully programmable.

Then you just program the system to meet your needs.

Andrew