RE: [802.21] triggers vs. O/S
Mani, DJ and All,
Is there in 802.21 docs sort of reference model where one could find
abstractions of network adapters, OS, network etc.?
Or the WG is yet to define the model? In any case trigger primitives need
some model to live in.
Vladimir
-----Original Message-----
From: Mani, Mahalingam (Mahalingam) [mailto:mmani@AVAYA.COM]
Sent: Friday, May 07, 2004 12:39 AM
To: Johnston, Dj; STDS-802-21@LISTSERV.IEEE.ORG
Subject: 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
> >
> [...]
This mail passed through mail.alvarion.com
****************************************************************************
********
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
****************************************************************************
********
This mail was sent via mail.alvarion.com
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************