Markdown Version | Session Recording

Session Date/Time: 30 Apr 2024 14:00

SCHC

Summary

The SCHC Working Group met to discuss the status of ongoing work, including updates to the SCHC Architecture document, the launch of the Lab SCHC initiative, and the introduction of a Framework for Forward Error Correction (FEC) in SCHC. Key discussions revolved around new terminology in the architecture (stratums, discriminators), the open-sourcing of an embedded SCHC SDK, and the principles and limitations of XOR-based FEC for improving reliability over lossy links.

Key Discussion Points

• Working Group Status and Milestones:

  • The adoption of the IP protocol number for SCHC (initially from ITRG) was completed, but authors are still pending publication as an IETF draft. The March 2025 publication milestone for this draft is under review, with the possibility of acceleration or the WG taking over if the original author (Bob) remains unresponsive.
  • Discussion of the OAM draft was deferred due to the author's (Alexander) absence.
  • New document versions were noted for the SCHC Architecture (updated by Anna), Zero-Energy Device (v01), and a new FEC document by Yogos.
  • The FEC document's late start (expected end-2023 adoption) means it's currently behind 2023 milestones, with no new dates set.

• SCHC Architecture Document (v02) Update:

  • A new Terminology Section was introduced.
  • The term "Stratum" was introduced to replace "SCHC layer," avoiding confusion with OSI layers. A stratum represents a "cut" in the packet processing, potentially spanning parts of or multiple OSI layers.
  • The concept of a "Discriminator" was clarified as an external mechanism (e.g., IP address, port, or implicit in LPWAN) used to identify the specific SCHC instance within a stratum.
  • Management packets were introduced as a type of SCHC packet, alongside fragmentation and compression packets.
  • Discussion on management features highlighted the need to define how management packets (potentially using CoAP, Score/DTLS) interact with and modify the set of rules, and whether this should be detailed in the informational architecture draft or a separate specification. This path would likely require specific security considerations.
  • The SCHC Header format remains open, allowing definition of necessary fields (e.g., ID, CRC). Its compression follows RFC 8724 (DR_ID + Compressed Residue).

• Lab SCHC Initiative Presentation:

  • The Lab SCHC is a collaborative initiative between Activity and IMT Atlantic, aiming to foster SCHC development and adoption.
  • Its primary goal is to maintain compatibility between Activity's commercial IP core and Open SCHC (community-driven).
  • Activity's full SDK (for embedded systems) is being open-sourced and will be maintained by the Lab SCHC.
  • The roadmap includes releasing the first open-source version of the full SDK by end of June, with plans to test it at the Vancouver IETF Hakathon.
  • Integration of new features, specifically FEC, into Open SCHC and full SDK, is a key objective, with a full code release targeted by year-end.
  • Initial work has shown success with a compression-only example on an STM32L0 board communicating with Open SCHC, with fragmentation and reassembly testing next.
  • It was clarified that the open-sourced full SDK will be the Eleo implementation, stripped of proprietary components, and made compatible with Open SCHC.
  • The website lab-schc.fr provides more information.

• FEC for SCHC Framework Draft:

  • Presented as a mechanism to improve reliability on lossy LPWAN links by recovering lost fragments without retransmissions, especially beneficial in NoACK mode.
  • A generic inter-frame FEC mechanism based on the XOR operator was proposed. If a packet is fragmented into K fragments, an additional XOR fragment (F_additional = F1 XOR F2 ... XOR FK) allows recovery of any single lost fragment.
  • Examples for NoACK, ACK-on-Error, and ACK-Always modes demonstrated how XOR-FEC can recover lost fragments and reduce the number of retransmissions (including valuable uplink retransmissions).
  • Limitations identified include the XOR algorithm's loss tolerance of one missing fragment per window and the additional cost (energy, bandwidth) incurred by sending redundant fragments.
  • The need to formalize how to signal that a data unit is an XOR fragment and carries redundancy was highlighted as a critical next step.
  • Discussion points included the potential for exploring other FEC algorithms beyond XOR and approaches for signaling FEC within the SCHC framework, possibly using FCN values or dynamically adjusting window sizes. It was suggested that a simple default FEC (like XOR) should be mandatory, with the data model allowing for more complex, negotiated options.

Decisions and Action Items

• The discussion on tokenizer-based compression was deferred due to the presenter's absence.
• The discussion on the OAM draft was deferred to the next interim meeting in two weeks.
• The Lab SCHC project aims to release the first version of the open-source full SDK by end of June for testing at the IETF Hakathon in Vancouver.
• Yogos and Amor Bruno will work on formalizing the signalling mechanism for XOR-FEC in the draft-y.b-schc-fec-framework document.

Next Steps

• SCHC Architecture Document:
  • Continue discussion on the set of rule identification for each instance and stratum.
  • Define the rule format for integrating new features like OAM, Flow, FEC, and payload-specific rules.
  • Further discussion needed on the scope and placement of management specifics (architecture vs. separate draft).
• IP Protocol Number Draft: Authors (Bob) to publish the adopted document as draft-ietf-schc-ip-protocol-number. If this doesn't happen, the WG will consider taking over the document.
• Lab SCHC: Continue development and open-sourcing of the full SDK, focusing on fragmentation/reassembly and FEC integration.
• FEC Framework Draft: Address the signalling mechanism for redundant fragments. Consider exploring other FEC algorithms and potential interactions with streaming.