1

Reference Architectures and Management Model for Ad hoc Sensor Networks

John A. Serri

Ubiquity Technologies Inc.

Fremont California, USA

John.Serri@ubiquitytechnologies.com

Abstract

Mobile self-organizing sensor networks pose

complex technical and operational challenges, yet

the benefits they offer justify efforts to develop

commercial standards for their eventual

widespread use. We propose a layered sensor

network architecture to be used to test and

develop protocols that in turn are used to develop

standards applicable to a wide range of networks.

We address and describe two essential aspects

needed for standardization, a model for element

and network management and an application-

level layer used for distributed activity

coordination between sensor elements. We refer

to this model as the Basic Sensor Network

Framework or BSNF.

Introduction

An Ad hoc sensor network is a collection of sensors,

and their users, with the ability to self organize to

collectively carryout functions of detection, data

processing, sensor control, and delivery of

information. These networks, especially wireless

ones, pose many challenges. Sensor traffic is often

bursty and asymmetric. Sensors often have to meet

low power / memory requirements[1][2], work for

years in an un-maintained state, provide location

awareness, and deliver data on demand. [3] There

can be conflicting tasking of sensors, involved

scheduling and sequencing of sensors, and a need to

multicast sensor data to a number of users in the

network. Given these requirements it becomes

evident that these systems require a layered

application architecture if there is any hope to

support a wide range of applications under one set of

standards. Furthermore the large number of elements

and interactions between these systems calls for a

strong network management model.

Considerable effort has been applied to the Ad hoc

routing and transport layer [4],[5],[6],[7] but less

effort has been given to the organization of the

sensor, users, and other control elements at the

application level. This paper addresses the latter

subjects and we refer to the architecture and

management model as the Basic Sensor Network

Framework (BSNF)

Standards Status

Assuming the widespread adoption of Ad hoc

Sensor networks for commercial use hinges on a

usable framework for application level standards [8],

the question is how achievable is that goal, and what

aspects can be standardized and what aspects should

never be standardized ? These are points we explore

in this paper. Efforts are underway to standardize

certain operational niches and they are achieving

some success such as the 802.14 Zigbee[9] standard,

and Sensor Modeling Language [10]. However the

approach taken here is more general aimed at

establishing a Basic Sensor Network Framework

(BSNF) applicable to a wide range of sensor

network applications.

Part of the challenge in developing a framework is to

determine what areas can be standardized and those

best left for proprietary implementation. A standard

that specifies too much is unwieldy to implement

and plagued with exceptions, yet one that does not

contain enough structure is hardly useful.[8] A

greater challenge is developing the application

protocols on which to build standards that would

operate under a wide range of circumstances.

2

P2P and Ad hoc Sensor Network Architectures

Self-organizing sensor networks use autonomous

peer-to-peer (P2P) concepts [11],[12] and these are

applied in formulating the BSNF. To start, a sensor

network’s purpose is to offer services to users, the

entities that task, collect and process data from

sensors. Users may also share data and cooperate

with each other, creating P2P services for query,

distribution, and computing. Figure 1 shows the

basic relationship between sensors and users. All

sensor services can be built by extending this model.

Figure 1: Basic Service Relationships between

Sensors and Users

To date most work in sensor network addresses

specific examples from local extent, low-power

consumption applications to multi-sensor high

bandwidth applications with a global reach.

[2][12][13] Underneath these different applications

reside essentially the same sets of basic processes,

including routing through an ad hoc and sometimes

mobile network, managing a large number of

elements, and maintaining a dynamic association of

the elements within the network.

BSNF - Architectural Framework Assumptions

The proposed reference architecture is based on six

assumptions. First, an ad hoc sensor network’s

purpose is to offer services to it’s users and follows

a service model based on simple rules, depicted in

figure 1. Sensors can be tasked by users to collect

data and sensors provide data to users. In the process

of tasking, sensors can be configured, including

repositioned. If the network does not involve

human-taskers it is autonomous, but an architecture

is required to handle human as well as autonomous

users. Second, a clear functional allocation to

sensors, users, and manager elements is necessary,

where sensors are to “sense”, users are to” task

sensors and use their data”, and managers are to

“manage other users and sensors”. Overlapping

functions are to be avoided. Therefore, in the BSNF

all sensors by definition are attached to a network-

cognizant element.

Third, a network manager is responsible for overall

sensor and user configuration and administration in

comparison to the user, involved solely in sensor

tasking and data collection, processing, and analysis.

There is a benefit to separating the management and

user functions, as groups of users can now interact

with groups of sensors and vice versa under the

management of one or a few overarching managers.

Fourth, we adopt a management model similar to the

SNMP information model [14] that uses indirect

action invocation. This approach allows extension

of existing practical methods, in particular use of

indirect action invocation, which loosely couples the

internal processes of an agent from the external

driving management process. Indirect action

invocation makes use of a Management Information

Base (MIB). This loose coupling is important in

networks with variable delays and unreliable links

characteristic of many ad hoc networks.

Fifth, sensor network elements reside on top of a

communication layer forming an overlay network.

Within the overlay are logical groupings and

associations among elements, supported through

introduction of a Group Coordination Layer, GCL.

With the GCL a group of sensor elements can make

use of more than one communication network,

implement load leveling and cooperative replication

methods to move content efficiently, resolve tasking

conflicts that could arise, and reliably deliver content

and status information in the case of failures across

the network. As the communication layer becomes

less reliable the importance of the GCL increases.

Finally, network-cognizant elements are position

aware and make use of this information in routing

and tasking decisions. Location may be used in the

GCL and the underlying network layer. The

definition of position can be physical position given

by coordinates or it could be a measure of relative

distance.

BSNF Building Blocks

The essential functions of a sensor-network are

detection and measurement (i.e. sensing), sensor

control and scheduling (we refer to as tasking),

delivery and use of sensor information, management

of sensors and users, and the interaction and

Sensor User

User

1. Tasking- telling the sensor what to do

2. Data Sent to User

3. Shared Data Between

3

communication between assets. In the BSNF the

building blocks of any sensor network, that carry out

these essential functions is comprised of six

elements: sensors, sensor attached users, standalone

users, managers, and single or grouped

communication node elements. A group of

communication nodes forms a network and

abstracted as one element. Figure 2 shows the six

basic functional elements defined in the architecture,

with this notation used in later diagrams.

Sensors

A multitude of sensors exist in all regimes of the

electromagnetic, chemical, acoustic, atmospheric,

and other environments [15]. In BSNF we restrict

the sensor function to an entity that detects, stores,

processes, and passes on data to the network via a

locally attached element. By doing so a sensor is

reduced to a local element of detection

instrumentation and does not require awareness of

network topology, location, or information on users

and other sensors in the network.

Users

Two types of user elements are defined; both are

controllers of sensors, and consumers and processors

of sensor information. Networking of Sensors is

accomplished by a user element that acts as the

network gateway of that sensor, called a Sensor

Attached User, (SA-U). A user not attached to a

sensor is called a Free Agent User, (FA-U), and can

connect to SA-U’s to task and extract data gathered

from other sensors connected to SA-U’s. FA-U’s

can also exchange data with one another. Finally one

SA-U can task another SA-U. For example, an SA-U

based on measurements made from one of its local

sensors, can task or request other sensors in the

network to make follow up measurements.

Managers

While the user is responsible for tasking and

interpreting data from sensors, the manager is

responsible for the general operation of the network

including configuration and administration.

A Manager only cares about health, status, and

configuration of elements of the network and does

not task sensors or users to carry out mission related

operations. The manager conducts configuration,

administration, security, fault, and performance

management in line with the ISO Network

Management Model. The manager also plays an

important role in the operational and security

policies of the sensor network.

Communication Nodes (CN) and Networks

The communication elements carry out the Ad hoc

routing function as part of the networking layer. CNs

are essentially routers and a logical group of CNs

forms a sub-network shown as the 6th

building block.

Figure 2: Building Blocks of Sensor Networks

BSNF Composite Elements

Composite elements, which represent physical

devices, can be built with combinations of these

basic blocks. For example a device with 2 Sensors+

1 SA-U + 1 CN comprises two networked sensors

that can be accessed by other users. This is shown in

Figure 3. Many combinations of building blocks are

possible, and any physical representation of a system

can be constructed from these building blocks.

Figure 3- Composite Element comprised of 2

Sensors, SA-User, and Communication Node.

Segregation of sensor network functions into

building blocks results in an architecture that permits

the development of inter-changeable and compatible

sensor, user, and management elements. This

segmentation approach has worked well in telecomm

systems and should work well in these

environments. [8], [16]

BSNF Functional Interfaces between Elements

•Sensor – S

•Manager

•Communication Node(CN)

•Communication Sub-Network

•User SA-U FA-U

•Free Agent User FA-U

4

The functional interfaces between sensor network

building blocks are shown in Figure 4. All of the

interfaces across networks, that is Manager -

Manager, User - User, Manager - User interfaces can

be standardized at the network and application level.

The means for transporting message level data

across these interfaces can use a Web Services

model based on XML/ SOAP [17] or an SNMP-like

model based on ASN.1 (Abstract Syntax Notation)

[18]. Whatever approach is taken, a large network

would require a hierarchical structure and the BSNF

and any associated standards will need to support

that as well.

Referring to Figure 4, observe that the sensor shown

on the upper left side is attached to a SA-U via a

proprietary interface whereas the other messaging

interfaces are standardized. The main information

flowing from the FA-U to the SA-U is tasking and

control information, and the information flowing

from the SA-U to the FA-U is sensor data. Data

flowing between FA-Us is raw or processed sensor

data. In this architecture a SA-U can task other SA-

U s( not shown in the figure ).

Figure 4: BSNF Functional Interfaces

BSNF Layered Reference Model

The coarse layering of these elements, consistent

with an overlay network concept is shown in figure

5 comprising a sensor layer and a communication

layer. The communication layer covers transport

layers on downward while the sensor layer sees the

communication network as an abstraction and allows

a sensor network to span different networks. Note

the position of the Sensors in figure 5; they always

sit on top of a SA-U.

Figure 5: Sensor Elements form an overlay on

top of the Communication Network

The layered BSNF reference architecture is shown in

figure 6 where the layering is similar to, but not

exactly matching the ISO OSI model [8]. Protocols

operate across equivalent layers. For example, a

network employing Mobile IP over a wireless LAN,

the protocols are TCP (level 4), IP (level 3), and

802.11.x (level 2/1) where x depends on the

particular variant of protocol. We now discuss the

nature of the protocols at the application layers.

Sensor Element Layer The FA-U, SA-U and Manager elements depicted in

figure 4 span levels 5, 6, and 7 depicted in Figure 6.

At Level 7, resides application-unique (i.e.

proprietary) functions, including sensors,

management and user applications. Level 6 in Figure

5 contains a standardized MIB and message

structure. By design, there is no attempt to

standardize at Level 7, which would include specific

processing applications and User interfaces, as there

is too much variability. However every attempt in

made to standardize at level 6. The next layer down,

level 5, labeled GCL corresponds to the Group

Coordination Layer. The GCL conducts the basic set

of information and messaging functions used to

coordinate between groups of sensors and users, and

is standardized as well.

Handoff between Level 7 and 6 within a host would

require an application programming interfaces, but

in principle none would be required between layers 6

and 5.

Figure 6: BSNF Layered Sensor reference model

Communication Layer

Sensor Element Layer

Sensor Data

Sensor Configuration

Sensor Operational Status

User Status User Configuration

Proprietary Standardized

Sensor Control

Manager to Manager

FA-U to FA-U data

prop

STD.

G C L

Transport

Network

Link/ Physical

STD.

G C L

Transport

Network

Link/ Physical

prop

STD.

G C L

Transport

Network

Link/ Physical

7 6 5 4 3 2/1

Sensor SA-U Manager FA-U

5

Sensor Element Layer Management Model

The information that resides in the Manager, SA-U,

and FA-U can be standardized using a common

information and communication model between

elements. We advocate using a system/information

model similar to that used in SNMP Network

Management [19]. Two messaging schemes are

possible, one based on the SNMP model (ASN

syntax, BER encoding, UDP transport) in use for

nearly 15 years, or one based on using an XML

schema (HTTP, TCP) and SOAP as a standard.

Whatever method is adopted, the BSNF makes use

of a MIB and indirect action invocation methods.

In this architecture we use a MIB (Management

Information Base)-type information model similar to

that of the successful SNMP model. The manager

contains a MIB of all the users and sensor elements

in the network and is able to do a GET or SET (or

POST using XML) on any of them. A user will

contain MIBS of other users and elements in the

network.

The MIB is a structured virtual database that

contains properties of sensors and users, each

property is depicted as a data object and stored in

the MIB. A Manager or other users, with allowable

permissions may update an entity through a MIB

object SET, or retrieve MIB values from that entity,

using a MIB object GET. A set is equivalent to a

WRITE and a GET is equivalent to a READ In case

of a SET the entity with a new setting will act to

change it’s system configuration using it’s own

internal process, therefore the action is indirect

rather than direct. This approach also allows for an

element to report an event to a network manager,

such as a HW failure, or signal overload.

The challenge to a workable system management

information model is scalability so to allow minimal

overheads, for low power/ memory sensor elements,

up to multi-function sensors with complex functions

and less constrained power and memory

requirements and reliability The SNMP type model

MIB is scalable and accommodates a minimal MIB,

needed for a lightweight device described by a few

objects, up to a complex MIB that may contain

many thousands of objects. Given a MANET’s

inherent limited reliability, the application

messaging should be sent using a connection

oriented transport protocol, which differs from the

basic SNMP model that used connectionless UDP.

[20]

A light weight variant of the SNMP model requiring

minimal storage and processing on the network

element side could be constructed. The basic

information elements required for all Sensors are an

Element Unique Identifier (ID), and identification of

it’s SA-U. A MIB for a simple sensor element is

shown in Table 1. The Sensor MIB does not need to

contain any network specific information, such as

network address. The last entry in Table 1.

represents the actual commanding and data elements

of the sensor and these could be extensive and would

be constructed by the developer of the Sensor

Table 1: Basic MIB for a Sensor Element Example Entry

Element ID Unique field that identifies

the sensor

( formal ID)

Element Type Basic Class of Sensor

Element Name Human Recognizable Name

given to Sensor

SAU- ID Unique field that identifies

the attached SA-U

Sensor Description Textual description of what

the sensor does, manufacturer

of sensor, etc

Sensor Owner Organization responsible for

Sensor

Sensor Status Ready, not Ready, In Use

Sensor Configuration

and Data Table

Table of objects that define the

configuration, used for tasking

and collecting data

Any sensor MIB would be extended from Table 1 to

incorporate control and data elements. One of the

advantages of the SNMP-like approach is that each

vendor device would develop and publish its own

MIB. This practice is well established in the

management of communication networks.

The basic MIB for a SA-U or FA-U would include

an association to any sensors attached to it as well as

its administrative and status information as shown in

Table 2.

Table 2: Basic MIB for a SA-User/ FA-user Element Example Entry

Element ID Unique identifier the SA-User(

formal ID)

Element Type User

6

Element Name Human recognizable Name (

informal )

User Description Textual description of what this

user does

User Owner Organization responsible for

this User

Status List of status indicators

Number of

attached Sensors

= 0 (then FA-U)

> = 1 ( then SA-U)

Sensor Attached

List

List of sensor Element ID

numbers of attached Sensors

Configuration

and Data

Elements

Numerous elements used in

operations.

Notice that table 2 contains information on the User

and the association to Sensors. When we cover the

GCL layer we define a MIB that has group and

addressing information in it, this is used to tie a user

into a Group, to give it’s location, and its network

address.

The BSNF Communication Layer

The Communication Layer shown in Figure5 is

comprised of Layer 4 and below; (4) transport, (3)

network, (2) link, and (1)physical as defined in the

ISO OSI reference model [12]. As the focus is on the

application levels we do not address level 4,3,2,1

and assume that they work. This means that in

principle the sensor element framework should be

able to work on top of any network and in the case

of mobile networks we shall see that the GCL is

used to improve reliability and performance. Placing

the GCL within the sensor element layer rather than

the communication layer is rationalized as it is more

closely associated with applications data distribution

than with networking, although one could argue the

GCL could reside in the communication layer.

The Need for the GCL

The most complex part of the BSNF is the GCL and

much of the remainder of the paper addresses this.

The GCL handles group dynamics such as sensor

tasking, cooperative distribution and processing,

distributed search and query, and group addressing.

This layer is often referred to as middleware in

distributed systems jargon [21], [22]. Symmetric

P2P system architectures contain a higher level of

complexity compared to client- server architectures

and concentrating all this complexity into one layer

facilitates standardization.

The GCL is common across Users and Managers

and all elements would contain a GCL SW layer as

part of the host’s application stack as depicted in

figure 7. Associations in this layer are dynamic;

sensors and users come and go, and the GCL is

responsible for keeping track and updating current

group membership around the network. In simple

networks with fixed locations, and static associations

between elements, the GCL need is minimized but in

more complex applications this layer performs

dynamic addressing, multi-casting, replication, and

conflict / resource management. The GCL by its

position above the Transport Layer can also be used

to direct traffic through different networks; in this

case one group address will be associated with more

than one network address.

Figure 7: Group Coordination Layer, used

to connect to different networks

Structure of the GCL

How does the GCL accomplish the functions

described above? The key is developing a protocol

for formation and definition of groups and providing

a reliable means to share membership information

and data within the groups. A group is defined as a

set of user nodes that exchange information and

handle sensor tasking amongst themselves. For the

network to function, each element would need to

know what group(s) it is in and who the other

members of the group are. Associated with the group

are a set of properties that govern privilege and

access. As an example consider a group of FA – U’s

that want to subscribe to the data offered by the

sensor located at SA-1. A group is established,

designated Group-M, such that all members in that

group can share data. The group is the set:

GCL GCL 5: GCL

Network 1

Network 2

7

{Group-M.FA-1, …. ,Group-M.FA-N, Group-

M.SA-1.Sensor1}.

See Figure 8 for an illustration of the grouping. We

use the convention:

GROUP_NAME. USER_ID. SENSOR_ID

to represent that the sensor, SENSOR_ID, is

attached to the user USER_ID which is a member of

the group, GROUP_NAME.

Grouping can be flexible where one entity may be a

member of more than one group as shown in Figure

8. In this case FA-i has access to all the sensors

shown in the figure.

Fig. 8: Logical Grouping of Sensor Elements

Example Uses of the GCL

An ad hoc sensor network is often resource limited

and routing cost is highly distance sensitive. If N

users are requesting the same information from the

same sensor, bottlenecks and congestion will occur

in the network at or near the source. Whether the

delivery of information to users is via a stream of by

an asynchronous method such as File Transfer, the

GCL can be used to form a multicast channel where

nodes seek the needed content from the nearest

neighbor that has the content. Nearest neighbor

distance metric is computed using the absolute

location or some other metric that reflects routing

cost. The GCL protocol needs to be flexible to

accommodate different distance or cost metrics. This

multicast scheme is shown in figure 9A and

compared to 9B, the case where multicasting could

not be implemented, and the sensor needs to send the

data to N users.

Figure 9: Logical Flow of Data from Sensor to

Many destinations using cooperative

Multicast (a.) vs. sending directly from one point

to many, (b.)

A.

B.

Arrangement (A), in figure 9 can deliver content

faster than (B.) and also relieve the originating node

of the burden of having to deliver to each node.

Consider an example where the SA-U shown in

figure 9 has an effective bandwidth B, to represent

any connection to any of the FA-U’s shown in the

figure. The minimum time required to get the

information of size S from the sensor to all eight

elements is given by S*B*8, by comparison the time

to distribute to the nodes shown in (A) is 3*B*S.

Since the GCL is an overlay of the actual network,

information exchange between group members may

occur over nodes that are not part of the group. For

example Group-M.FA-I and Group M.FA-J may

be extracting data from a sensor, Group-M. SA-

1.Sensor-1 The actual data path could be routed

through other communication nodes having sensor

elements that are not part of the group. This concept

is demonstrated in Figure 10, showing the path

through the actual communication layer goes via

hops through CNs not necessarily part of the group,

in this case Group-N.FA-1, which is not part of

Group-M.

Group-M

FA-1

FA-N

SA-1

SA-i

SA-k

Group-N

FA-i

8

Figure 10: Routing using via nodes not part of the

group

The GCL also facilitates in the regulation of

conflicts from multiple users requesting to use the

same sensor or in arranging scheduling. Conflicts

can be resolved by the GCL letting other users know

that the sensor is already being tasked and if a

priority / pre-emption scheme is included, a high

priority user can take over control of a sensor as a

low priority user relinquishes control.

Implementing the Grouping Layer

Standards for the GCL will depend on the method of

implementation. There are a number of approaches,

from completely decentralized to entirely

centralized. A completely decentralized approach

would allow groups to form and manage themselves

without any central point of focus. This is unwieldy

from a security and performance perspective.

However a completely centralized approach would

require that each node go to one source for every

instruction. This is inefficient and certainly would

not scale well. What is best is to take a compromise

approach, often called a brokered Peer to Peer [22].

In this case one central entity keeps track of group

membership and behaviors but allows peers to

exchange directly within the constraints of those

rules.

In BSNF with a brokered approach, a GCL master

MIB is collocated with the manager. This MIB has

the structure of the entire sensor network, defining

all the Groups. The process by which groups are

initially defined in the Manager can be manual, but

changes to the groups and even creation of new

groups would be done autonomously and need to be

supported by the GCL protocol. Users would also

have their own GCL MIBs that reflect the group(s)

they are in.

In the BNSF the manager maintains authority over

group definitions and membership, SA-U’s and FA-

U’s may register with different groups based on

needs and permissions via contact with the manager.

As part of the protocol the User would be able to

browse the properties of each group and decide

whether to join it or not. Acceptance is granted if

the user meets the criteria defined within the

properties and whether the group can support

additional members given possible resource

constraints. One of the properties is access level and

each member is granted a certain level by the

manager. All group members maintain a copy of the

Groups properties and group member’s access and

use it in their actions with each other. If a member is

added or withdrawn from the group, the Manager

sends out an update message to all nodes within the

group. This update message includes the needed

information about the group member. The joining

member is also given a full contact list. Upon

coming into the network the new member can send a

GCL level hello message to all the other members of

the group and collaborate with other group members

based on its access.

Figure 11 shows the registration process, a new user

makes a request to the manager (1.), the manager

grants access, and sends a member list and

properties to the new member which is entered into

the Users GCL MIB (2.), the Manager updates its

MIB, and then sends updates to all other members of

that group giving the information on the new group

Member. All the other users update their MIB (3),

communication between the new user and other

group members can now occur (4).

Figure 11: Brokered Approach to GCL Group

membership

The GCL MIB

The GCL associates with each User the following

items; Group – ID, Group Member Name (which is

GCL MIB Manager

New User Joins

1. Request

2. Granted Group Member Information

Is sent

GCL

3. Other Group Members MIB updated to account for new group member

Other Members Updated

4. Communication with new group member becomes possible

Group-M.SA-1

Group-M.FA-I

Group-M.FA-J Group-N.FA-x

Group-M.FA-1

9

the User and Sensor ID), Network Address, Access

Level, Sensor List, and Location. These elements are

described in Table 3. These information elements

could be stored in Level 6( of Figure 6) of the users

MIB, however given the separation in layers

between 6 and 5, each user has a self contained GCL

MIB, as seen in figure 11. The Group Member ID

for any sensor level element is associated with

network addresses of the CN it is connected to,

giving the handle between level 5 and level 4 and 3.

Each group member will store and use a group

membership list that is maintained by passing

messages among group members. The GCL

messaging follows similar rules and syntax as the

information messaging in the sensor layer

management model.

Table 3 Elements in GCL MIB Table for a User Object Description

USER ID Unique identifier for the

User( formal ID)- same as in

table 2

Location Position of User

Sensor List List of Element ID attached to

User

Number of Groups

User is part of

An Integer N

Group 1 Group N Property Description

Table for Group1

members

Group members ID, network

address list, location, group

member access level

Group 2 Group N Property Description

Table for Group 2 Group members ID , network

address list, location, group

member access level

<<<<<

Group N Group N Property Description

Table for Group

N

Group members ID , network

address list, location, group

member access level

Location and Sensors In the BSNF users are assumed to be able to

determine their location. Location is an important

element in many sensor network applications and

there are many considerations that need to be taken

into account[13]. Assuming a relevant location

metric can be determined by a user on a periodic

basis, if users are moving, the location value in the

GCL MIB is updated. Any manager or user could

determine the location of another User by reading

this MIB value. In addition location updates could

be sent out periodically to the manager, and as part

of any outgoing messages sent to users. In

developing the messaging protocol every out going

message would have a location field in the GCL

header giving it’s most recent position.

Sensors in the BSNF are not directly attached to the

network but are associated with a SA-U,(see Table

1). Any group member can contact any other SA-U

to determine what sensors are attached to them and

what their location is. When a user joins a network it

can go through a discovery process that allows it to

determine what sensors are on the network and learn

about it’s properties. In addition a manager could

include on the membership list sensors using the

nomenclature Group. User. Sensor.

Scalability, Reliability, and Security of the

Brokered GCL approach

A system comprised of many nodes and many

groups can be a large burden on the manager

needing to update all the other group members every

time there is a change. This problem however can be

mitigated by distributing the GCL messages via the

multicast capability inherent in the GCL as shown in

Figure 9a. Another weakness of the brokered

approach is that the main node can be a single point

of failure. This weakness can be reduced by using a

backup GCL manager that can be kept in synch with

the main manager. All nodes in the event that they

could not contact the primary would contact the

alternate. The Brokered GCL approach provides

strong group access security since any joining

members must get permission granted from the

manager, and the manager needs to notify all the

other users that a new member has joined. In

addition if a rogue user is to be removed from a

group, the manager can send a message out to all

other group members removing the rogue user from

the access list.

To this point we have not addressed the overall issue

of security in this architecture as it is beyond the

scope of this framework. Given the layering

concept, encryption and authentication security can

be part of the network layer, however it could be

added into the GLC layer as well . Once again the

brokered P2P approach with a manager simplifies

the key management issues that would come up in

implementing a secure GCL layer.

10

Benefit of BSNF based Standards

The development of the level 5 and 6 protocols and

their specification would cover the information

model, the messaging model, across the functional

interfaces at both layers 5 and 6, and programming

interface from layer 7 to 6. The general framework

if implemented would have many benefits. A general

framework with the building block approach could

be used to model and estimate complexity of sensor

systems to be developed. With BSNF specifications,

management products can be built or existing

network management ones extended to manage

sensor networks. Software that implements the GCL

can be built into various operating systems.

Developers of Sensors will have the tools needed to

build BSNF compliant systems without having to

“reinvent the wheel”. Some progress has been made

in providing tools for development of the GCL[23].

Builders of specialized sensors can develop closed

interfaces on the sensor side and standard control,

status, and transfer on the network side.

Future Work

This BSNF can be used as a starting point for

developing a group of sensor network standards.

This work serves as a framework for protocol

development and analysis of level 5 and 6. Some

parts of the proposed framework are straightforward,

such as developing an information model of the

Sensor layer elements, while developing the best

approach for GCL still needs substantial effort,

requiring analysis of different distribution

algorithms and the role of important factors such as

location. The framework could be used for

developing requirements specifications in large

systems.

The focus of this work is on structure but clearly

important implementation aspects such as security

and use of location details need additional effort. As

with any complex effort, the BSNF should be

implemented incrementally and pieces can be built

and tested independently of one another. For

example an information model using basic MIBs can

be built using the ideas presented here. This would

allow a way to at least standardize network

management in these networks.

Summary and Conclusions

Given the utility and complexity of ad-hoc self

organizing sensor networks, a general layered

architectural framework is required followed by

development of standards is essential. While some

standardization efforts have occurred to date they

have been niche specific. The paper using 6 key

ideas creates a general but comprehensive

framework called BSNF for ad hoc sensor networks

amenable to standardization. Key concepts include a

simple service model, a clear partitioning of

functions into users, sensors, and managers,

development of an SNMP-like information model,

use of location awareness, and development of a

Group Coordination Layer, used to deal with the

cooperative groupings, processes, and tasking

associated with self organizing autonomous sensor

networks. We use a brokered Peer-to-Peer

architecture. The paper points out where to

standardize and where not and lays out a proposal

for how standards can be developed.

References [1] G.Pottie and W. Kaiser, “Wireless integrated

network sensors”, Communications of the ACM

43(5):51-58, May 2000

[2] J, Hill, R. Szeweczyk,, A. Woo, S. Hollar,

D.Culler and K.Pister, “System architecture

directions for networked sensors”. ACM Sigplan

Notices, vol 35, no 11, 2000

[3] D.Estrin, L.Girod, G. Pottie, and M. Srivastava,”

Instrumenting the World with Wireless Sensor

Networks” in International Conference on Acoustics,

Speech, and Signal Processing ( ICASSP 2001),

May 2001

[4] Perkins C.E.(ed.) Ad Hoc Networking, Boston,

Addison-Wesley 2001

[5]Perkins CE and Royers, K.” Ad-hoc On-demand

Distance Vector Routing, Proc. Second Ann. IEEE

Workshop on Mobile Computing Systems and

Applications, pg 99 – 100 , 1999

[6] K.Chandran et al, “ A Feedback Based Scheme

for Improving TCP Performance in Ad Hoc

Networks”, IEEE Personal Communication

Systems(PCS) Magazine Special Issue on Ad Hoc

Networks, Vol 8 pp.34-39, February 2001

[7] K-W. Chin, et al”Implementation Experience

with MANET Routing Protocols,”ACM SIGCOMM

Computer Communications Review, Nov 2002,

pp.49-59

[8] A. Tanenbaum, Computer Networks, Sec 1.6,4th

Edition,2002, Prentice Hall PTR

[9] M. Hatler, M. W. Ritter, The Zigbee Revolution:

Expanding Markets for Short Range, Low Power

11

Wireless, July 2003, On World Emerging Wireless

Research www.onworld.com/html/zigbeerreprt.htm

[10] M. Botts (ed.)Sensor Model Language

(SensorML) for In-situ and Remote Sensors,Draft ,

Ref Number OGC 04-019r2

[11] M.Kelaskar, V.Matossian, P.Mehra, D. Paul,

and M/Parashar, Proceedings of the 2nd

IEEE/ACM

International Symposium on Cluster Computing and

the Grid

[12] A. Ferscha, M. Hechinger, R. Mayrhofer, and

R. Oberhauser, “ A Light-Weight Component Model

for Peer-to-Peer Applications”, www.soft.uni-

linz.ac.at

[13] T. He,C. Huang, B. Blum, J. Stankovic, T.

Abdelzaher, “Range-Free Localization Schemes for

Large Scale Sensor Networks” MobiComm 2003

[14] W. Stallings, SNMP V3,2,1 and RMON, 3rd

edition 1999, Addison-Wesley.[10] M. Botts

(ed.)Sensor Model Language ( SensorML) for In-

situ and Remote Sensors,Draft , Ref Number OGC

04-019r2

[15]I.F. Akyildiz et al.,” A Survey on Sensor

Networks,” IEEE Communications Magazine,

August 2002, pp 102- 114

[16] Standards and Telecommunication

Development., World Telecommunication

Development Conference(WTDC-02) ETSI,

Istanbul, Turkey, 18-27 March 2002

[17] H.T. Ju, et. al. “AnEmbedded Web Server

Architecture for XML-based Netowrk

Management”’ Proc. IEEE/IFIP Network Operations

and Management Symposium ( NOMS 2002),

Florence, Italy, Apr. 2002,pp 1 – 14

[18] M. Subramanian, Network Management ,

Principles and Practices, 2000, Addison-Wesley

[19] RFC1213, Rose, M. Management Information

Base for TCP/IP Networks, MIB-II, 1991

[20]RFC 1905 J. Case, M. McClogrie, M. Rose, and

S. Waldbusser, Protocol Operations fro Version 2 of

the Simple Network Management Protocol , 1996

[21] A. Rowstron and P. Druschel, Pastry: Scalable

distributed object location and routing for large scale

peer to peer systems IFIP/ACM International

Conference on Distributed Systems( Middleware)

November 2001

[22] Peer-to-Peer: Harnessing the Power of

Disruptive Technologies, A. Oram, O’Reilly

Publshers, March 2001

[23] M. Bisignano, A. Calvagna, G. Di Modica, and

O. Tomarchio:”Experience: A JXTA middleware for

mobile ad-hoc networks”, Proceedings of the Third

International Conference on Peer-to-Peer Computing

2003, pp 214-5.