those network logical entities (AAA services
administrator, paging controller, gateway routers, caching services, SFID
administrator, MACGs, mobility management controllers, etc...) that may exist
on the network. Note that I propose distinguishing identification
of logical entities by function rather than by device. One or more
logical functions may be performed by the same device;
network logical entities' relationships to BS
and to each other
events on BS and on the network that may trigger
communications;
information elements transferred across the
network during triggered communications (avoid protocol and message formatting
specification);
primitives on BS tied to trigger events and
appropriate primitive/SAP associations;
an appropriate, minimally defining Network
Reference Model(s) highlighting these relationships;
an appropriate BS/MSS Reference Model containing
these relationships.
Subject: Re: [STDS-802-16] [NETMAN_SG] Network
Management Study Group
> Here's a list of things that 16e has been discussing that could go
into > a new PAR: > > 1. Management and Provisioning
issues > > a) BS interface to AAA server (ie.
details of RADIUS/DIAMETER >
exchange etc.) > > b) MIBs, including dynamic
management of Service Flows > > c) BS Discovery
of "Neighbor BSes" > > d) Roaming between
administrative domains > > 2. The following can be termed "Extended
Services" (following the > example of 802.11 ESS) or
"Backbone mobility services" > > a) Protocol to
enable BSes to query neighbors or centralized servers >
during evaluation of Handover requests from
MSSes (Revision > to Annex
C). > > b) Structures and semantics of data that
are passed between BSes > during
Handover. These are currently addressed in Annex C and >
elsewhere in .16e, but more work is needed,
particularly > on derivation of
security context and readmission/reactivation of >
service flows. > >
c) Transport protocol for low-latency transfer (predictive
and > reactive) of the L2 context
data at handover, and related >
MAC-layer triggers > > d) Compatibility w/
various types of L3 mobility (and triggers) > > - Jeff >
> ------------------ > > Jeff Mandin > Streetwaves
Networking > > > > To: STDS-802-16@listserv.ieee.org Subject:
[STDS-802-16] [NETMAN_SG] > > Network Management Study Group
From: "Johnston, Dj" > > <dj.johnston@INTEL.COM> Date: Fri,
26 Mar 2004 18:53:19 -0800 > > Reply-To: "Johnston, Dj"
<dj.johnston@INTEL.COM>
Sender: > > owner-stds-802-16@listserv.ieee.org
Thread-Index: > > AcQTprE0A4ncKA23Qyu9ObpkW8LGcw== Thread-Topic:
[NETMAN_SG] Network > > Management Study Group Title: Message
All, > > > > We need to get moving on inputs to the
network management study > > group. The goal I put forth to the
WG is that we do our work before > > and during the May meeting,
so this will require us to work some of > > the issues on the
reflector and maybe have a conference call or two, > > if we are
to produce a PAR and five criteria during the interim. If > > we
don't have a workable basis for consensus going into the May > >
meeting, then I expect we will be asking for an extention in July, >
> and that is a long time, given that it would then be November
before > > the TG request would be approved by the EC and NesCom
would add more > > time to the process, so maybe we would be
looking at 2005 before we > > had a group for real. Finishing in
May is a good plan. > > > > I propose that email
directed to this effort has [NETMAN_SG] in the > > subject line
to allow appropriate filtering. > > > > The primary
thing that led me to suggesting a study group was the > >
plethora of different things people wanted to do with respect to >
> network management, network architectures, interfaces, MIBs and so
on > > and the rapid closure of .16d as a forum in which to
address them. My > > personal wish list is no secret, you will
find it in the comment > > databases - security, interfaces,
MIBs. > > > > So as a first step, I would like to
request that people forth their > > ideas for what problems they
think network management group or groups > > (don't let the name
predjudice the function) should be solving, or > > what features
they should be introducing. This will give us a list of > >
issues that we can enumerate, sort, sift, rejig, classify and > >
generally argue about until we can approach consensus on scope and >
> purpose. But first we need the issues out on the table for all
to > > see. > > > > A potential benefit I
suggested was that items of questionable scope > > in .16e might
find a more secure home in a new group. This is not my > > idea
and I have not been in the loop on these discussions (although I >
> do like the idea), so perhaps it would be useful input for people
who > > are thinking along these lines to start describing
specifics of what > > bits in .16e are problematic and might
benefit from a group with a > > clear scope to address
them. > > > > I'll make my suggestions in a separate
email.. > > > > DJ (chair 802.16 network management
study group) > > >