RE: [802.21] triggers vs. O/S
I kind of agree - it is an abstraction.
At the risk of modeling it online -
I would normally address it by an intermediate artifact that is a
broker. Higher layers may register event interest with a broker. Higher
layers are interested in events - more likely associated with
clients.The broker may choose to understand the different (L2) device
gateways/APs (that may have in turn registered their presence with it
after discovering the broker). The broker in turn interprets higher
layer event-interest and looks-for/alerted-by the devices for events it
may register interest with them.
The events of interest may happen in a (topologically) broad
(handoff/roaming) domain. The broker serves to collate (collect) and
deliver the right one(s) to the higher layer(s).
I guess part of this WG's role is in categorizing such higher layer
events and abstracting the APIs to fit requirements arising thereof in
either direction
(app<->broker & broker<->device).
There may be better models; I would be interested to hear them.
-mani
> -----Original Message-----
> From: Johnston, Dj [mailto:dj.johnston@intel.com]
> Sent: Thursday, May 06, 2004 1:03 PM
> To: Mani, Mahalingam (Mahalingam); STDS-802-21@listserv.ieee.org
> Subject: RE: [802.21] triggers vs. O/S
>
> Just to clarify..
>
> The reason for the registration scheme for triggers is simply that it
> might be possible for a lot of triggers to be defined that might
> ultimately be non useful. Your upper layer might not want all these
> triggers flying around, it might not understand some of them and over
> the link, they will consume bandwidth.
>
> So a registration scheme will limit the generation of event and over
the
> air event traffic to only those event that are useful in some way.
>
> DJ
>
>
> -----Original Message-----
> From: owner-stds-802-21@listserv.ieee.org
> [mailto:owner-stds-802-21@listserv.ieee.org] On Behalf Of Mani,
> Mahalingam (Mahalingam)
> Sent: Thursday, May 06, 2004 11:19 AM
> To: STDS-802-21@listserv.ieee.org
> Subject: Re: [802.21] triggers vs. O/S
>
>
> If we assume dedicated L2 devices we need to identify transport and
> protocol (a) for external apps. (read higher layers) to register
> interest in trigger events (b) percolate trigger events up as alerts
> back to the those external apps.
>
> In specific cases where the layers are co-resident on a single device
> such an interface may be inconsequential.
>
> -mani
> > -----Original Message-----
> > From: owner-stds-802-21@LISTSERV.IEEE.ORG [mailto:owner-stds-802-
> > 21@LISTSERV.IEEE.ORG] On Behalf Of Michael.G.Williams@NOKIA.COM
> > Sent: Thursday, May 06, 2004 9:46 AM
> > To: STDS-802-21@LISTSERV.IEEE.ORG
> > Subject: [802.21] triggers vs. O/S
> >
> > Vladimir,
> >
> > There has been presented a notion of triggers delivered locally up
the
> stack from
> > L1/L2 detection on the mobile or the network attachment point. There
> has also
> > been the notion of transmitted triggers which are sent from the MN
or
> (existing or
> > potential) attachment points, to each other.
> >
> > The later will arrive in the L1/L2 of the device and presumably be
> delivered in the
> > same fashion as the former.
> >
> > The delivery fashion will most likely be quite different on Symbian
or
> Linux or
> > Solaris or Java than on CE or XP or NT. That delivery might be
signal
> oriented or
> > method oriented or an ABI within the OS network stack for example.
> >
> > Do you feel that we can /cannot define anything in the standard
about
> the locally
> > determined triggers?
> >
> > Best Regards,
> > Michael Williams
> >
> > -----Original Message-----
> > From: owner-stds-802-21@LISTSERV.IEEE.ORG
> > [mailto:owner-stds-802-21@LISTSERV.IEEE.ORG]On Behalf Of ext
Vladimir
> > Yanover
> > Sent: Thursday, May 06, 2004 8:59 AM
> > To: STDS-802-21@LISTSERV.IEEE.ORG
> > Subject: Re: contributions for upcoming May 2004 meeting - L2.5 C
> > oncrete Model ?
> >
> >
> > Peretz, Mike
> >
> > I absolutely agree that the standards must not be based on product
of
> > specific vendor. Unfortunately, viability of this specific
applicaton
> > scenario does
> depend on
> > special features
> > provided [or not] by OS vendors. Probably, there are more scenarios
on
> the
> > table?
> >
> > Vladimir
> >
> [...]