====== 6LoWPAN Retransmissions ======

====== Implementierung ======

**Fragmentierung:** ''contiki-2.4/core/net/sicslowpan.c''

Process a received 6lowpan packet:
  static void input(const struct mac_driver *r)


Take an IP packet and format it to be sent on an 802.15.4:
  static u8_t output(uip_lladdr_t *localdest)
  
**Fragmentierung ein/ausschalten:** ''contiki-2.4/core/net/sicslowpan.c''
  /**
   * Do we support 6lowpan fragmentation
   */
  #ifndef SICSLOWPAN_CONF_FRAG  
  #define SICSLOWPAN_CONF_FRAG  0
  #endif

**Frame-Acknowledge Contiki 2.4**

mac/mac.h \\
mac/csma.c
	csma_init() setzt den mac_driver (mac) - Welcher wird verwendet?

''CSMA_CONF_REXMIT'': steuert Retransmission (1x on Unicast frames)

	send_packet()
		ret=mac->send();
		MAC_TX_NOACK

Was bedeutet folgendes Attribut (siehe auch Link zu Contiki 2.5)?
''PACKETBUF_ATTR_RELIABLE''


**Frame-Acknowledge Contiki 2.5**

http://sourceforge.net/mailarchive/message.php?msg_id=28765040


**IPv6-Routing**

http://sourceforge.net/mailarchive/message.php?msg_id=28828038


====== Testplan ======

**Idee:** Erstellung eines zuverlässigen und nachvollziehbaren Tests für die Überprüfung der Entwicklung (Erstellung einer Baseline für Verbesserungen/Verschlechterungen),
bzw. für den Vergleich zwischen verschiedenen Contiki-Versionen.

**Vorgehensweise:** \\
  - Die Tests werden in unterschiedlichen Entfernungen (1m, 3m, 5m, 8m, 10m, 15m) durchgeführt. Aus den Entfernungen ergeben sich unterschiedliche RF Charakteristiken, die sich dahingehend auswirken, dass 6LoWPAN Frames verloren gehen. Um Störeinflüsse aus der Umgebung auszuschließen (zu mitteln) sollten die Tests
  - Contiki (2.4-only?) soll angeblich Re-Transmissions (Acknowledge) auf 6LoWPAN-Ebene nutzen. Ist das Ausschaltbar? Die Tests sollten jeweils mit und ohne dieser Funktion durchgeführt werden. (Bisher habe ich da noch keinen Code für gefunden - evtl. noch mal Adam Dunkels fragen, bzw. Debug-Code in die Paketverarbeitung einbauen)
  - Jeder Test sollte jeweils 100 mal wiederholt werden und dann die Mittelwerte der Tests verglichen werden.

**Ansätze:** 
  - HTTP-basiert:
    - Contiki-Webserver wird mittels Testtool abgefragt und die Performance ermittelt
    - http://jakarta.apache.org/jmeter/usermanual/build-web-test-plan.html
  - ICMP-basiert:
    - ICMP Pakete mit unterschiedlichen Packetgrößen (klein(64), mittel(512), groß (1280) )
    - Vorteil: sollte mit Standard-Contiki funktionieren (keine Applikation erforderlich) 

====== Zu Beachten ======
=== Ausgabe der 6LoWPAN-Frames ermitteln ===
Bei Contiki 2.4 sieht man die 6-LoWPAN-Fragmente im Wireshark. Ist das bei 2.5 immer noch so? Wenn nicht, was müsste ggf. angepasst werden, bzw. könnten wir eine eigene
Ausgabe bei Fehlern in den Code einbauen **TODO!**

Mir ist dabei nirgends aufgefallen, dass für fehlerhafte Frames eine Retransmission durchgeführt würde.

''platform/avr-ravenusb/sicslow_ethernet.c''
  void mac_LowpanToEthernet(void)
  
ruft auf: 
  
''cpu/avr/radio/mac/sicslowmac.c''
  parsed_frame_t * sicslowmac_get_frame(void)


Unklar ist mir derzeit noch, wie der normale Contiki TCP-Stack die Pakete aus dem 6LoWPAN holt und ggf. die
Prüfsumme überprüft. **TODO!**

Hilfreich für die Codeanalyse ist http://www.stack.nl/~dimitri/doxygen/

=== Ggf. RSS ermitteln und mit printf über Debug ausgeben ===
In radio.h gibt es die Funktion: ''uint8_t radio_get_saved_rssi_value(void)''\\
Laut diesem Dokument: http://www.atmel.com/dyn/resources/prod_documents/doc5131.pdf
berechnet sich die Empfangsstärke wie folgt:

The RSSI is a 5-bit value indicating the receive power in the selected channel, in steps of 3 dB.
  * Minimum RSSI sensitivity is -91 dBm (RSSI_BASE_VAL)
  * Dynamic range is 81 dB
  * Minimum RSSI value is 0
  * Maximum RSSI value is 28


An RSSI value of 0 indicates an RF input power of < -91 dBm.
For an RSSI value in the range of 1 to 28, the RF input power can be calculated as follows:
PRF = RSSI_BASE_VAL + 3*(RSSI - 1)