A

framework

and

tool

supports

for

generating

test

inputs

of

AspectJ

programs

Aspect-oriented

software

development

is

gaining

popularity

with

the

wider

adoption

of

languages

such

as

AspectJ.

To

reduce

the

manual

effort

of

testing

aspects

in

AspectJ

programs,

we

have

developed

a

framework,

called

Aspectra,

that

automates

generation

of

test

inputs

for

testing

aspectual

behavior,

i.e.,

the

behavior

implemented

in

pieces

of

advice

or

intertype

methods

defined

in

aspects.

To

test

aspects,

developers

construct

base

classes

into

which

the

aspects

are

woven

to

form

woven

classes.

Our

approach

leverages

existing

test-generation

tools

to

generate

test

inputs

for

the

woven

classes;

these

test

inputs

indirectly

exercise

the

aspects.

To

enable

aspects

to

be

exercised

during

test

generation,

Aspectra

automatically

synthesizes

appropriate

wrapper

classes

for

woven

classes.

To

assess

the

quality

of

the

generated

tests,

Aspectra

defines

and

measures

aspectual

branch

coverage

(branch

coverage

within

aspects).

To

provide

guidance

for

developers

to

improve

test

coverage,

Aspectra

also

defines

interaction

coverage.

We

have

developed

tools

for

automating

Aspectra's

wrapper

synthesis

and

coverage

measurement,

and

applied

them

on

testing

subjects

taken

from

a

variety

of

sources.

Our

experience

has

shown

that

Aspectra

effectively

provides

tool

supports

in

enabling

existing

test-generation

tools

to

generate

test

inputs

for

improving

aspectual

branch

coverage.

Aspect-oriented

software

development

(AOSD)

is

a

new

technique

that

improves

separation

of

concerns

in

software

development

AOSD

makes

it

possible

to

modularize

crosscutting

concerns

of

a

software

system,

thus

making

it

easier

to

maintain

and

evolve.

Research

in

AOSD

has

focused

mostly

on

the

activities

of

software

system

design,

problem

analysis,

and

language

implementation.

Although

it

is

well

known

that

testing

is

a

labor-intensive

process

that

can

account

for

half

the

total

cost

of

software

development

research

on

testing

of

AOSD,

especially

automated

testing,

has

received

little

attention..

Although

several

approaches

have

been

proposed

recently

for

testing

aspect-oriented

programs

of

these

approaches

is

able

to

provide

a

framework

for

automated

generation

of

test

inputs

for

AspectJ

programs.

AOSD

can

lead

to

betterquality

software,

but

it

does

not

provide

the

correctness

by

itself.

An

aspect-oriented

design

can

lead

to

a

better

system

architecture,

and

an

aspect-oriented

programming

language

enforces

a

disciplined

coding

style,

but

they

do

not

protect

against

mistakes

made

by

programmers

during

the

system

development.

In

addition,

Aspectoriented

programming

can

introduce

specific

(and

hard

to

detect)

errors

that

ordinary

object-oriented

programming

is

not

subject

to.

As

a

result,

software

testing

remains

an

inevitable

and

important

task

in

AOSD..

Aspect-oriented

programming

languages,

such

as

AspectJ

introduce

some

new

language

constructs

(such

as

join

points,

advice,

intertype

declarations,

and

aspects)

to

the

common

objectoriented

programming

languages,

such

as

Java.

The

behavior

of

an

aspect

in

AspectJ

programs

can

be

categorized

into

two

types

aspectual

behavior

(behavior

implemented

in

pieces

of

advice)

and

aspectual

composition

behavior

(behavior

implemented

in

pointcuts

for

composition

between

base

and

aspectual

behavior)..

When

we

treat

an

aspect

as

a

unit

and

intend

to

test

its

aspectual

behavior,

unit

tests

for

an

aspect

are

created

to

test

in

isolation

pieces

of

advice

defined

in

the

aspect.

However,

it

is

often

difficult

to

manually

or

automatically

construct

the

aspect's

execution

context

in

unit

tests.

When

we

intend

to

test

aspectual

composition

behavior

related

to

an

aspect,

integration

tests

for

the

aspect

are

created

to

test

interaction

or

composition

between

the

aspect

class

and

the

affected

classes.

These

integration

tests

can

consist

of

invocations

of

those

methods

affected

by

the

aspect.

These

invocations

eventually

exercise

the

interaction

between

the

aspect

class

and

the

affected

classes

by

invoking

pieces

of

advice

from

the

advice-call

sites

inserted

within

the

affected

classes..

Our

research

focuses

on

automatic

generation

of

test

inputs

that

test

aspectual

behavior,

an

important

type

of

an

aspect's

behavior.

We

leave

the

issue

on

automatic

generation

of

test

inputs

for

aspectual

composition

behavior

for

our

future

work.

Specifically,

we

propose

Aspectra,

a

novel

framework

for

generating

test

inputs

to

exercise

aspectual

behavior.

Given

aspects

to

be

tested,

developers

can

construct

base

classes

that

the

aspects

can

be

woven

into

to

produce

woven

classes.

We

can

view

these

base

classes

as

providing

scaffoldings

necessary

to

drive

the

aspects.

Aspectra

develops

a

wrapper-synthesis

technique

to

address

aspect

weaving

issues

in

test

generation

(by

providing

visibility

of

woven

methods

to

test-generation

tools

and

avoiding

unwanted

weaving).

Given

a

woven

class,

Aspectra

automatically

synthesizes

a

wrapper

class

for

the

woven

class

and

then

feeds

the

wrapper

class

to

our

testgeneration

tool

based

on

state

exploration

In

order

to

assess

the

quality

of

generated

tests,

we

define

and

measure

aspectual

branch

coverage,

which

characterizes

branch

coverage

within

aspect

code.

Sometimes

initially

generated

test

inputs

for

base

classes

(constructed

by

developers)

may

not

be

sufficient

to

achieve

good

aspectual

branch

coverage.

To

guide

developers

to

improve

test

coverage,

we

define

interaction

coverage

that

measures

the

interactions

among

four

types

of

methods

in

AspectJ

programs

(which

will

be

explained

in

Section

advised

methods

(defined

in

base

classes),

advice,

intertype

methods,

and

public

non-advice

methods

(defined

in

aspects).

These

measurement

results

guide

developers

to

improve

the

base-class

construction

and

test

generation..

This

paper

makes

the

following

main

contributions

with

the

proposal

of

the

Aspectra

framework..

We

develop

a

wrapper-synthesis

technique

that

prepares

woven

classes

to

be

given

to

test-generation

tools;

The

synthesized

wrapper

classes

provide

a

clean

interface

between

the

program

under

test

and

test-generation

tools.We

implement

a

tool

to

automate

the

wrapper

synthesis..

We

leverage

existing

tools

for

testing

Java

programs

to

generate

tests

for

AspectJ

programs..

We

define

and

measure

branch

coverage

within

aspect

code.

We

also

classify

four

types

of

methods

in

AspectJ

programs

and

measure

the

interactions

among

them.

We

implement

tools

to

automate

these

measurements.

We

provide

guidelines

for

developers

to

use

these

measurement

results

to

improve

test

coverage..

We

describe

our

experience

in

applying

Aspectra

to

AspectJ

programs

from

a

variety

of

sources.

The

experience

shows

that

Aspectra

provides

effective

tool

supports

to

generate

test

inputs

for

increasing

structural

coverage

of

aspect

code..

The

rest

of

the

paper

is

organized

as

follows.

Section

briefly

introduces

AspectJ.

Section

presents

an

example

that

we

shall

use

to

illustrate

our

approach.

Section

presents

our

Aspectra

framework.

Section

describes

our

implementation

for

Aspectra.

Section

presents

our

experience

in

applying

Aspectra

on

various

AspectJ

programs.

Section

discusses

related

work

and

Section

concludes.

We

proposed

Aspectra,

a

novel

framework

for

automatically

generating

test

inputs

for

AspectJ

programs.

To

test

aspects

in

an

AspectJ

program,

developers

can

construct

base

classes,

which

can

be

woven

with

aspects

to

produce

woven

classes.

Aspectra

synthesizes

a

wrapper

class

for

each

woven

class.

The

wrapper

mechanism

allows

test-generation

tools

to

indirectly

exercise

advice

related

to

call

join

points

and

public

non-advice

methods

in

aspects

during

test

generation.

At

the

same

time,

the

mechanism

prevents

the

methods

in

generated

test

classes

from

being

advised

by

unwanted

advice.

Given

wrapper

classes,

Aspectra

leverages

existing

test-generation

tools

for

generating

test

inputs.

But

sometimes

behavior

in

aspects

may

not

be

sufficiently

exercised

by

test

inputs

initially

generated

by

these

tools

for

base

classes

constructed

by

developers.

To

assess

the

quality

of

generated

test

inputs,

we

define

and

measure

aspectual

branch

coverage

and

interaction

coverage

based

on

four

types

of

methods

in

AspectJ

programs:

advised

methods,

advice,

intertype

methods,

and

public

non-advice

methods.

We

provide

guidelines

for

developers

to

use

measurement

results

to

improve

base-class

construction

or

test

generation.

Our

experience

shows

that

our

wrapper

mechanism

is

necessary

for

some

important

types

of

AspectJ

programs

and

our

measurement

results

provide

useful

guidance

for

improving

test

coverage..

In

future

work,

we

plan

to

adapt

our

framework

implementation

to

accommodate

AspectJ

code

compiled

by

other

compilers

such

as

abc

We

plan

to

provide

tool

supports

for

automatic

construction

of

base

classes

given

aspects.

We

also

plan

to

extend

our

framework

to

address

testing

of

other

important

behavior

such

as

aspectual

composition

behavior,

including

not

only

interactions

between

base

classes

and

aspects

but

also

interactions

among

multiple

aspects.

Although

we

applied

Aspectra

on

only

AspectJ

benchmarks,

we

expect

that

Aspectra

can

be

applied

to

a

wide

range

of

AspectJ

programs.

In

our

experience,

the

wrapper

mechanism

is

useful

in

test

generation

when

advice

is

call

advice

and

there

are

no

call

sites

of

its

advised

methods

in

the

code

base.

In

addition,

the

wrapper

mechanism

is

useful

in

test

generation

for

public

non-advice

methods

of

aspect

classes.

From

our

experience

with

testing

these

benchmarks,

constructing

appropriate

base

classes

turned

out

to

be

more

important

than

we

originally

thought,

especially

for

complex

aspects.

As

we

discussed

in

Section

we

simply

used

Stack

for

those

aspects

that

were

not

equipped

with

base

classes.

It

turned

out

that

Stack

may

not

be

sufficient

for

some

aspects

such

as

DCM

and

LoD.

The

measurement

results

of

both

interaction

coverage

and

aspectual

branch

coverage

are

helpful

for

guiding

us

in

improving

base

classes

as

well

as

test

generation.

But

at

the

same

time,

we

also

noticed

that

it

is

sometimes

not

trivial

to

manually

figure

out

how

to

improve

test

coverage,

especially

when

we

were

not

familiar

with

the

code

base

under

test.

This

observation

suggests

the

need

of

developing

tools

to

automatically

construct

appropriate

base

classes

given

aspects.

We

plan

to

pursue

this

research

direction

in

our

future

work..

The

runtime

overhead

of

applying

Aspectra

is

low.

Because

our

coverage

measurement

is

focused

on

aspects

or

interactions

between

aspects

and

base

classes,

the

runtime

overhead

of

measurement

is

negligible.

Although

running

Rostra

with

a

large

number

of

iterations

could

be

expensive,

all

benchmarks

except

for

StateDesignPattern

require

no

more

than

three

iterations

to

achieve

optimal

aspectual

branch

coverage

with

Jtest-generated

arguments..

Sometimes

Jtest-generated

arguments

are

not

sufficient

(such

as

those

for

BusinessRuleImpl).

We

expect

that

using

a

more

powerful

tool

with

symbolic

execution

could

generate

better

arguments

to

cover

some

branches

and

thus

reduce

manual

efforts

in

producing

relevant

method

arguments

based

on

coverage

measurement

results..

Aspectra

focuses

on

testing

aspectual

behavior.

Although

Aspectra

also

measures

interaction

coverage

and

tries

to

cover

the

interactions

between

aspects

and

base

classes,

testing

aspectual

composition

behavior

may

require

developments

of

new

techniques..

Aspectra

tests

aspectual

behavior

of

an

aspect

by

weaving

the

aspect

with

one

or

several

constructed

base

classes

(including

only

several

representative

base

classes

if

the

total

number

of

base

classes

is

too

large).

Then

it

leverages

the

existing

test-generation

tools

to

generate

test

inputs

on

a

per-class

basis.

Indeed,

in

the

context

of

AOP,

an

aspect

typically

impacts

more

than

one

class

and

the

aspect

is

usually

executed

in

a

broader

context

than

what

Aspectra

has

tested.

However,

as

was

argued

by

Lopes

and

Ngo

testing

aspectual

behavior

individually

can

be

cost-effective

in

diagnosing

failures

and

detecting

faults

in

aspectual

implementations.

In

addition,

they

found

that

the

majority

of

existing

aspects

are

general

purpose

such

as

logging,

tracing,

persistence,

profiling,

and

design

patterns.

Testing

these

aspects

woven

with

some

representative

base

classes

can

often

be

effective

in

detecting

faults

in

aspectual

implementations

before

integration

testing

is

done.

NonNegativeArg

has

an

execution

join

point

and

using

wrapper

classes

does

not

offer

further

help

in

test

generation.

The

generated

test

inputs

achieved

aspectual

branch

coverage.

Our

tool

reported

that

the

following

call

site

is

not

covered:

a

call

site

(in

Stack's

iterator

method)

that

invokes

the

before

advice

in

NonNegativeArg.

We

inspected

the

Stack

code

and

found

that

iterator

is

not

declared

as

public

and

Jtest

or

Rostra

generates

test

inputs

only

for

public

methods.

We

then

declared

iterator

as

a

public

method

and

regenerated

test

inputs.

The

generated

test

inputs

could

achieve

interaction

coverage.

But

our

tool

still

reported

that

the

false

branch

of

(args[i]

instanceof

Integer)

in

NonNegativeArg

(shown

in

Figure

was

not

covered.

We

inspected

the

Stack

code

and

found

that

we

needed

a

method

that

has

at

least

one

argument

and

this

argument

is

not

of

the

integer

type.

We

added

a

public

method

push(double

d)

to

the

Stack

class.

Then

generated

inputs

can

achieve

aspectual

branch

coverage..

NonNegative

has

a

call

join

point;

therefore,

without

using

wrapper

classes,

no

aspectual

branch

coverage

was

achieved

by

generated

test

inputs

(there

were

no

interactions

from

the

methods

of

the

base

class

to

the

aspect

methods).

Then

we

fed

the

gener-ated

wrapper

class

to

test-generation

tools

and

the

generated

test

inputs

achieved

aspectual

branch

coverage

and

interaction

coverage.

Our

tool

reported

that

the

true

branch

of

the

following

aspect

code

in

NonNegative

(shown

in

Figure

is

not

covered:.

We

inspected

the

generated

test

code

and

found

that

test

code

contained

method

invocations

of

which

push

negative

elements

into

the

stack.

Then

we

further

inspected

the

method

body

of

push

and

found

that

the

uncovered

branch

is

due

to

the

first

line

of

push:.

After

we

commented

out

this

line,

which

prevents

negative

elements

from

being

finally

pushed

into

the

stack,

the

generated

test

inputs

achieved

aspectual

branch

coverage..

PushCount

has

a

public

non-advice

method

getAllStackCount;

therefore,

without

using

wrapper

classes,

no

coverage

of

getAllStackCount

can

be

achieved

by

generated

test

inputs.

After

using

the

wrapper

class,

we

achieve

aspectual

branch

coverage..

Instrumentation

has

two

call

join

points

and

no

aspectual

branch

coverage

was

achieved

by

generated

test

inputs

for

the

woven

class

(without

using

a

wrapper

class).

After

we

fed

the

generated

wrapper

class

to

test-generation

tools,

the

generated

test

inputs

achieved

aspectual

branch

coverage

and

interaction

coverage..

NullCheck

has

around

advice

for

those

methods

whose

returns

are

not

void

and

not

of

primitive

types:.

Object

around():

execution(Object+

Object

lRetVal

proceed();

if

(lRetVal

null)

System.err.println(

"Detected

return

value

after

calling

thisJoinPoint.getSignature().toShortString()

in

file

thisJoinPoint.getSourceLocation().getFileName()

at

line

thisJoinPoint.getSourceLocation().getLine());

return

lRetVal;

To

provide

a

base

class

for

NullCheck,

we

adapt

the

Stack

class

in

Figure

by

changing

the

int

type

to

Integer.

Then

both

the

pop

and

iterator

methods

of

Stack

are

advised

by

NullCheck.

Using

wrapper

classes

does

not

offer

further

help

in

test

generation.

The

generated

test

inputs

achieved

aspectual

branch

coverage.

Our

tool

reported

that

a

call

site

(in

Stack's

iterator

method)

of

the

around

advice

in

NullCheck

is

not

covered.

Similar

to

what

we

did

for

NonNegativeArg,

we

declared

iterator

as

a

public

method

and

then

the

generated

test

inputs

could

achieve

interaction

coverage

and

but

aspectual

branch

coverage.

We

found

that

the

false

branch

of

(lRetVal

null)

is

not

covered,

because

return

values

of

either

pop

or

iterator

can

never

be

null.

We

modified

Stack

to

be

able

to

store

any

object

type

instead

of

just

Integer

and

then

pop

can

return

an

element

that

is

null.

Given

the

new

base

class,

Jtest

and

Rostra

generated

test

inputs

that

achieved

aspectual

branch

coverage.

One

remaining

uncovered

branch,

the

false

branch

of

(lRetVal

null)

in

the

inlined

around

advice

for

iterator,

is

infeasible

to

cover

because

iterator's

return

value

can

never

be

null..

Telecom

has

one

key

base

class

Connection.

There

are

two

aspects:

Timing

and

Billing.

The

Timing

aspect

records

the

phone

connection

time

and

the

Billing

aspect

uses

the

connection

time

to

bill

the

dialer.

Either

Timing

or

Billing

aspect

declares

two

pieces

of

after

advice

with

call

join

points.

Both

aspects

also

declare

intertype

fields

and

methods.

Without

using

a

wrapper

class,

branches

within

advice

with

call

join

points

cannot

be

covered.

In

addition,

because

Timing

and

Billing

define

three

public

non-advice

methods,

before

using

wrapper

classes,

these

three

methods

were

not

covered.

After

using

wrapper

classes,

generated

test

inputs

achieved

aspectual

branch

coverage

and

interaction

coverage..

BusinessRuleImpl

has

a

base

class

of

SavingsAccount

and

two

aspects:

MinimumBalanceRuleAspect

and

OverdraftProtectionRuleAspect.

MinimumBalanceRuleAspect

defines

a

piece

of

before

advice

for

method

execution

and

OverdraftProtectionRuleAspect

defines

another

piece

of

before

advice

for

method

execution.

Our

tool

reported

that

generated

test

inputs

achieved

only

aspectual

branch

coverage.

We

inspected

those

uncovered

branches

and

found

that

some

arguments

generated

by

Jtest

are

not

sufficient.

For

example,

MinimumBalanceRuleAspect

required

the

minimum

balance

to

be

but

the

Jtest-generated

arguments

for

SavingsAccount's

credit

method

are

only

or

after

they

are

invoked

even

for

three

iterations,

SavingsAccount

still

could

not

get

sufficient

funds

for

withdrawal.

We

improved

Jtest-generated

method

arguments

by

adding

some

new

arguments

to

improve

the

aspectual

branch

coverage

to

but

we

could

not

easily

improve

test

generation

to

exercise

two

uncovered

branches

because

the

complexity

of

necessary

conditions

for

covering

these

two

branches

is

beyond

our

capability.

A

more

sophisticated

testgeneration

tool

is

needed

for

generating

tests

to

cover

them..

StateDesignPattern

has

a

QueueStateAspect

aspect

that

declares

three

pieces

of

after

advice

for

method

calls.

Because

these

advised

call

sites

already

exist

in

the

code

base,

using

wrapper

classes

does

not

offer

further

help

in

test

generation.

Our

tool

reported

that

generated

test

inputs

achieved

aspectual

branch

coverage,

with

one

branch

uncovered.

We

inspected

the

uncovered

branch,

which

indicated

that

the

base

class

Queue

has

not

reached

the

full

state

yet.

We

therefore

increased

Rostra's

maximum

iteration

number

and

when

the

number

was

four,

we

achieved

aspectual

branch

coverage..

DCM

has

an

Metrics

aspect

that

uses

around

and

after

advice

for

method

executions.

Our

tool

reported

aspectual

branch

coverage.

We

found

that

seven

aspect

methods

are

uncovered,

two

of

which

are

uncovered

advice

methods.

By

inspecting

these

advice

method's

join

point

definitions,

we

found

they

advise

main

method

in

the

base

class

but

our

base

class

did

not

have

a

main

method.

We

constructed

a

main

method

for

the

base

class

and

then

six

of

these

seven

originally

uncovered

methods

were

covered.

The

aspectual

branch

coverage

was

increased

from

to

By

inspecting

the

remaining

uncovered

branches,

many

of

them

were

due

to

that

the

value

of

Metrics's

static

field

dumpinterval

was

never

but

its

value

is

preset

as

and

could

not

be

updated

through

code

interface

(that

is,

these

branches

cannot

be

covered

inherently

unless

we

modify

the

code

under

test).

For

other

uncovered

branches,

we

could

not

easily

improve

test

generation

to

cover

them.

A

more

sophisticated

test-generation

tool

is

needed

for

generating

tests

to

cover

them..

ProdLine

has

base

classes

that

are

a

set

of

empty

classes.

Our

testing

focuses

on

one

of

these

classes:

Vertex.

The

woven

class

contains

intertype

fields

that

are

declared

by

seven

aspects.

It

also

contains

four

methods

that

are

declared

by

two

aspects:

DFS

and

Undirected,

which

are

developed

for

depth-first

search

and

undirected

graph,

respectively.

Note

that

our

coverage

measurement

tool

measures

all

aspect

classes

loaded

at

class

loading

time.

Many

other

loaded

aspect

classes

than

DFS

and

Undirected

were

loaded

and

thus

measured.

Our

tool

reported

low

aspectual

branch

coverage

and

interaction

coverage

We

inspected

these

uncovered

branches

or

call

sites

and

found

that

many

of

them

LoD

has

a

Check

aspect

that

declares

two

pieces

of

after

advice

for

checking

the

method

calls.

There

are

two

other

aspects

Percflow

and

Pertarget

for

collecting

calling

context

through

the

use

of

percflow,

pertarget,

and

cflow.

Our

tool

reported

that

generated

test

inputs

achieved

aspectual

branch

coverage.

After

we

used

a

wrapper

class,

the

aspectual

branch

coverage

was

increased

to

the

increase

is

due

to

the

increase

of

call

depths

affecting

LoD's

behavior,

rather

than

our

original

intention

of

the

wrapper

mechanism.

We

further

inspected

uncovered

advice

and

found

a

piece

of

uncovered

advice

advises

a

main

method

and

another

piece

advises

Java

library

method

calls.

We

constructed

a

main

method

in

the

base

class

and

put

some

call

sites

of

Java

library

methods

in

the

main

method.

Then

the

generated

test

inputs

achieved

aspectual

branch

coverage.

We

could

not

easily

improve

base-class

construction

or

test

generation

for

the

remaining

uncovered

branches.

Besides

a

more

sophisticated

test-generation

tool,

a

sophisticated

base-class

construction

tool

is

needed

for

helping

further

improve

the

aspectual

branch

coverage.

Souter

et

al.

developed

a

test

selection

technique

based

on

concerns.

A

concern

is

the

code

associated

with

a

particular

maintenance

task.

An

aspect

in

AspectJ

programs

can

be

seen

as

a

concern.

To

reduce

the

space

and

time

cost

of

running

tests

on

instrumented

code,

they

proposed

to

instrument

only

the

concerns

for

collecting

runtime

information.

They

also

proposed

to

select

or

prioritize

tests

for

the

selected

concerns.

In

particular,

they

select

a

test

if

the

test

covers

a

concern

that

has

not

been

been

exercised

by

previously

selected

tests.

Zhou

et

al.

also

used

the

same

technique

for

selecting

tests

for

an

aspect.

These

two

test

selection

approaches

assume

that

there

already

exist

a

set

of

tests

for

an

AspectJ

program

(or

just

for

the

base

classes

in

the

AspectJ

program),

whereas

Aspectra

focuses

on

automatically

generating

test

inputs

for

an

AspectJ

program

and

using

coverage

measurement

results

to

guide

developers

to

improve

test

coverage.

Our

aspectual

branch

coverage

or

interaction

coverage

can

also

be

used

to

select

tests:

if

a

test

input

covers

at

least

one

new

aspectual

branch

or

interaction,

the

test

input

is

selected

for

inspection

when

there

are

no

test

oracles

for

generated

test

inputs.

Our

aspectual

branch

coverage

or

interaction

coverage

defines

coverage

in

the

granularity

of

branches

or

call

sites,

whereas

Souter

et

al.

or

Zhou

et

al.

define

coverage

in

a

coarser

granularity

of

whole

aspects..

Xu

et

al.

presented

a

specification-based

testing

approach

for

aspect-oriented

programs.

The

approach

creates

aspectual

state

models

by

extending

the

existing

FREE

(Flattened

Regular

Expression)

state

model,

which

was

originally

proposed

for

testing

objectoriented

programs.

Based

on

the

model,

they

developed

two

techniques

for

testing

aspect-oriented

programs.

The

first

technique

transforms

an

aspectual

state

model

to

a

transition

tree

and

generates

tests

based

on

the

tree.

The

second

technique

constructs

and

searches

an

aspect

flow

graph

for

achieving

statement

coverage

and

branch

coverage.

Their

work

focuses

on

testing

aspect-oriented

programs

based

on

abstract

state

models,

whereas

Aspectra

focuses

mainly

on

automatically

generating

test

inputs

based

on

implementations..

Alexander

et

al.

developed

a

fault

model

for

aspect-oriented

programming,

including

six

types

of

faults

that

may

occur

in

aspectoriented

systems.

Their

fault

model

provides

useful

guidance

in

developing

testing

coverage

tools

for

aspect-oriented

programs,

whereas

Aspectra

proposes

an

automated

approach

for

generating

tests

to

achieve

structural

coverage.

Recently,

Nathan

and

Alexander

proposed

another

fault

model

that

results

from

maintenance

problems

for

aspect-oriented

programs.

They

also

reported

their

evaluation

of

AspectJ's

ability

to

distribute

class

files

containing

woven

concerns

and

to

reweave

them

later.

Although

their

fault

model

may

lead

to

a

better

understanding

of

maintenance

issues

inherent

in

aspect-oriented

software,

it

still

does

not

provide

a

testing

solution

for

aspect-oriented

programs..

Zhao

proposed

a

data-flow-based

unit

testing

approach

for

aspect-oriented

programs.

For

each

aspect

or

class,

the

approach

performs

three

levels

of

testing:

intra-module,

inter-module,

and

intra-aspect

or

intra-class

testing.

His

work

focused

on

unit

testing

of

aspect-oriented

programs

based

on

data

flow,

whereas

Aspectra

focuses

on

automatically

generating

test

inputs

for

AspectJ

programs..

Rajan

and

Sullivan

presented

an

approach

to

expressing

and

automating

test

adequacy

criteria

relative

to

crosscutting

concerns

using

aspect-oriented

languages.

Their

approach

represents

tester

intentions

within

source

code

in

an

explicit

and

abstract

way.

They

also

provided

a

white-box

join

point

model

and

a

generalized

action

framework

to

support

white-box

testing

tools.

Their

work

focuses

on

using

aspect-oriented

languages

to

support

general

and

automated

test

adequacy

analysis,

whereas

Aspectra

focuses

on

generating

test

inputs

for

AspectJ

programs

and

using

structural

coverage

measurement

results

to

guide

how

to

improve

test

coverage..

Rinard

et

al.

proposed

a

classification

system

for

aspectoriented

programs

and

developed

a

static

analysis

to

support

automatic

classification.

Their

system

characterizes

the

interactions

between

advice

and

advised

methods

based

on

field

accesses.

Developers

can

use

the

classification

system

and

analysis

to

structure

their

understanding

of

the

aspect-oriented

programs.

Aspectra

defines

and

measures

the

coverage

of

interactions

between

advised

methods

and

aspect

methods

in

the

granularity

of

methods.

Our

implementation

of

Aspectra

uses

bytecode

rewriting

techniques

based

on

the

Byte

Code

Engineering

Library

(BCEL)

(instead

of

code

instrumentation

by

using

aspect-oriented

paradigm).

We

have

automated

the

wrapper

synthesis

by

adapting

a

package

in

the

Apache

Avalon

Framework

(also

based

on

BCEL);

this

package

generates

wrapper

classes

for

Java

containers.

Given

the

bytecode

of

a

woven

class

as

well

as

aspect

classes,

our

tool

automatically

synthesizes

a

wrapper

class

in

the

form

of

bytecode..

We

leverage

Jtest

and

our

previously

developed

Rostra

tool

to

generate

test

inputs.

Rostra

uses

Java

reflection

mechanisms

to

generate

and

execute

new

tests

online.

In

the

end

of

test

generation,

Rostra

exports

the

test

inputs

generated

after

each

iteration

to

a

JUnit

test

class

code

More

implementation

de-tails

of

Rostra

can

be

found

elsewhere

We

have

also

automated

the

measurement

of

aspectual

branch

coverage

and

interaction

coverage.

Our

tool

reports

the

percentage

numbers

for

branch

coverage

or

interaction

coverage.

In

addition,

our

tool

reports

the

details

of

covered

branches

or

call

sites

as

well

as

uncovered

branches

or

call

sites.

The

details

of

a

branch

include

the

corresponding

conditional,

its

line

number

in

the

source

code,

and

the

true

or

false

branch

of

the

conditional.

The

details

of

a

call

site

include

its

line

number

in

the

source

code

and

the

corresponding

caller

and

callee

method

names

in

the

woven

bytecode.

To

facilitate

human

inspection

of

these

names,

our

future

work

plans

to

keep

the

mapping

between

a

method

name

in

the

woven

bytecode

and

the

corresponding

method

name

in

the

source

code,

and

present

to

developers

also

the

method

name

in

the

source

code..

During

class

loading

time,

our

tool

dynamically

determines

whether

a

class

is

an

aspect

class

by

inspecting

the

names

of

its

methods,

because

the

ajc

compiler

gives

special

names

for

advice.

We

also

similarly

detect

inlined

around

advice

in

base

classes

based

on

its

method

name.

We

scan

bytecode

to

identify

branches

and

then

insert

probes

at

branching

points

for

collecting

branch

coverage

information.

We

also

scan

the

bytecode

to

identify

call

sites

and

classify

them

into

different

types

of

interactions,

and

then

also

insert

probes

for

collecting

interaction

coverage

information.

O O O O O O O O O O B O B I I O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O B O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Perceived quality of multimedia educational content: A cognitive style approach Abstract Cognitive styles influence the way how humans process information, with previous research demonstrating that they have significant effects on student learning in multimedia environments. On the other hand, the perceptual quality of the human multimedia experience is notoriously difficult to measure. In this paper, we report the results of an empirical study, which investigated the relationship between user cognitive styles and perceptual multimedia quality, in which users had the possibility to specify their desired Quality of Service settings -in terms of frame rates and color depth. Results show that whilst color choice is impacted by a participant's cognitive style, such Quality of Service parameters do not significantly affect perceived multimedia quality, and that users do not necessarily choose optimum presentation settings to enhance their perceived enjoyment and assimilation of multimedia informational content. Multimedia technologies play an increasingly important role in education [1] [2] [3] . However, whilst adaptive multimedia approaches in e-learning abound, very few of them [4, 5] address perceptual quality issues. Research in this area has highlighted several key concerns, one of which deals with the effectiveness of multimedia presentations [6] . To this end, an important measure of the effectiveness of a multimedia presentation is the user experience captured in terms of enjoyment and information assimilation. Key is the issue of the quality of the multimedia presentation.. In a distributed multimedia environment, the issue of quality takes on a new dimension, as not only it is in the eye of the beholder, but is also affected by the underlying communication system. Accordingly, in our perspective, quality has two main facets: of service and of perception. The former, Quality of Service (QoS), illustrates the technical side of computer networking and represents the performance properties that the underlying network is able to provide. The latter, Quality of Perception (QoP), characterizes the perceptual experience of the user when interacting with multimedia applications. Whilst the quality delivered by communication networks has traditionally been measured using QoS metrics, we believe that, as learners are "consumers" of multimedia educational applications, it is their opinions of and experiences with the quality of multimedia material that ultimately measure the success (or, indeed, failure) of such applications to successfully deliver edutainment (i.e., combined educational and entertainment) material. Moreover, when this delivery is done over Wide Area Networks such as the World Wide Web ("the Web"), transmission of multimedia data has to accommodate not only users' subjective preferences, but also fluctuating networking environments.. The question also arises of whether distributed multimedia presentations can accommodate individual preferences. Previous research has indicated that users with different characteristics have different perceptions of multimedia presentations [7] . In particular, different cognitive style groups benefit from different types of multimedia presentation. Empirical examination of cognitive style impact is eminently necessary, because such an endeavor has the potential to offer concrete prescriptions for developing user-centered systems that can match the particular needs of each cognitive style group.. In this paper, we present the results of an empirical study that explored the relationship between user cognitive styles and QoP, when multimedia is presented with varying levels of QoS parameters. The results of this study can help designers to understand how to choose appropriate multimedia presentation parameters to match the preferences of users with different cognitive styles, and in so doing, make better use of scarce networking resources such as bandwidth. Accordingly, this paper is structured as follows: Sect. 2 presents a review of issues related to QoP and cognitive styles research; the methodological design of our empirical work is then detailed in Sect. 3, while results are described and discussed in Sect. 4. Lastly, conclusions are drawn and possibilities for future work are identified in Sect. 5. In this paper, we have presented the results of an empirical study which examined the influence of user cognitive styles and QoS preferences (in terms of presentation frame rate and color depth choices) on perceptual multimedia quality. Results accordingly suggest that frame rate variations and color choices do not, irrespective of cognitive style, significantly impact upon perceptual multimedia quality, a finding of particular interest in bandwidth-constrained environments. Moreover, Intermediate users were shown to have largely versatile color choices.. Nonetheless, our results indicate that the perception of multimedia quality by the end user does not seem to be affected by the underlying QoS with which that multimedia was delivered, nor by the particular cognitive style of the user. This has a two-fold implication-the first is that in bandwidth constrained environments, user QoP is largely unaffected by the presentation quality. Therefore, this offers both scope and promise. Scope-for more efficient utilization of resources, since playing back a multimedia clip at less than full blown quality is likely not to be noticed by users, or, even if it is, it is not likely to significantly affect his/her perceptual quality experience. Promise-for it seems to suggest that personalization, though undoubtedly an important issue in the advanced communication systems of today and of the future, need not necessarily consider the cognitive style dimension in the tailoring of multimedia quality.. The second implication of our study is that our findings show that, even when given a choice, the choices made by users do not necessarily lead to a better perceptual experience, if one considers informational assimilation as part of this. However, whether it is psychologically more important for users to be given the opportunity to make decisions regarding quality preferences is still an open question as far as multimedia is concerned.. Lastly, although we recognize that we have only examined a reduced subset of multimedia content and that, for instance, more clips with dynamic features could have been included in our sample, we cannot ignore the relatively low information assimilation scores associated with a subset of the multimedia content of our experiments. That this happened in spite of users being told that the information assimilation aspect of their experience was going to be evaluated, leads us to conclude that further work should also involve the influence of task and content on the subjective multimedia experience. This is a direction we are currently engaged in and will provide a valuable cornerstone in our efforts to build integrated multimedia communication systems information.

O O O B O O O O O O O B I O O O O O O O O O O O O O O O O O O O O B O O O O O O B I O O O B O O O O O O O O O O O O O O O O O O O O O O O B I O O B O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O B O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O


Discovery and Verification of Neighbor Positions in Mobile Ad Hoc Networks Abstract-A growing number of ad hoc networking protocols and location-aware services require that mobile nodes learn the position of their neighbors. However, such a process can be easily abused or disrupted by adversarial nodes. In absence of a priori trusted nodes, the discovery and verification of neighbor positions presents challenges that have been scarcely investigated in the literature. In this paper, we address this open issue by proposing a fully distributed cooperative solution that is robust against independent and colluding adversaries, and can be impaired only by an overwhelming presence of adversaries. Results show that our protocol can thwart more than 99 percent of the attacks under the best possible conditions for the adversaries, with minimal false positive rates. L OCATION awareness has become an asset in mobile systems, where a wide range of protocols and applications require knowledge of the position of the participating nodes. Geographic routing in spontaneous networks, data gathering in sensor networks, movement coordination among autonomous robotic nodes, location-specific services for handheld devices, and danger warning or traffic monitoring in vehicular networks are all examples of services that build on the availability of neighbor position information.. The correctness of node locations is therefore an allimportant issue in mobile networks, and it becomes particularly challenging in the presence of adversaries aiming at harming the system. In these cases, we need solutions that let nodes 1) correctly establish their location in spite of attacks feeding false location information, and 2) verify the positions of their neighbors, so as to detect adversarial nodes announcing false locations.. In this paper, we focus on the latter aspect, hereinafter referred to as neighbor position verification (NPV for short). Specifically, we deal with a mobile ad hoc network, where a pervasive infrastructure is not present, and the location data must be obtained through node-to-node communication. Such a scenario is of particular interest since it leaves the door open for adversarial nodes to misuse or disrupt the location-based services. For example, by advertising forged positions, adversaries could bias geographic routing or data gathering processes, attracting network traffic and then eavesdropping or discarding it. Similarly, counterfeit positions could grant adversaries unauthorized access to location-dependent services, let vehicles forfeit road tolls, disrupt vehicular traffic or endanger passengers and drivers.. In this context, the challenge is to perform, in absence of trusted nodes, a fully distributed, lightweight NPV procedure that enables each node to acquire the locations advertised by its neighbors, and assess their truthfulness. We therefore propose an NPV protocol that has the following features:. . It is designed for spontaneous ad hoc environments, and, as such, it does not rely on the presence of a trusted infrastructure or of a priori trustworthy nodes; . It leverages cooperation but allows a node to perform all verification procedures autonomously. This approach has no need for lengthy interactions, e.g., to reach a consensus among multiple nodes, making our scheme suitable for both low-and highmobility environments; . It is reactive, meaning that it can be executed by any node, at any point in time, without prior knowledge of the neighborhood; . It is robust against independent and colluding adversaries; . It is lightweight, as it generates low overhead traffic. Additionally, our NPV scheme is compatible with state-ofthe-art security architectures, including the ones that have been proposed for vehicular networks [1] , [2] , which represent a likely deployment environment for NPV.. The rest of the paper is organized as follows: In Section 2, we review previous works, highlighting the novelty of our solution. In Section 3, we describe the system model, while the communication protocol, the objectives of the verification procedure and our main results are outlined in Section 4. The details of the NPV protocol and of verification tests are then presented in Section 5, and the resilience of our solution to different attacks is analyzed in Section 6. Finally, we provide a performance evaluation of the protocol in a vehicular scenario in Section 7, and draw conclusions in Section 8. We conclude that a single independent adversary cannot perform any successful attack against the NPV scheme. Indeed, in presence of a limited number of noncollinear neighbors in common with the verifier, a knowledgeable adversary can attempt one of the strategies outlined before, but it is tagged at most as unverifiable. When the shared neighborhood increases in size, the probability that the adversary is tagged as faulty rapidly grows to 1. Multiple independent adversaries can only harm each other, thus reducing their probability of successfully announcing a fake position.. As a conclusion on coordinated attacks, it is the nature of the neighborhood that determines the performance of the NPV scheme in presence of colluders. However, the simulation results in Section 7 show that, in realistic environments, our solution is very robust even to attacks launched by large groups of knowledgeable colluders. We presented a distributed solution for NPV, which allows any node in a mobile ad hoc network to verify the position of its communication neighbors without relying on a priori trustworthy nodes. Our analysis showed that our protocol is very robust to attacks by independent as well as colluding adversaries, even when they have perfect knowledge of the neighborhood of the verifier. Simulation results confirm that our solution is effective in identifying nodes advertising false positions, while keeping the probability of false positives low. Only an overwhelming presence of colluding adversaries in the neighborhood of the verifier, or the unlikely presence of fully collinear network topologies, can degrade the effectiveness of our NPV. Future work will aim at integrating the NPV protocol in higher layer protocols, as well as at extending it to a proactive paradigm, useful in presence of applications that need each node to constantly verify the position of its neighbors. Claudio Ettore Casetti received the graduate degree in electrical engineering from the Politecnico di Torino in 1992 and the PhD degree in electronic engineering from the same institution in 1997. He is an assistant professor in the Dipartime'nto di Elettronica at the Politecnico di Torino. He has coauthored more than 130 journal and conference papers in the fields of networking and holds three patents. His interests focus on ad hoc wireless networks and vehicular networks. He is a member of the IEEE.. Carla-Fabiana Chiasserini received the PhD degree from Politecnico di Torino in 2000. She has worked as a visiting researcher at UCSD in 1998-2003, and she is currently an associate professor at Politecnico di Torino. Her research interests include architectures, protocols, and performance analysis of wireless networks. She has published more than 190 papers in prestigious journals and leading international conferences, and she serves as an associated editor of several journals. She is a senior member of the IEEE and the IEEE Computer Society.. Panagiotis Papadimitratos received the PhD degree from Cornell University, Ithaca, New York. He was a postdoctoral fellow at Virginia Tech, Blacksburg, VA, a scientist at EPFL, Lausanne, Switzerland, and a visiting faculty member at Politecnico di Torino. He is now an associate professor in the School of Electrical Engineering at KTH, Stockholm, Sweden. His research is concerned with security and networked systems, with more than 70 related technical publications. He is a member of the IEEE.. . For more information on this or any other computing topic, please visit our Digital Library at www.computer.org/publications/dlib. We employed movement traces representing vehicle traffic over a real-world road topology. More precisely, we considered car movements within a 20 km 2 portion of the Karlsruhe urban area depicted in Fig. 8 , extracting 3 hours of vehicular mobility that reproduce mild to heavy traffic density conditions. These synthetic traces were generated using the IDM-LC model of the VanetMobiSim simulator, which takes into account car-to-car interactions, traffic lights, stop signs, and lane changes, and has been proven to realistically reproduce vehicular movement patters in urban scenarios [31] .. In our simulations, we set T max ¼ 200 ms, T jitter ¼ 50 ms, Á ¼ 1 ms and assume that CSMA/CA is used to access the wireless medium, hence messages can be lost due to collisions. Unless otherwise specified, we fix the proximity range, R, which is equal to the maximum nominal transmission range, to 250 m (resulting in an average neighborhood size of 73.4 nodes), while r ¼ 6:8 m, p ¼ 10 m, and the tolerance value m ¼ 5 m (roughly corresponding to the case of two vehicles moving at 50 km/h in opposite directions).. To evaluate the performance of our NPV, at every simulation second we randomly select 1 percent of the nodes as verifiers. Then, for each verifier, we compare the outcome of the verification tests with the actual nature of the neighbors. We consider colluding adversaries acting in groups, referred to as clusters. Note that a colluding cluster size equal to 1 corresponds to independent attacks. Also, adversaries are knowledgeable, i.e., they perfectly know the identity and location of all colluding and noncolluding neighbors, and always adopt the best attack strategy as described in Section 7.1. In the following, unless otherwise specified, adversaries amount to 5 percent of the overall nodes and are divided into clusters of five colluders each.. In the legend of the plots, C stands for correct node (e.g., the label "C faulty" refers to the probability of false positives), while M/Bas, M/Hyp, and M/Col stand for adversaries launching, respectively, the basic, hyperbola-based and collinear attack (e.g., the label "M/Bas verified" refers to the probability of false negatives due to basic attacks).. We first examine the NPV protocol performance for different values of colluding cluster sizes and R ¼ 250 m (Figs. 9a and 9b) .. The false negative/positive probability in Fig. 9a clearly shows that 1) the chance of wrong classification reaches 0.01 only for a very large adversarial cluster size, namely 10, 2) the hyperbola-based and the collinear attacks are the most threatening and 3) an attack by the colluders is most effective in passing themselves off as verified when there are at least three of them. The cluster size also affects the colluders ability to disrupt the positioning of correct nodes, which exhibit as high as a 0.4 percent chance to be tagged as faulty.. Conversely, as shown in Fig. 9b , the cluster size does not cause more correct nodes to be unverifiable, since the main reason for correct nodes to be tagged as unverifiable is the lack of noncollinear neighbors that can verify them. The chance for an adversary to be unverifiable increases with the cluster size, although it is significant only in case of collinear attacks. This is in agreement with the fact that the outcome of the collinear attack is the avoidance of a sizable number of cross-checks between the adversary and correct nodes, thus likely leading the adversary to be tagged as unverifiable.. The neighborhood size proves to play an important role, as evident in Figs. 9c and 9d where we consider a 5-colluder cluster and vary the transmission range. A small R (hence few neighbors) affects the NPV capability to correctly tag a node. Widening the transmission range with a fixed colluding cluster size significantly favors the verifier, allowing it to reach a conclusive and exact verdict on either correct or adversary nodes: the larger the R, the higher the number of cross-checks involving correct nodes in the CST. We note that, for transmission ranges larger than 300 m, we obtain false positive/negative probabilities that are smaller than 0.001. Below 150-m ranges (corresponding to an average neighborhood size of 12 nodes), such probabilities are still 0.01. Beside the impact of the cluster size and of the transmission range, it is important to understand the effect of the percentage of adversaries in the vehicular network. Thus, in Fig. 10a we fix R to 250 m and the cluster size to 5, and we show the robustness of our NPV to the density of adversaries: the probability that adversaries are verified increases ever so slightly with their density. The highest effect is on the probability of correct nodes being tagged as faulty, which however reaches its highest value (0.1) only for 30 percent of adversaries in the network. A further effect of the growing presence of adversaries, as shown in Fig. 10b , is the unverifiable tag being slapped onto more correct nodes. A final observation can be made looking at the false positive/negative probability as the positioning error varies (Figs. 10c and 10d) . Interestingly, for any positioning error different from 0, the metrics are only marginally affected.. Finally, we further increase the level of detail of our analysis and study the advantage obtained by adversaries that perform a successful attack against the NPV protocol. Such an adversarial gain is expressed in terms of spatial displacement, i.e., difference of position between the real and fraudulently advertised locations of the successful attacker: clearly, a larger displacement range implies a higher freedom of movement, which, in turn, enables potentially more dangerous actions against the system. The results in Fig. 11a are broken down based on the type of attack launched by the successful adversary, and are limited to the impact of the transmission range, since the other parameters did not show significant influence on the displacement of successful attackers.. We can observe that successful collinear attacks yield small advantage for adversaries, who are forced to announce positions quite close to their real locations. Moreover, we recall that these attacks constrain adversaries to advertise fake positions along a precise axis, thus further limiting their freedom of movement. We can conclude that collinear attacks, typically those with the highest chances of success as previously discussed, are also those resulting in the smallest gain for the adversaries. Conversely, basic attacks allow the largest average displacements, but we showed that they have extremely low success probability. The hyperbola-based attacks appear then to be the most dangerous ones, if the displacement gain is taken into consideration. However, such a gain becomes significant only for large transmission ranges, in presence of which we already observed that the actual success probability of the attacks becomes negligible.. Finally, we comment on the overhead introduced by our scheme. The NPV protocol generates at most 2n þ 2 messages for one execution initiated by a verifier with n communication neighbors. Also, NPV messages are relatively small in size: with SHA-1 hashing and ECDSA-160 encryption [27] , the length of signatures is 21 bytes (with coordinates compression). Assuming that messages include headers with 4-byte source and destination identifiers and 1-byte message type field, POLL, REPLY, and REVEAL are 26, 71, and 67 bytes in size, respectively. The REPORT length depends on the quantity of common neighbor data it carries, amounting to 4 bytes per shared neighbor: information on more than 360 neighbors can thus fit in a single IP packet. Fig. 11b portrays the traffic induced on the network by one instance of the NPV protocol. The plot only accounts for transmission range variations since, once more, the other parameters do not have an impact on the overhead. We can observe that security comes at a cost, since the traffic load of the NPV protocol is higher than that of a basic nonsecure neighbor position discovery, consisting of only one poll and associated position replies from neighbors. More precisely, the NPV protocol overhead is comparable to that of the nonsecure discovery for smaller transmission ranges, while the difference tends to increase for larger ranges. However, the cost of the NPV protocol is affordable in absolute terms, since one run requires just a few tens of kbytes to be exchanged among nodes, even in presence of dense networks and large transmission ranges. Note that the results above do not take into account the overhead induced by the distribution of certificates, as it is out of the scope of this work (the interested reader can refer to [26] ).. Summary. Given that we assumed the best possible conditions for the adversaries, the above results prove our NPV to be highly resilient to attacks. Indeed, we observed typical probabilities of false positives/negatives below 1 percent, while that of a node being tagged as unverifiable is below 5 percent. Moreover, we showed that a significant portion of the successful attacks yields small advantage to the adversaries in terms of displacement. Finally, the overhead introduced by the NPV protocol is reasonable, as it does not exceed a few tens of kbytes even in the most critical conditions. Although the literature carries a multitude of ad hoc security protocols addressing a number of problems related to NPV, there are no lightweight, robust solutions to NPV that can operate autonomously in an open, ephemeral environment, without relying on trusted nodes. Below, we list relevant works and highlight the novelty of our contribution. For clarity of presentation, we first review solutions to some NPV-related problems, such as secure positioning and secure discovery, and then we discuss solutions specifically addressing NPV.. Securely determining own location. In mobile environments, self-localization is mainly achieved through Global Navigation Satellite Systems, e.g., GPS, whose security can be provided by cryptographic and noncryptographic defense mechanisms [3] . Alternatively, terrestrial specialpurpose infrastructure could be used [4] , [5] , along with techniques to deal with nonhonest beacons [6] . We remark that this problem is orthogonal to the problem of NPV. In the rest of this paper, we will assume that devices employ one of the techniques above to securely determine their own position and time reference.. Secure neighbor discovery (SND) deals with the identification of nodes with which a communication link can be established or that are within a given distance [7] . SND is only a step toward the solution we are after: simply put, an adversarial node could be securely discovered as neighbor and be indeed a neighbor (within some SND range), but it could still cheat about its position within the same range. In other words, SND is a subset of the NPV problem, since it lets a node assess whether another node is an actual neighbor but it does not verify the location it claims to be at. SND is most often employed to counter wormhole attacks [8] , [9] , [10] ; practical solutions to the SND problem have been proposed in [11] , while properties of SND protocols with proven secure solutions can be found in [12] , [13] .. Neighbor position verification was studied in the context of ad hoc and sensor networks; however, existing NPV schemes often rely on fixed [14] , [15] or mobile [16] trustworthy nodes, which are assumed to be always available for the verification of the positions announced by third parties. In ad hoc environments, however, the pervasive presence of either infrastructure or neighbor nodes that can be aprioristically trusted is quite unrealistic. Thus, we devise a protocol that is autonomous and does not require trustworthy neighbors.. In [17] , an NPV protocol is proposed that first lets nodes calculate distances to all neighbors, and then commends that all triplets of nodes encircling a pair of other nodes act as verifiers of the pair's positions. This scheme does not rely on trustworthy nodes, but it is designed for static sensor networks, and requires lengthy multiround computations involving several nodes that seek consensus on a common neighbor verification. Furthermore, the resilience of the protocol in [17] to colluding attackers has not been demonstrated. The scheme in [18] suits static sensor networks too, and it requires several nodes to exchange information on the signal emitted by the node whose location has to be verified. Moreover, it aims at assessing not the position but whether the node is within a given region or not. Our NPV solution, instead, allows any node to validate the position of all of its neighbors through a fast, one-time message exchange, which makes it suitable to both static and mobile environments. Additionally, we show that our NPV scheme is robust against several different colluding attacks. Similar differences can be found between our work and [19] .. In [20] , the authors propose an NPV protocol that allows nodes to validate the position of their neighbors through local observations only. This is performed by checking whether subsequent positions announced by one neighbor draw a movement over time that is physically possible. The approach in [20] forces a node to collect several data on its neighbor movements before a decision can be taken, making the solution unfit to situations where the location information is to be obtained and verified in a short time span. Moreover, an adversary can fool the protocol by simply announcing false positions that follow a realistic mobility pattern. Conversely, by exploiting cooperation among nodes, our NPV protocol is 1) reactive, as it can be executed at any instant by any node, returning a result in a short time span, and 2) robust to fake, yet realistic, mobility patterns announced by adversarial nodes over time.. The scheme in [21] exploits Time-of-Flight (ToF) distance bounding and node cooperation to mitigate the problems of the previous solutions. However, the cooperation is limited to couples of neighbor nodes, which renders the protocol ineffective against colluding attackers.. To our knowledge, our protocol is the first to provide a fully distributed, lightweight solution to the NPV problem that does not require any infrastructure or a priori trusted neighbors and is robust to several different attacks, including coordinated attacks by colluding adversaries. Also, unlike previous works, our solution is suitable for both low and high mobile environments and it only assumes RF communication. Indeed, non-RF communication, e.g., infrared or ultrasound, is unfeasible in mobile networks, where non-line-of-sight conditions are frequent and device-todevice distances can be in the order of tens or hundreds of meters. An early version of this work, sketching the NPV protocol and some of the verification tests to detect independent adversaries, can be found in [22] .. nodes can perform Time-of-Flight-based RF ranging with a maximum error equal to r . As discussed in [17] , this is a reasonable assumption, although it requires modifications to off-the-shelf radio interfaces; also, promising techniques for precise ToF-based RF ranging have been developed [24] .. We assume that node positions do not vary significantly during a protocol execution, since a complete message exchange takes no more than a few hundreds of milliseconds. The relative spatial movements of the nodes during such a period are taken into account through the tolerance value m .. Nodes carry a unique identity 2 and can authenticate messages of other nodes through public key cryptography [27] . In particular, we assume that each node X owns a private key, k X , and a public key, K X , as well as a set of one-time use keys {k 0 X ; K 0 X }, as proposed in emerging architectures for secure and privacy-enhancing communication [2] , [25] . Node X can encrypt and decrypt data with its keys and the public keys of other nodes; also, it can produce digital signatures (Sig X ) with its private key. We assume that the binding between X and K X can be validated by any node, as in state-of-the-art secure communication architectures [2] , [26] .. Nodes are correct if they comply with the NPV protocol, and adversarial if they deviate from it. As authentication essentially thwarts external adversaries, we focus on the more powerful internal ones, i.e., nodes that possess the cryptographic material to participate in the NPV and try to exploit it, by advertising arbitrarily erroneous own positions or inject misleading information. Internal adversaries cannot forge messages on behalf of other nodes whose keys they do not have. Thus, attacks against the cryptosystem are not considered, as correct implementation of cryptographic primitives makes them computationally infeasible.. We further classify adversaries into: knowledgeable, if at each time instant they know positions and (temporary) identities of all their communication neighbors, and unknowledgeable, otherwise; independent, if they act individually, and colluding, if they coordinate their actions.

O O O O O O O B I I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Efficient algorithms for incremental utility mining Temporal data mining is the activity of finding interesting correlations or patterns in large temporal data sets. On the other hand, utility mining aims at identifying the itemsets with high utilities. In 2006, Tseng et al. introduced the temporal utility mining which is extended from both temporal association rule mining and utility mining. In this study, we investigated the incremental utility mining which can identify all high temporal utility itemsets in a specified time period on an incremental transaction database. Two efficient algorithms, Incremental Utility Mining (IUM) and Fast Incremental Utility Mining (FIUM), were proposed. The experimental results also showed that both algorithms are efficient. In traditional association rule mining model, the products of transactions are treated as items. Association rule mining identifies relationship among a set of items frequently purchased together. Apriori [1] is the most famous algorithm for finding association rules. Some researchers continued to improve it afterward, such as [2] , [3] , [4] , [5] , [6] .. However, in many applications, mining temporal association patterns from the most recent data is also important. The concept of incremental mining was introduced by Cheung et al. [7] in 1996. FUP Algorithm was proposed to solve such problem. Afterward, there were many researches on incremental sequential pattern mining aimed at the cases of incremental databases [8] , [9] , [10] , [11] , [12] , [13] .. Utility mining [14] is the research which discusses the quantity of items. Utility is defined as how useful or valuable an item is. Utility mining identifies high utility itemsets that own a large portion of the total utility in the transaction database. By combining the concept of temporal data mining and utility mining, Tseng et al. [15] introduced THUI-Mine algorithm for finding temporal high utility itemsets from data streams.. In this paper, we investigated the incremental utility mining which can identify all high temporal utility itemsets in a specified time period on an incremental transaction database. This study proposed two novel algorithms, Incremental Utility Mining (IUM) Algorithm and Fast Incremental Utility Mining (FIUM) Algorithm, which can discover all high temporal utility itemsets.. The rest of this paper is organized as follows. Section 2 overviews the related works. Section 3 describes the proposed algorithms. Performance studies are given in Section 4. Finally, we conclude in Section 5 with a summary of our work. The study proposed novel incremental utility mining methods, IUM-Algorithm, and FIUM-Algorithm, which can discover temporal high utility itemsets. The algorithms can efficiently identify all high temporal utility itemsets that users will be interested in particular periods when the new transaction data are added into the original transaction database. The algorithm not only can find the temporal high utility itemsets for particular time periods, but also can find the high utility itemsets for the entire transaction database. In fact, the high temporal utility itemsets are the candidates of high utility itemsets.. Incremental utility mining strives for finding high temporal utility itemsets that drive large portions of utility in a particular period. However, it does not indicate how often such itemsets appear in the period. In the future, the temporal utility-frequent mining can be more investigated.

O O O O B I B I I O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O B I O O O O O O O O O O B I O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O B I O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O B I I O B I O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Approximating Optimal Binary Decision Trees We give a (ln n + 1)-approximation for the decision tree (DT) problem. An instance of DT is a set of m binary tests T = (T 1 , . . . , T m ) and a set of n items X = (X 1 , . . . , X n ). The goal is to output a binary tree where each internal node is a test, each leaf is an item and the total external path length of the tree is minimized. Total external path length is the sum of the depths of all the leaves in the tree. DT has a long history in computer science with applications ranging from medical diagnosis to experiment design. It also generalizes the problem of finding optimal averagecase search strategies in partially ordered sets which includes several alphabetic tree problems. Our work decreases the previous best upper bound on the approximation ratio by a constant factor. We provide a new analysis of the greedy algorithm that uses a simple accounting scheme to spread the cost of a tree among pairs of items split at a particular node. We conclude by showing that our upper bound also holds for the DT problem with weighted tests.

O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


A lower bound for multicast key distribution With the rapidly growing importance of multicast in the Internet, several schemes for scalable key distribution have been proposed. These schemes require the broadcast of H(log n) encrypted messages to update the group key when the nth user joins or leaves the group. In this paper, we establish a matching lower bound (Independently, and concurrently, Richard Yang and Simon Lam discovered a similar bound with slightly different properties and proofs. An earlier version of our paper appeared in Infocom 2001 while their result appears in [R. Yang, S. Lam, A secure group key management communication lower bound, Technical Report TR-00-24, Department of Computer Sciences, UT Austin, July 2000, revised September 2000].), thus showing that H(log n) encrypted messages are necessary for a general class of key distribution schemes and under different assumptions on user capabilities. While key distribution schemes can exercise some tradeoff between the costs of adding or deleting a user, our main result shows that for any scheme there is a sequence of 2n insertion and deletions whose total cost is X(n log n). Thus, any key distribution scheme has a worstcase cost of X(log n) either for adding or for deleting a user. Many distributed applications-such as interactive games, teleconferencing, and chat rooms-use a group paradigm. While such applications using groups can be implemented over point-to-point communication links, there are advantages to using multicast or broadcast as the underlying communications primitive.. A broadcast channel such as a satellite allows a sender to communicate with every user that can listen to the channel using a single broadcast message. With n users, broadcast can be n times cheaper than sending n separate unicast messages. The notion of broadcasting extends to a network of point-to-point links, such as the Internet where the routers can make extra copies of a message for all downstream links to which the message is intended. Further, broadcast generalizes to multicast where a message can be sent to a subset of all the Internet nodes.. Multicast is easily accomplished by assigning separate multicast addresses for each subset that wishes to communicate, and creating a separate Steiner tree [7] for each such subset. Despite the slowness of initial deployment, Internet multicast [7] is likely to become an important and well-used Internet paradigm.. The original Internet protocols paid little attention to secure communication, but commercial success has lead to many proposals for Internet security (e.g., IPsec [18] ) that allow unicast messages to travel encrypted. Security concerns for IP multicast are even greater, due to the nature and distribution of the traffic. When a multicast message is sent to one station on say a satellite link, other stations in the range of the satellite can listen to the packets. If the listening stations have not paid for the service, then cryptographic techniques must be used to prevent unauthorized listeners from using the service.. This paper is about the problem of maintaining secrecy for multicast communication using any multicast or broadcast communication primitive, including the Internet multicast protocols as an important special case. Although there are proposals for group security that use sophisticated cryptographic techniques [16] , we concentrate on secrecy by encrypted communication using simple and efficient private key techniques (e.g., DES) for group data encryption. Since secret key techniques are well studied and widely deployed, the main problem is key distribution: sending keys to all the group recipients in a scalable fashion.. The scalable key distribution problem is interesting because a number of applications can use large multicast groups that are also highly dynamic (i.e., users can be added or deleted frequently). For example, distributed war gaming and teleconferencing [19] , applications can have thousands of users at any time with ten percent of the users changing over a period of one minute, and a constraint that users be added or dropped within a second.. Simple extensions of unicast key distribution protocols (e.g., [10] ) take linear time to add or remove a user, which would be problematic for the dynamic scenarios described above. Recent proposals [20, 6, 19] introduced a Key Graph scheme for scalable key distribution that takes O(log n) messages to add to or delete from a group of n users. We describe the Key Graph scheme in the next section. The main question that we investigate in this paper is whether the Key Graph scheme is optimal for scalable, multicast key distribution. For this, we must define the security requirements for key distribution. We discuss previous work in the Internet and the theory communities.. Internet proposals: The simplest solution advocated in RFCs 2093 and 2094 for multicast key distribution is to assign a user key for each valid user, and one group key for the group [10, 9] . When a user u leaves, the new group key is sent to each remaining user u i by encrypting with that userÕs key using (n À 1) transmissions. The Iolus system [13] improves scalability of adds and deletes using a geographical hierarchy of keys. Unfortunately, Iolus requires time-consuming encryption for several multicast server encountered in the path, and requires multiple trusted entities (the so-called group security agents).. In the past few years, several groups [1, 4, 20, 6, 19, 15] have proposed variations on a technique to allow the use of a single group data key for data transmission (as in RFC 2093/2094) while having scalable add and delete operations (as in Iolus). Thus it is possible to have the best of both worlds. We use the term from Wong et al. [20] , and refer to a Key Graph scheme in this paper.. The main idea is to have a single server but to have the server distribute subgroup keys in addition to the individual user keys and the group key. Keys are arranged in a logical hierarchy with the root key being the root and the individual user keys being the leaves. The subgroup keys then correspond to the intermediate nodes of this conceptual tree. Each subgroup key can be used to securely multicast to the users that are leaves of its corresponding subtree. Fig. 1 shows an example of a group of 8 users, u 1 to u 8 , represented as leaves in what is almost a binary tree. While the tree can be arbitrary, balanced trees are required for fast adds and deletes. The root key k 1 is known to all the users, the subtree key k 3 to users u 5 , . . . , u 8 , etc. Only the root key is used for data encryption, achieving similar performance for data encryption as in RFC 2093/2094. The subtree keys support fast rekeying.. Deletion is accomplished by rekeying all the keys on the path from the deleted user to the root. The main idea is to rekey from the bottom up, so that child subtrees have their keys for use when rekeying the parent. A balanced d-ary tree can be maintained at a cost of H(d log d n) encrypted messages per operation. It is easy to show that d log d n is minimized when d is 3.

O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O