forked from mikaelpatel/Cosa
-
Notifications
You must be signed in to change notification settings - Fork 0
/
RETE.txt
112 lines (82 loc) · 4.33 KB
/
RETE.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
RETE: COSA DATA DISTRIBUTION AND NETWORK MANAGEMENT PROTOCOL
Author: Mikael Patel
Date: 2013-11-12
Rev.: 1.0.3
This document is a short description of the messages in the Cose data
distribution and network mangement protocol RETE. The protocol is
inspired by the OMG DDS and SNMP but very much adapted to a small
scale embedded system.
The protocol contains two primary elements; 1) a management protocol
to control wireless sensor nodes, 2) data distribution service from
sensor nodes.
To achieve low power sensor devices the management protocol is often
piggy-backed on either acknowledgements or transmitted directly after
receiving a data update event from the sensor. A sensor will attempt
to receive management messages for a short period after sending a data
update and before going back to power down mode.
PROTOCOL AND MESSAGES
The network management protocol contains three basic message
pairs. The transactions are always initiated by the supervision node
with a request message. The sensor node may answer with a response
message.
0:GET-REQUEST(id, network, device, path)
1:GET-RESPONSE(id, network, device, status, value)
The GET request message reads an attribute in the sensor device
registry. A transaction identity and path are given. The response
will contain the transaction identity and a status followed by the value
of the attribute if the access was granted and the path was valid.
2:PUT-REQUEST(id, network, device, path, value)
3:PUT-RESPONSE(id, network, device, status)
The PUT request message attempts to modify an attribute in the sensor
device registry. A transaction identity, attribute path and new value
is given. The response will contain the transaction identity and the
status of the request.
4:APPLY-REQUEST(id, network, device, path, value)
5:APPLY-RESPONSE(id, network, device, status, value)
The APPLY request message will the execution of a function in the
sensor device registry. A transaction identity, function attribute
path and argument block are given. The response is the status of the
request and possible return values from the function. APPLY may be
seen as generalization of the PUT request with a response with the
result.
6:PUBLISH(network, device, idenity, path, value)
The PUBLISH message is a message sent from a sensor node. An identity
together with attribute path and value are given. Receiving nodes may
SUBSCRIBE to messages by filtering this message type. Filtering may be
achieve on network, device, identity and path.
ENCODING
1. MESSAGE TYPE(uint8_t)
The messages are encoded in the RETE message type sequence. The
numbers are the indexies.
2. ADDRESSING(uint16_t network, uint8_t device)
The network/device addressing is part of the parameters to the
Wireless interface.
3. PATH(uint8_t length, {uint8_t index*})
The path parameter is a length prefixed sequence of indexies(uint8_t)
in the attribute tree. The path may be viewed as a protocol family
unique key to an attribute or set of attributes.
4. IDENTITY(uint16_t family,vendor,serialnr)
The family code is used to identity the root of a path within a given
attribute tree. The family code is the key to the MIB. The individual
device number is composed of the vendor identity and a serial number.
5. DATA ENCODING
RETE does not defined to encoding of data (i.e. attribute
values). Most wireless sensor data are small in size (less than 32
bytes) and there is no gain by encoding.
From a security point of view it is very important to encrypt at least
registry updates. If there are actuators directly listening to sensor
data the sensor data publish must also be encrypted to reduce
tampering. With the limited amount of processing power and memory in
very small embedded wireless sensor efficient encryption algorithms
are difficult to find. Cosa supports RC4 and Vigenere which both
require very little resources to implement and are extremly fast (< 10
us per byte).
LOW POWER CONSIDERATION
In battery powered wireless sensor networks it is important to
consider low power design of the wireless protocol. The transceiver
must be turned off and the device put in power down state as often as
possible.
For a periodically reporting sensor it is natural to have a listening
period directly following the sensor data transmission. The further
reduce transmission it is possible to synchronize the sensors to a
controller/rounter pulse (i.e. beacon).