BLIP 2.0 Platform Support Guide

Error creating thumbnail: File missing

BLIP 2 Platform Support Guide

The purpose of this page is to describe what interfaces and hardware support must be present for blip-2 to work. Currently, only epic and tmote platforms are supported. It should be noted that this guide merely describes what is actually required to get blip to run, and does not represent a working-group consensus or a commitment to these interfaces.

Overview

Blip is reasonably platform-independent, and should work with only a smallish set of components allowing access to the interfaces. The basic components are:

• An implementation of TEP122, providing a unique 64-bit EUI64 to be used as the base for IPv6 link-local addresses
• Suitable interface support. Blip supports adding multiple interfaces for packets to leave on; the two which are implemented currently are a Point-to-Point Protocol implementation for serial communication, and a 6lowpan "Layer 2.5" shim which sits on top of IEEE 802.15.4 packet radios.

LocalIeeeEui64C

This component provides globally unique 64-bit ids. Blip2 does not implement Duplicate Address Detection since it is normally used over 6lowpan links, and so it is important that the IDs this component provides are actually unique. Practically speaking, while it is desirable for these ids to be globally unique, it is typically practical for deployments to use identifiers where only local uniqueness is guaranteed; the component should take care to set the U/L bit appropriately in this case.

Interface Support

The blip stack wires itself together on top of interfaces, in the IPv6 sense of the term. Blip currently only supports interfaces using IEEE 802.15.4 link-layer addresses; in the future it may be desirable to support multiple address types if there is a need to run on top of other links like 802.3. Each interface must implement the IPLower nesc interface which allow the stack to submit packets to the lower layer.

struct send_info {
  void   *upper_data;           /* reference to the data field of IPLower.send */
  uint8_t link_fragments;       /* how many fragments the packet was split into */
  uint8_t link_transmissions;   /* how many total link transmissions were required */
  bool    failed;               /* weather the link reported that the transmission succeed*/
  uint8_t _refcount;
};

interface IPLower {

  /*
   * sends the message with the headers and payload given.  Things
   * which we know how to compress should be part of the data passed
   * in as headers; things which we cannot compress must be passed as
   * payload.  

   * the interface is this way so that the stack may insert extra
   * (routing, snooping) headers between the two sections.
   * once the call returns, the stack has no claim on the buffer
   * pointed to
   */ 
  command error_t send(struct ieee154_frame_addr *next_hop, 
                       struct ip6_packet *msg,
                       void *data);

  event void sendDone(struct send_info *status);

  /*
   * indicate that the stack has finished writing data into the
   * receive buffer. 
   */
  event void recv(struct ip6_hdr *iph, void *payload, struct ip6_metadata *meta);
}

6lowpan Interface Support

Support for 6lowpan is implemented as an interface implementing IPLower. It is just a more-complicated than usual interface since it splits up large packets into fragments and applies the header compression. It is implemented by IPDispatchC. It requires slightly special radio support for it to work; the standard TinyOS stack does not support sending or receiving packets using 64-bit extended addresses.

Currently, IPDispatchC directly references CC2420RadioC; this is clearly broken and must be renamed. However, the IEEE 802.15.4 radio driver must support the following interfaces:

• Send as BareSend
• Receive as BareReceive
• Packet as BarePacket
• PacketLink

Blip uses PacketLink to implement link-layer retransmissions for outgoing packets. The Bare* family of interfaces refer to methods of accessing the radio where the "payload" starts at the first octet of the IEEE 802.15.4 header (the length byte), and all lengths refer to the number of bytes in the frame including the length byte: therefore the maximum length is 128. Note this is different from the value in the 802.15.4 header since that value does not include the length byte.

The radio driver should support sending and receiving frames using 64-bit extended address mode, since blip will likely generate these frames. This typically involves only modifying the address recognition code to properly check the destination address.

Addressing Control

Blip assumes there is exactly one 802.15.4 interface on the platform, and attempts to configure its address using the Ieee154Address interface. It is very similar to the ActiveMessageAddress interface, with an additional call to support extended address mode:

interface Ieee154Address {
  command ieee154_panid_t getPanId();
  command ieee154_saddr_t getShortAddr();
  command ieee154_laddr_t getExtAddr();
  command error_t setShortAddr(ieee154_saddr_t addr); 
  event void changed();
}

This should be implemented by the Ieee154AddressC component. This interface assumes that the extended address is based upon the EUI-64 retrieved from LocalIeeeEui64C and never changes. It is recommended that the short address and pan id be initialized from TOS_NODE_ID and TOS_AM_GROUP, with a few caveats:

• By default blip will not use short addresses and so TOS_NODE_ID will have no effect
• am_group_t is only 8 bits wide. Implementations should use the ieee154_panid_t type in Ieee154.h to refer to a panid.
• The byte order is reversed when converting between an ieee_eui64_t and an ieee154_laddr_t. The eui64 is stored in canonical (big-endian) order; however since the IEEE 802.15.4 spec specifies little-endian, the laddr should be reversed to match the expected byte order of the radio.

This interface should be provided by the radio; currently the implementation for CC2420 is located in the blip directory; this must be moved.

TODOs

• IPDispatchC should reference a generic Ieee154 component, something like BareIeee154C or something.
• Ieee154AddressC should be moved to the cc2420/ chip directory
• We should add a generic way of reading out LQI information so we can provide link metadata inside of the received packet metadata.