= Simple Aggregation Message Passing Layer (SAMPL) =

The SAMPL protocol is a compact network layer that operates on top of a low-power MAC layer to achieve robust and economic aggregation of network-wide sensor information. Although our current implementation uses a low-power listen protocol similar to BMAC, the
same approach is also applicable to other energy-efficient MAC protocols. The protocol has been designed with extensibility in mind to support new transducer devices and unforeseen applications without requiring reprogramming of the entire network. The goals of the SAMPL protocol are as follows:

  • Efficiently collect sensor data using packet aggregation
  • Provide a control channel from the gateway to all nodes
  • Infrastructure support for mobile devices
  • Remote storage on each node similar to active RFID
  • Secure Communication
  • Built-in Performance Monitoring

Image(sampl-components.png)

Figure 1: SAMPL components

SAMPL uses a tree-based routing scheme in which control messages are flooded from a gateway through the network in order to establish routes and provides loose time synchronization for reply messages. Each level in the tree determined by the path of the flooding message has a delay relative to the maximum depth of the tree (based on hop count) such that sensor nodes contend for the channel only with other nodes at the same depth. The spanning tree created by the downstream flooding message sets the routing tables for reply messages to the gateway. Since lower branches in the tree reply earlier, messages can be efficiently aggregated together as they are passed up the tree. By default, the aggregation phase of operation simply removes redundant messages however this can be easily enhanced to do more intelligent in network processing to reduce data. During the upstream period of data collection, the Low-Power-Listen (LPL) check rate can be increased to allow for faster and more energy efficient collection since the network is expecting data. Routes can potentially change on each query making the network resilient to failures and able to support a high degree of mobility. Routes can optionally be reinforced over time to stop unnecessary re-routing. The flooding messages contain multiple control parameters setting attributes including: which nodes should reply, which sensor or data values should be transmitted, nonce counter values for CBC encryption, actuation control packets, network allocation vector (NAV) indicating when mobile communication is allowed. Control messages from the gateway can optimize the construction of the network spanning tree by applying various routing metrics or if need be set static routes.

Image(sampl-tree.png)

Figure 2: SAMPL collection tree formation

While performing data collection, SAMPL operates in a push-pull cycle where queries are sent out to all nodes in the subnet and data is aggregate back to the gateway. In between requests, SAMPL operates in a Peer-to-Peer (P2P) mode. P2P requests could originate from mobile devices or infrastructure nodes in the form of asynchronous messages. Since much of the infrastructure is battery operated, network reservations are put in place to protect static nodes from battery depletion. Infrastructure nodes are allotted a fixed number of P2P transactions per period of time. This enforcement mechanism is configurable in the gateway's control packets. Mobile nodes that overhear packets from the infrastructure can identify the type of protocol, the version of the protocol and the next period of free network access time based upon packet header information. When the channel is clear, mobile nodes can then perform operations like pinging for lists of neighbors with corresponding RSSI values, or access nearby sensors. We also provide mobile nodes with access to read and write 4KB of EEPROM on all infrastructure nodes. This can be used to store various types of spatial information such as node GPS coordinates; messages for a friend that is running late; or conference room schedule information. By providing a general read and write interface, SAMPL leaves the usage of the data up to the application developers. This is extremely useful in scenarios such as maintenance, where the technician can store information such as the last service date, known issues, next scheduled service etc. on the device itself.

Common Header

The common header to each packet consists of the following elements:
  • Byte 0 Protocol ID
    • This indicates which protocol is running in the network. SAMPL is always 1
  • Byte 1 Protocol Version
    • Indicates which version of the protocol is running on the node that sent the last message
  • Byte 2 Control Flags
    • Power Flag
      • This flag is set if the last-hop has an ample supply of power. In downstream messages, this bit is cleared by any link that is energy constrained to represent the power state of the entire route.
    • Connection Flag
      • This bit is set if the node has access to a gateway
    • Encryption Flag
      • This bit is set if the received packet was encrypted
    • Link ACK
      • This bit is set if you wish the message to use automatic link-layer ACKs and retries
    • Debug Flag
      • When this bit is set, infrastructure nodes dump debugging data. (note this mode of operation must be enabled by a control packet)
    • Tree Filter
      • For Downstream and Upstream packets this bit sets if new routes should be set and if replies should follow a single route
    • Mobile Flag
      • For P2P messages, this bit determines if they should be passed across different subnets. (see P2P section)
    • Bits 1:0
      • These bits set the class of message (Downstream 01, Upstream 10 or P2P 00)
  • Byte 3 Packet Type
    • This byte indicates what SAMPL packet type is contained in the message
  • Byte 4 Sequence Number
    • This byte contains a counter that should be incremented for each packet sent
  • Byte 5 ACK Retries and Priority
    • This byte contains the number of retries if Link ACKs are enabled and the priority of the message.
  • Byte 6-8 Subnet MAC
    • These bytes contain the subnet MAC of sender. For inter-subnet communication, only the least significant byte is used for addressing. The subnet MAC must match for each device that is part of a subnet.

Downstream Packet Format

Image(downstream.png)

Figure 3: Downstream Message Header Format

Upstream Packet Format

Image(upstream.png)

Figure 4: Upstream Reply Message Header Format

Peer-to-Peer Packet Format

Image(p2p.png)

Figure 5: Peer-to-Peer Message Header Format

Peer-to-peer packets can be used by mobile nodes or infrastructure nodes to send data in an asynchronous fashion as opposed to the normal data collection cycle. The destination address of a P2P message includes the full length source and destination MAC address. This allows messages from outside a local subnet (for example from a mobile node) to address any node in the system. Infrastructure nodes can set their own subnet in the destination subnet field for inter-subnet communication. Normally message routing within a subnet is filtered based on the destination subnet MAC address. If for example a mobile node from one subnet wishes to communicate with a mobile node from another subnet through the infrastructure, the messages would normally be ignored since the destination subnet does not match. In these situations, the mobile mask should be set. When the mobile mask bit is enabled, then the subnet is ignored allowing all messages to be forwarded by the infrastructure. This means that the mobile mask bit should be set if the destination of the packet is for any node potentially outside of the local subnet.

Example 1: Multi-hop message from mobile node to nearest gateway

 1    p2p_pkt.ctrl_flags = LINK_ACK;  
 2    p2p_pkt.ack_retry = 0x0f;
 3    p2p_pkt.ttl = 5;  // 5 hop max to find gateway
 4    p2p_pkt.src_subnet_macr0 = MY_SUBNET_MAC_0;
 5    p2p_pkt.src_subnet_macr1 = MY_SUBNET_MAC_1;
 6    p2p_pkt.src_subnet_macr2 = MY_SUBNET_MAC_2;
 7    p2p_pkt.src_mac = MY_MAC;
 8    p2p_pkt.last_hop_mac = MY_MAC;
 9    p2p_pkt.dst_subnet_macr0 = BROADCAST;
10    p2p_pkt.dst_subnet_macr1 = BROADCAST;
11    p2p_pkt.dst_subnet_macr2 = BROADCAST;
12    p2p_pkt.dst_mac = 0;

Example 2: Single-hop Message from mobile node to infrastructure node 0x01020304

 1    p2p_pkt.ctrl_flags = LINK_ACK; 
 2    p2p_pkt.ack_retry = 0x0f;
 3    p2p_pkt.ttl = 1;
 4    p2p_pkt.src_subnet_macr0 = MY_SUBNET_MAC_0;
 5    p2p_pkt.src_subnet_macr1 = MY_SUBNET_MAC_1;
 6    p2p_pkt.src_subnet_macr2 = MY_SUBNET_MAC_2;
 7    p2p_pkt.src_mac = MY_MAC;
 8    p2p_pkt.last_hop_mac = MY_MAC;
 9    p2p_pkt.dst_subnet_macr0 = 3;
10    p2p_pkt.dst_subnet_macr1 = 2;
11    p2p_pkt.dst_subnet_macr2 = 1;
12    p2p_pkt.dst_mac = 4;

Example 3: Broadcast message 1-hop

 1    p2p_pkt.ctrl_flags = 0; 
 2    p2p_pkt.ack_retry = 0x00;
 3    p2p_pkt.ttl = 1;
 4    p2p_pkt.src_subnet_macr0 = MY_SUBNET_MAC_0;
 5    p2p_pkt.src_subnet_macr1 = MY_SUBNET_MAC_1;
 6    p2p_pkt.src_subnet_macr2 = MY_SUBNET_MAC_2;
 7    p2p_pkt.src_mac = MY_MAC;
 8    p2p_pkt.last_hop_mac = MY_MAC;
 9    p2p_pkt.dst_subnet_macr0 = BROADCAST;
10    p2p_pkt.dst_subnet_macr1 = BROADCAST;
11    p2p_pkt.dst_subnet_macr2 = BROADCAST;
12    p2p_pkt.dst_mac = BROADCAST;

Example 4: Multi-hop Mobile node message from 0x01020304 to mobile node 0x01020305 through infrastructure

 1    p2p_pkt.ctrl_flags = LINK_ACK  | MOBILE_MASK; 
 2    p2p_pkt.ack_retry = 0x0f;
 3    p2p_pkt.ttl = 5;
 4    p2p_pkt.src_subnet_macr0 = 3;
 5    p2p_pkt.src_subnet_macr1 = 2;
 6    p2p_pkt.src_subnet_macr2 = 1;
 7    p2p_pkt.src_mac = 4;
 8    p2p_pkt.last_hop_mac = 4;
 9    p2p_pkt.dst_subnet_macr0 = 3;
10    p2p_pkt.dst_subnet_macr1 = 2;
11    p2p_pkt.dst_subnet_macr2 = 1;
12    p2p_pkt.dst_mac = 5;

Gateway Packet Format

Image(gateway.png)

Figure 6: Gateway Message Header Format

Application Packets

  • XMPP-lite
    The XMPP lite packet allows a sensor node to send and receive messages from arbitrary XMPP jids. The gateway will login as a proxy and deliver messages on your behalf. The src jid is the JID for your node. The passwd should contain the password for your JID so that the node can authenticate with the XMPP server. The dst jid should contained the recipient's JID for your message. The length fields correspond to the length of either the JIDs, password or message. By default, your src jid is derived from the node's 32bit MAC address. For example 0x01020304 would become . If the explicit src jid is set, then you can specify the JID you wish to use as your source. The gateway will automatically append gateway-server-domain at the end of any JID lacking an "" symbol. The pubsub flag sets if the gateway should publish the message to the dst jid event node instead of sending a direct message to the dst jid. In the case of publishing, no @server is required after the event node name. By default, all messages are expected to be an ASCII string. If the binary flag is set, then the buffer is read as raw bytes and converted into 2 digit hex characters before being packet into the XMPP message payload. For example bytes 1,2,56,34 with the message size set to 4 would be sent as "01023822" in the message body.
                               1            
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          | |E|P|B|       Timeout         |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |  passwd size  |  src jid size |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |  dst jid size |    msg size   |              
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |     variable length fields    |    
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |     message...                |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
          E - Explicit src jid Flag
          P - [[PubSub]] Flag
          B - Binary Flag
          Timeout:  Number of seconds that src JID should remain logged in
          variable length fields:  Password String, [Source JID String], Destination JID String
          message: Ascii Text or Data if Binary Flag set
    
  • Ping Packet
    
           0 1 2 3 4 5 6 7 
          +-+-+-+-+-+-+-+-+
          |   short addr  | 
          +-+-+-+-+-+-+-+-+
    
    
  • ACK/NCK Packet
  • Transducer Packet
  • Routing Packet
  • Control Packet
  • Runtime Statistics Packet
  • Data Storage Packet
  • Time Packet
                               1                  
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |  short addr   |  Time 3 (MSB) | 
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |      Time 2   |     Time 1    | 
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
          | Time 0 (LSB)  |    
          +-+-+-+-+-+-+-+-+
    
    
  • Traceroute Packet
  • Neighbor List Packet
  • Extended Neighbor List Packet

sampl-components.png - SAMPL components (33.4 kB) Anthony Rowe, 11/10/2008 11:52 pm

sampl-tree.png - Example collection tree (23.5 kB) Anthony Rowe, 11/10/2008 11:57 pm

downstream.png - Downstream Packet Header (47.9 kB) Anthony Rowe, 11/18/2008 04:04 pm

gateway.png - Gateway Node Packet Header (40.4 kB) Anthony Rowe, 11/18/2008 04:04 pm

p2p.png - P2P Packet Header (43 kB) Anthony Rowe, 11/18/2008 04:04 pm

upstream.png - Upstream Packet Header (28.8 kB) Anthony Rowe, 11/18/2008 04:05 pm