Geoff,
Here is one format for preapring the Use Cases.
Use Case: <Title>
Category:
Goals to be achieved by this use case:
Roles
<To make it very general use actors>:
Needs (Preconditions):
Context (Triggers) - Optional:
Usage Scenarios: <Add steps to each usage scenario>
Postconditions - Optional:
We put together all the use cases and then classify them in terms of priority and/or life-term. And hopefully that should also help
us identify the functional requirements / components
Here is a sample that I prepared
Use Case: Intermittent Data acquisition from a LowPAN device
Category(s): Healthcare
Goals to be achieved by this use case: Obtain data for monitoring at the client machine in
the local network. Summary of the data acquired maybe stored. The Profile of the LowPAN device is fixed.
Roles <To make it very general use actors>: Andy responsible for setting up and managing the client machine.
Amin LowPAN device is devoted to
Amin
Malin Unauthorized entity trying to get into the network
Dr Brad Entity that specifies the policies and profile for LowPAN device and Amin. Also recipient of summary of data acquired.
Needs (Preconditions): the device is operational and ready to be used
Context (Triggers) - Optional:
Usage Scenarios:
-
Identifying Amin and Preparing Amin
- Setting up the LowPAN device for data acquisition- preparing the policies
- Authorized Data acquisition and control
- Unauthorized data acquisition and control
- Device Tracking
- Device maintenance
Post conditions - Optional:
We should have a master pool of Categories and Roles so that all the use cases have a common basis.
Other use cases could be
- Large scale
deployment of LowPAN devices (real-time monitoring)
- LowPAN device as a Utility (such as Gas, Electricity) Usage Monitor (Command / Response driven Profile is being pushed)
- LowPAN device being used in Home Network Monitoring (Mobile home owner can access theis LowPAN device in his home)
- Touch less access control system at a Building
Abhijit
Ron Strich <[EMAIL PROTECTED]> wrote:
Geoff,
I agree that "use case" is a better term than architecture, especially
considering the historical issues that Carsten has raised. But I also
believe that the incorporation of very small devices into a 6lowpan "use
case" is important to the adoption of 6lowpan. Cost is also important
consideration for 6lowpan adoption. An extra $0.01 in cost imposed by
6lowpan, has a potential $100 million annual impact to the adoption of
wireless communications to the micro controller industry at today's
production rates.
Ron
-----Original Message-----
From: Geoff Mulligan [mailto:[EMAIL PROTECTED]
Sent: Friday, November 03, 2006 12:36 AM
To: Ron Strich
Cc: '6lowpan'
Subject: Re: [6lowpan] 6lowpan Architecture Questions
Ron,
These are excellent points.
I would like to hear from other on the list about the idea of supporting
extremely small devices (4K) (smaller than the extremely small devices
that we have been targeting (32K)). I would not like to choose to miss
a potential market segment (potentially large market segment), but is it
reasonable to got after a 4k device which probably could not possibly
ever accept a 1280 byte (minimum size ipv6) packet.
I think question 2 is going to be critical as we move to the next phase
of this working group. Hopefully we will finish the format document and
start on rechartering. One of the top areas that I think we need to
look at is the idea of utilizing Manet and how the design will impact
6lowpan (memory, power, other costs). And whether or not we choose to
use the manet approach and protocols, should we down select to a single
protocol or some small set and if so what is the criteria for this
selection.
Please consider what criteria you think we should use to evaluate the
available mesh protocols.
While the IETF doesn't appear to embrace architecture docs, it is
critical for us to agree on some set of use-cases so that we can focus
our efforts on providing real solutions.
So again, please consider for our rechartering and new work items,
should we generate a set of use-cases? What is the format for this?
Should we support extremely small devices? And finally what criteria
should we use to determine the selection/evaluation of mesh routing
protocols (which probably begs for a use-case analysis.)
Folks, please start to participate in these discussions. It is only
with your input that we will have a successful working group and will
create a standard that is useful in the market.
geoff
On Fri, 2006-10-27 at 09:07 -0500, Ron Strich wrote:
> 1. Many sensor and control devices will be too small to support a full
> mesh/ip adaptation implementation. Some of these devices may be as small
as
> 4K of flash and 100s of bytes of RAM and may only be used in a point to
> point (P2P), simple star, or very simple mesh implementation (please see
the
> attached pdf drawing). Incorporation of these very small devices, I
> believe, is important to the broad adoption of 6lowpan.
>
> Should we consider how to support these extremely limited devices? Should
> we make it easy for these simple protocol implementations at this level to
> adapt to 6lowpan? If we want to include these small devices, should we
> consider a more constrained design (limited payload, P2P/star only) that
> would simplify the adaptation layer?
>
> 2. How will the group evaluate what mesh, P2P or star protocols should be
> supported? As David pointed out, we may not be allowing for future
> capabilities in the current structure of the adaptation layer should we
want
> to support multiple types of L2 protocols.
>
> 3. Related to the pending mesh protocol evaluation, is the evaluation of
any
> functionality related to the "cost" of those technical choices in terms of
> power, code size, complexity, RAM, instructions executed, etc?
>
> 4. As was mentioned on the list a while ago, neither the Problem Statement
> nor the Format documents discuss the overall 6LoWPAN architecture. As we
> move forward with our next working group items, shouldn't we create a
> document to describe the high level architecture which might well
encompass
> the criteria for evaluation of the protocols and costs mentioned above?
>
> Ron Strich
> Mobile: 228.369.4332
> _______________________________________________
> 6lowpan mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
Get your email and see which of your friends are online - Right on the new Yahoo.com
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
