IETF 103 Hackathon LPWAN

Cedric Adjih edited this page Nov 19, 2018 · 28 revisions

Quick links

Rememberable link https://tinyurl.com/lpwan-hackathon103
openschc code https://github.com/openschc/openschc
Other SCHC code https://github.com/openschc/doc/wiki/Code-and-Repositories
Tasks (old) https://github.com/openschc/doc/projects/1
Scenario (initial one) Initial Diagrams describing scenario and code structure
Draft -hc17 schc draft 17
Etherpad (live notes) https://etherpad.tools.ietf.org/p/openschc (not used)

Post-Hackathon write-up

Logistics

This page was about LPWAN Hackathon Project occurring at the IETF 103 Hackathon.

Details for our own logistics to be announced.

Remember to register to the hackathon: https://www.ietf.org/registration/ietf103/hackathonregistration.py

For other LPWAN activities at IETF 103 see also the IETF103 LPWAN meeting agenda.


Objective and planning

Below are given some objectives, testings, scenarios, etc. already envisioned by some participation. Variations are welcome: the more hacking/testing, the meerier!

  • Objective: one primary objective is to test the revised fragmentation mode with ACK-on-error introduced in SCHC draft-17.

  • Testing: the test will be primarily on through exchanging UDP packets.

    • For interoperability (or just interacting with fellow participants), one participant would set up a UDP receiver (defragmenter), and another would send UDP packets.
    • The UDP port will be 44048
  • Scenario: The reference scenario will be as follows:

    • The reference "ACK on error" SCHC fragmentation parameters for the Hackathon are:

      • ruleID : 6 bits
      • DTAG: 2 bits
      • Window: 5 bits
      • FCN: 3 bits
      • the above parameters allow having a header aligned on byte boundaries
      • MAX_WIND_FCN: 6
      • tile size: 30 bytes
      • The MIC will be the default MIC specified by the draft.
      • The L2 Word is one byte.
    • First scenario:

      • Each SCHC Fragment message carries exactly one tile.
      • The fragment sender will only expect a SCHC ACK after it transmits an All-1 SCHC Fragment or after it transmits a SCHC ACK REQ. It will expect at most one SCHC ACK in either of those circumstances.
      • The fragment receiver (i.e. reassembler) is allowed to send at most one SCHC ACK after the reception of:
        • an All-1 SCHC Fragment
        • or a SCHC ACK REQ.
    • Advanced scenario:

      • In a second step, we will send several tiles per SCHC Fragment message.

Tools used in Hackathon

See: https://github.com/openschc/doc/wiki/Code-and-Repositories


Resources

People's role in the SCHC work session at the IETF103 Hackathon

  • Laurent Toutain (locally): inspirational guru, architect
  • Dominique Barthel (locally): draft exegete, tester
  • Cedric Adjih (locally): architect, developper
  • Shoichi Sakane (locally): architect, lead developper
  • Thongchai Chuachan (locally): developper

View the list of registered IETF103 Hackathon Attendees

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.