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

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:

1. 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
2. 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)
3. Jeder Test sollte jeweils 100 mal wiederholt werden und dann die Mittelwerte der Tests verglichen werden.

Ansätze:

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

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/

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)