A Transport Protocol for Multimedia Wireless Sensor Networks

(1)

technology

from seed

A Transport Protocol for Multimedia Wireless Sensor Networks

Duarte Meneses, António Grilo, Paulo Rogério Pereira

Instituto de Engenharia de Sistemas e Computadores Investigação e Desenvolvimento em Lisboa

27-06-2011 1 NGI'2011: A Transport Protocol for Multimedia Wireless Sensor Networks

technology

from seed

Introduction –

Wireless Sensor Networks

• Typically a high number of autonomous nodes with sensors and RF communications.

• Cooperate in a common task retrieving sensor data such as:

temperature, humidity, light, image, video, etc.

• Data is normally forwarded wirelessly to a sink node

• Used in surveillance and security, industrial process control, military

• Used in surveillance and security, industrial process control, military applications, domotics, monitoring, etc.

Other networks

Mobile devices

(2)

technology

from seed

Motivation

• Protection of critical infrastructures, namely electrical energy distribution infrastructures

• Multimedia data from cameras is routed multi-hop to the sink

• WSN advantages: ease of installation, configuration, flexibility, low power

• TCP: end-to-end, loss assumed as congestion, RTT delays

• New transport protocol tailored for WSN: DTSN.

27-06-2011 NGI'2011: A Transport Protocol for Multimedia Wireless Sensor Networks

3

technology

from seed

Objectives

Transport protocol for WSN with the following characteristics:

• Adapted to embedded systems

• Battery operated

• Runs on Linux

• Support reliability

• Optimize multimedia data transfers, particularly real-time video

• Support several simultaneous applications

• Support security mechanisms

• Ease of use through an API

4

(3)

technology

from seed

Purpose: Reliability Guarantee and/or Congestion Control Several different characteristics and mechanisms:

• upstream/downstream communication

• Loss feedback through: ACK, NACK, iACK

• Lost segment detection: sequence number continuity or timers for each segment

Transport Protocols for WSN

timers for each segment

• end-to-end or hop-by-hop recovery

• Two types of target applications: sending events or sending large data volumes

t^EƐdƌĂŶƐƉŽƌƚWƌŽƚŽĐŽůƐ

ZĞůŝĂďŝůŝƚǇ'ƵĂƌĂŶƚĞĞ

ŽŶŐĞƐƚŝŽŶŽŶƚƌŽů

WKZd͕K W&^Y͕ZdW͕ZD^d͕

d^E͕'Zh

^dW͕dW͕^Zd͕d

technology

from seed

• Sessions identified by a Session Number, Application ID, source and destination

addresses

• Feedback when requested by the source through an DTSN

DATA 0

DATA 3 DATA 2 DATA 1

DATA 8 DATA 4 DATA 6 DATA 5 DATA 7 + EAR

DATA 10 DATA 12 DATA 11 DATA 9

DATA 13 DATA 15 + EAR DATA 14

DATA 3 DATA 2 DATA 4 DATA 6 DATA 5 DATA 7 + EAR

DATA 13 DATA 14

DATA 10 DATA 12 DATA 11 DATA 13 DATA 14 EAR 15

DATA 7 + EAR

NACK 0, <0,1,2,3>

Node 1 Node 2 Node 3

NACK 0, <0,1,2>

Node 4

DATA 3 EAR

Timeout

source through an Explicit

Acknowledgement Request (EAR)

• Losses detected through the sequence number continuity

• Selective Repeat retransmission hop- by-hop: intermediate nodes cache packets

EAR 15

NACK 0, <0,1,2,8,9,10,12,15>

DATA 10 DATA 12 NACK 0, <0,1,2,8,9,15>

NACK 0, <0,1,8,15>

DATA 0 DATA 1

t

DATA 8 DATA 15 Flow Control Timeout

EAR 15

EAR 15 DATA 0

NACK 7, <8,10,12>

NACK 7, <8,12>

NACK 7, <>

DATA 2 DATA 9

DATA 10

DATA 8

DATA 12 DATA 8

DATA 12 DATA 17

DATA 19 DATA 17

DATA 16 DATA 18

DATA 19 DATA 17

(4)

technology

from seed

Expected number of links crossed:

Expected number of transmissions per Probabilistic Model

Success probability:

packet:

Generalized formulas for different losses in each link:

technology

from seed

Expected number of transmissions when packets are cached with 50% probability:

Probabilistic model 2

ϭϬ ϭϭ ϭϮ

ǆƉĞĐƚĞĚEƵŵďĞƌŽĨdƌĂŶƐŵŝƐƐŝŽŶƐ

ϳ ϴ ϵ ϭϬ

Ϭ͘Ϭϭ Ϭ͘ϬϮ Ϭ͘Ϭϯ Ϭ͘Ϭϰ Ϭ͘Ϭϱ Ϭ͘Ϭϲ Ϭ͘Ϭϳ Ϭ͘Ϭϴ Ϭ͘Ϭϵ Ϭ͘ϭ

ǆƉĞĐƚĞĚEƵŵďĞƌŽĨdƌĂŶƐŵŝƐƐŝŽŶƐ

WĂĐŬĞƚ>ŽƐƐWƌŽďĂďŝůŝƚǇŝŶĞĂĐŚ>ŝŶŬ

ĂĐŚŝŶŐĚŝƐĂďůĞĚ͕ϮϱйůŽƐƐŝŶƚŚĞůĂƐƚůŝŶŬ

ĂĐŚŝŶŐĞŶĂďůĞĚ͕ϮϱйůŽƐƐŝŶƚŚĞůĂƐƚůŝŶŬ

ĂĐŚŝŶŐǁŝƚŚϱϬйƉƌŽďĂďŝůŝƚǇ

ĂĐŚŝŶŐĞŶĂďůĞĚ

ĂĐŚŝŶŐĚŝƐĂďůĞĚ

(5)

technology

from seed

• The protocol is generic: can work over several wireless technologies and hardware

• The Silex SX-560 was used.

• Supports Wi-Fi 802.11a/b/g.

• 200 MHz 32-bit ARM processor

• 16 MB RAM

Development Platform

• 16 MB RAM

• 8MB Flash

• Runs Linux

• 792 mW average power

• 49.6 x 34.3 x 9.65 mm

• Developer’s daughtercard with USB, serial, SPI, GPIO, Ethernet, power

technology

from seed

General Architecture

• DTSN implemented as a single daemon process for all node types: source, receiver and intermediate nodes.

• Clients use the protocol through a library that connects to the daemon through UNIX sockets

• Several configuration parameters may be adjusted in a configuration file

(6)

technology

from seed

• Dynamic library

• Interface similar to the Unix sockets interface

• Simple operation, with most work done centrally in the daemon

• The application can receive asynchronous events

• Threads, blocking and exclusive access implemented

API

• Threads, blocking and exclusive access implemented through the pthread library

technology

from seed

• Header present in all packets: ^Bit ^Flag

0 ACK

1 NACK

2 EAR

3 DATA

4 RESEND

5 ENDSESSION

6 (not used

7 (not used)

DTSN Sessions 1

• Soft unidirectional sessions, identified by <App ID, Session No, Src Addr, Dest Addr>. No connection establishment: the

applications just creates the session and start sending packets

• A complete session description is maintained with buffers, timers, ID, mode, etc.

• The session can be kept internally after being closed by the application

7 (not used)

(7)

technology

from seed

• Sliding windows mapped into circular buffers

• Both windows synchronized.

• Simple flow control by limiting the number of unconfirmed packets

DTSN Sessions 2

sender receiver

368367366365 63 4 63 3 63 2 36 1 0 36 9 35 8 35

369 370

371 372

373 374

375 376 Aplication

Oldest unconfirmed segment Last segment sent

Where the next segment will be placed DTSN

368

367366365

63 4 633 63 2 63 1 0 36 9 35 8 35

369 370

371 372

373 374

375 376 Aplication

Next expected segment

Last segment received

Next segment to be read by the application DTSN

technology

from seed

• Intermediate nodes participate in packet recovery

• Space uniformly divided through existing sessions

• Packets kept in linked lists

• FIFO for each session

• Other caching policies for dŝŵĞŽĨůĂƐƚ^{^ĞƐƐŝŽŶ/}

^ĞƐƐŝŽŶ/

dŝŵĞŽĨůĂƐƚ

^ĞƐƐŝŽŶ/

dŝŵĞŽĨůĂƐƚ

EƐĞƐƐŝŽŶƐ

Cache

• Other caching policies for future work

• Packets eliminated with ACK/NACK/ENDSESSION received if security is

not used

WĂĐŬĞƚ dŝŵĞŽĨůĂƐƚ

ĂĐƚŝǀŝƚǇ

͘͘͘

dŝŵĞŽĨůĂƐƚ

ĂĐƚŝǀŝƚǇ

͘͘͘

WĂĐŬĞƚ

dŝŵĞŽĨůĂƐƚ

ĂĐƚŝǀŝƚǇ

͘͘͘

WĂĐŬĞƚ

DĂǆŝŵƵŵƉĂĐŬĞƚƐƉĞƌ ƐĞƐƐŝŽŶ͗ŵĂǆͺŐůŽďĂůͬE

(8)

technology

from seed

• Activity Timeout: used when the sender window is not empty or full, and no new data is received from the application, to trigger sending an EAR.

• EAR Timeout: used when an EAR was sent and the sender is There are 5 timers with different periods and purposes.

There is always a single one active at each time for each session.

Timers

• EAR Timeout: used when an EAR was sent and the sender is waiting for a NACK/ACK.

• Wait Timeout: used when the sender window is empty to destroy a session without activity.

• Flow control Timeout: Active when the sender window is full

• Receiver Activity Timeout: only timer used by the receiver, restarted every time a packet is received from the source.

sender

receiver

technology

from seed

Security 1

• Most WSN protocols ignore the security issues, assuming it is assured by lower layers (e.g. MAC).

– This may be energetically inefficient, as only some (important) packets require security

• Attacks possible by packet replication or injection

– Purpose: denial of service, data manipulation, reduce node lifetime

• Security requires some overhead, increasing energy spent

• Security is optional: the application decides

• The DTSN security extension uses symmetric

cryptographic functions (HMAC based on the SHA-2 hash function).

16

(9)

technology

from seed

masterkey

“ACK master key” |AppId

ACK master key

NACK master key HMAC

HMAC HMAC

HMAC K_ACK⁽ⁿ⁾ K_NACK⁽ⁿ⁾

“per packet ACK key” |n

HMAC HMAC

MIC_NACK⁽ⁿ⁾ MIC_ACK⁽ⁿ⁾

y Message Integrity Code (MIC) and key computation:

Security 2

y Packet format:

“NACK master key” |AppId

“per packet NACK key” |n <packet contents>

K H D G H U 1 U E LWV Q

E LWP D S

K H D G H U N H \

K H D G H U G D WD V L] H

0 ,& $ & . 0 ,& 1 $ & . 1 $ & . N H \ V

ϭ ϳ ď Ǉ ƚ Ğ Ɛ ϭ ϳ ď Ǉ ƚ Ğ Ɛ ϭ ϳ ď Ǉ ƚ Ğ Ɛ

ϭ ď Ǉ ƚ Ğ Ŷ ͬ ϴ ď Ǉ ƚ Ğ Ɛ

ǀ Ă ƌ ŝĂ ď ůĞ

ϭ ϲ ď Ǉ ƚ Ğ Ɛ Ϯ ď Ǉ ƚ Ğ Ɛ

E < < d

' D WD

ϭ ϲ ď Ǉ ƚ Ğ Ɛ ϭ ϲ ď Ǉ ƚ Ğ Ɛ ǀ Ă ƌ ŝĂ ď ůĞ

$ & . N H \ ϭ ϲ ď Ǉ ƚ Ğ Ɛ

technology

from seed

• M-DTSN functionality implemented, allows restarting a session. The following actions are performed:

• Discard all packets in the sender window and change the session nr.

• Intermediate nodes also discard cached packets

• The receiver eliminates data from the window and notifies the application

Multimedia

&ƌĂŵĞϭ

&ƌĂŵĞϮ

&ƌĂŵĞϯ

&ƌĂŵĞϭ

&ƌĂŵĞϮ

&ƌĂŵĞϯ

/ Ϯ/ ϯ/

d^E

DͲd^E

ĂƐĞůĂǇĞƌƚƌĂŶƐŵŝƐƐŝŽŶ

ĂƐĞůĂǇĞƌŶŽƚƚƌĂŶƐŵŝƚƚĞĚ

ĚĚŝƚŝŽŶĂůůĂǇĞƌƚƌĂŶƐŵŝƐƐŝŽŶ

ĚĚŝƚŝŽŶĂůůĂǇĞƌŶŽƚƚƌĂŶƐŵŝƚƚĞĚ

• A new session is implicitly started without additional overhead

• The idea is to give up on sending data from a frame after a temporal limit set by the

application.

(10)

technology

from seed

• A module to simulate a sensor network over a LAN was developed

• Routing is made based on DTSN addresses

• Arbitrary bit error rates can be configured

• A 1.95 MB file was transmitted over 7 hops

• 5 situations tested:

• 512 bytes payload with and without cache

• 512, 350 and 200 bytes payload with security and cache

Simulation

512, 350 and 200 bytes payload with security and cache

• Single hop between a PC and a Silex to measure throughput

Wϭ ϭϵϮ͘ϭϲϴ͘ϯ͘ϭ

Wϰ ϭϵϮ͘ϭϲϴ͘ϯ͘ϰ

Wϱ ϭϵϮ͘ϭϲϴ͘ϯ͘ϱ

Wϲ ϭϵϮ͘ϭϲϴ͘ϯ͘ϲ

Wϳ ϭϵϮ͘ϭϲϴ͘ϯ͘ϳ

Wϴ ϭϵϮ͘ϭϲϴ͘ϯ͘ϴ Wϭ

ϭϵϮ͘ϭϲϴ͘ϯ͘ϭ

WϮ ϭϵϮ͘ϭϲϴ͘ϯ͘Ϯ

Wϯ ϭϵϮ͘ϭϲϴ͘ϯ͘ϯ

ZŽƵƚĞƌ

technology

from seed

ϮϯϮ

ϭϴϳ ϭϴϲ ϭϵϬ ϭϲϴ ϭϱϯ ϭϲϭ

ϰϲϴ ϰϰϱ

ϯϳϮ ϯϵϲ

ϯϰϵ ϯϮϭ ϯϮϰ

ϳϵϲ

ϲϱϲ ϳϳϲ

ϲϮϰ

ϰϳϲ ϱϮϲ

ϰϱϮ

ϮϬϬ ϯϬϬ ϰϬϬ ϱϬϬ ϲϬϬ ϳϬϬ ϴϬϬ

ĂƚĂƉĂĐŬĞƚƐůŽƐƐ͕ǁŝƚŚŽƵƚĐĂĐŚĞ

ϮϬϮ ϭϴϮ ϭϳϳ ϭϲϭ ϭϲϴ ϭϱϮ

ϭϵϭ

ϯϭϴ ϯϮϬ ϯϬϲ Ϯϵϭ Ϯϴϵ ϯϬϴ Ϯϵϯ

ϰϴϲ ϰϵϯ

ϰϱϯ ϰϯϬ ϰϭϲ

ϰϱϮ ϰϮϲ

ϮϬϬ ϯϬϬ ϰϬϬ ϱϬϬ ϲϬϬ ϳϬϬ ϴϬϬ

ĂƚĂƉĂĐŬĞƚƐůŽƐƐ͕ǁŝƚŚĐĂĐŚĞ

Results 1

Instituto de Engenharia de Sistemas e Computadores Investigação e Desenvolvimento em Lisboa ϳϳ

ϰϰ ϰϴ ϯϭ ϯϳ ϰϭ ϯϱ

ϭϱϯ

Ϭ ϭϬϬ

ϭ Ϯ ϯ ϰ ϱ ϲ ϳ

>ŝŶŬ WсϬ͘Ϭϭ WсϬ͘Ϭϰ WсϬ͘Ϭϳ WсϬ͘ϭ

ϰϱ ϰϵ ϯϯ ϰϲ ϰϲ ϰϭ ϰϱ

ϭϲϭ ϭϱϮ

Ϭ ϭϬϬ ϮϬϬ

ϭ Ϯ ϯ ϰ ϱ ϲ ϳ

>ŝŶŬ WсϬ͘Ϭϭ WсϬ͘Ϭϰ WсϬ͘Ϭϳ WсϬ͘ϭ

ϳ ϳ͘ϭ ϳ͘Ϯ ϳ͘ϯ ϳ͘ϰ ϳ͘ϱ ϳ͘ϲ ϳ͘ϳ ϳ͘ϴ ϳ͘ϵ

Ϭ͘Ϭϭ Ϭ͘Ϭϰ Ϭ͘Ϭϳ Ϭ͘ϭ

ǀĞƌĂŐĞŶƵŵďĞƌŽĨƚƌĂŶƐŵŝƐƐŝŽŶƐ͕ ǁŝƚŚĐĂĐŚĞ

ĂƚĂƉĂĐŬĞƚůŽƐƐƉƌŽďĂďŝůŝƚǇ ŝŶĞĂĐŚůŝŶŬ dĞƐƚƐ ŶĂůǇƚŝĐĂůĂŶĂůǇƐŝƐ

(11)

technology

from seed

• Comparing the 5 tested scenarios

:

Results 2

Ϭ͘ϱϱ Ϭ͘ϱϴ

Ϭ͘ϴϯ

Ϭ͘ϰϲ Ϭ͘ϲϳ Ϭ͘ϲϴ

ϭ͘Ϭϴ

Ϭ͘ϱ Ϭ͘ϲ Ϭ͘ϳ Ϭ͘ϴ Ϭ͘ϵ ϭ ϭ͘ϭ

EŽƌŵŝůŝǌĞĚŶƵŵďĞƌŽĨůŽƐƚĚĂƚĂƉĂĐŬĞƚƐ

ϵ ϭϬ ϭϭ

ǀĞƌĂŐĞŶƵŵďĞƌŽĨĚĂƚĂƉĂĐŬĞƚƚƌĂŶƐŵŝƐƐŝŽŶƐ

200

512 Ϭ͘Ϭϯ

Ϭ͘ϭϰ

Ϭ͘Ϯϰ

Ϭ͘ϯϳ

Ϭ͘Ϭϲ

Ϭ͘ϮϮ

Ϭ͘ϯϵ

Ϭ͘Ϭϴ

Ϭ͘ϯϯ

Ϭ͘Ϭϴ

Ϭ͘Ϯϲ

Ϭ͘ϰϲ

Ϭ͘Ϭϴ

Ϭ͘ϯϮ

Ϭ Ϭ͘ϭ Ϭ͘Ϯ Ϭ͘ϯ Ϭ͘ϰ Ϭ͘ϱ

Ϯ͘ϰͲϬϲ ϵ͘ϲͲϬϲ ϭ͘ϳͲϬϱ Ϯ͘ϱͲϬϱ

EŽƌŵŝůŝǌĞĚŶƵŵďĞƌŽĨůŽƐƚĚĂƚĂƉĂĐŬĞƚƐ

ŝƚĞƌƌŽƌƉƌŽďĂďŝůŝƚǇŝŶĞĂĐŚůŝŶŬ

tŝƚŚƐĞĐƵƌŝƚǇĂŶĚĐĂĐŚŝŶŐ͕ϮϬϬďǇƚĞƐƉĂǇůŽĂĚ tŝƚŚƐĞĐƵƌŝƚǇĂŶĚĐĂĐŚŝŶŐ͕ϯϱϬďǇƚĞƐƉĂǇůŽĂĚ tŝƚŚƐĞĐƵƌŝƚǇĂŶĚĐĂĐŚŝŶŐ͕ϱϭϮďǇƚĞƐƉĂǇůŽĂĚ tŝƚŚĐĂĐŚŝŶŐ͕ϱϭϮďǇƚĞƐƉĂǇůŽĂĚ tŝƚŚŽƵƚĐĂĐŚŝŶŐ͕ϱϭϮďǇƚĞƐƉĂǇůŽĂĚ

ϳ ϴ

Ϯ͘ϰͲϬϲ ϵ͘ϵͲϬϲ ϭ͘ϳͲϬϱ Ϯ͘ϱͲϬϱ

ǀĞƌĂŐĞŶƵŵďĞƌŽĨĚĂƚĂƉĂĐŬĞƚƚƌĂŶƐŵŝƐƐŝŽŶƐ

technology

from seed

Results 3

Ϭ͘ϭϰ Ϭ͘ϭϲ Ϭ͘ϭϴ Ϭ͘Ϯ Ϭ͘ϮϮ Ϭ͘Ϯϰ Ϭ͘Ϯϲ Ϭ͘Ϯϴ Ϭ͘ϯ

KǀĞƌŚĞĂĚƌĂƚŝŽ

ϭϭ ϭϮ ϭϯ ϭϰ ϭϱ ϭϲ ϭϳ ϭϴ ϭϵ ϮϬ Ϯϭ ϮϮ Ϯϯ Ϯϰ

dŽƚĂůƚƌĂŶƐŵŝƚƚĞĚďǇƚĞƐ;DŝůůŝŽŶƐͿ

Instituto de Engenharia de Sistemas e Computadores Investigação e Desenvolvimento em Lisboa Ϭ

Ϭ͘ϬϮ Ϭ͘Ϭϰ Ϭ͘Ϭϲ Ϭ͘Ϭϴ Ϭ͘ϭ Ϭ͘ϭϮ

Ϯ͘ϰͲϬϲ ϵ͘ϵͲϬϲ ϭ͘ϳͲϬϱ Ϯ͘ϱͲϬϱ

KǀĞƌŚĞĂĚƌĂƚŝŽ

Ϭ ϭ Ϯ ϯ ϰ ϱ ϲ ϳ ϴ ϵ ϭϬ ϭϭ

Ϯ͘ϰͲϬϲ ϵ͘ϲͲϬϲ ϭ͘ϳͲϬϱ Ϯ͘ϱͲϬϱ

dŽƚĂůƚƌĂŶƐŵŝƚƚĞĚďǇƚĞƐ;DŝůůŝŽŶƐͿ

ŝƚĞƌƌŽƌƉƌŽďĂďŝůŝƚǇŝŶĞĂĐŚůŝŶŬ tŝƚŚƐĞĐƵƌŝƚǇĂŶĚĐĂĐŚŝŶŐ͕ϮϬϬďǇƚĞƐƉĂǇůŽĂĚ tŝƚŚƐĞĐƵƌŝƚǇĂŶĚĐĂĐŚŝŶŐ͕ϯϱϬďǇƚĞƐƉĂǇůŽĂĚ tŝƚŚƐĞĐƵƌŝƚǇĂŶĚĐĂĐŚŝŶŐ͕ϱϭϮďǇƚĞƐƉĂǇůŽĂĚ tŝƚŚĐĂĐŚŝŶŐ͕ϱϭϮďǇƚĞƐƉĂǇůŽĂĚ

tŝƚŚŽƵƚĐĂĐŚŝŶŐ͕ϱϭϮďǇƚĞƐƉĂǇůŽĂĚ

(12)

technology

from seed

Results 4

PC ĺ Silex Silex ĺ PC

DTSN 10.36 s (1.51 Mbps) 8.03 s (1.94 Mbps)

DTSN with security 10.97 s (1.42 Mbps) 8.22 s (1.90 Mbps)

• 1.95 MB file transfer over a 10Mbps Ethernet

• 1 hop, no link errors

• Performance results:

• High overhead in the communication between the protocol and application

• The security option impact on performance is not significant

DTSN with security 10.97 s (1.42 Mbps) 8.22 s (1.90 Mbps) DTSN without delivery

to application on Silex 4.69 s (3.33 Mbps) 8.03 s (1.94 Mbps) TFTP (UDP) 12.0 s (1.30 Mbps) 79.9 s (0.20 Mbps) FTP (TCP) 3.00 s (5.20 Mbps) 5.17 s (3.02 Mbps)

technology

from seed

Results 5

• Optimized version performance results:

PC -> PC

(Fast Ethernet)

[Mbps]

PC -> Silex

(802.11b)

[Mbps]

Silex -> PC

(802.11b)

[Mbps]

Silex -> Silex

(802.11b)

[Mbps]

DTSN 83.20 2.36 3.21 2.69

• Much better performance

• Silex CPU performance is a limitation

DTSN 83.20 2.36 3.21 2.69

DTSN with security 62.42 1.68 2.02 1.87

FTP 88.68 5.73 4.47 4.69

TFTP 10.96 0.34 0.29 0.17

(13)

technology

from seed

Conclusion

• A transport protocol for real-time streaming in WMSN was successfully implemented and tested.

• Tests prove the correct operation and show that DTSN is efficient in reducing the number of transmissions in

WMSN, thus saving energy.

• Future work:

– Dynamic parameters, such as timeouts, window and cache sizes – New caching policies, for instance by storing packets with

probability less than 1, according to the distance to destination, etc.

– raw sockets – BeagleBoard

25

technology

from seed

technology from seed

from seed