Academic team project — Computer Networks course. We investigate whether 5G Cellular-V2X (C-V2X) can actually meet the brutal latency and reliability budgets that Level 4/5 autonomous driving demands — not in theory, but in real EU cross-border field trials. This README is the full write-up: the problem, the architecture, the evidence, and the honest trade-offs.
~15 min read · Last updated June 2026 · Full English write-up, figure-driven, with cited sources.
(Click the thumbnail above. GitHub does not embed video players, so the standard convention is a thumbnail that links out to the hosted recording.)
- TL;DR
- Background & Motivation
- The Problem: Why Best-Effort Networks Fall Short
- Approach & Methodology
- The Solution: 5G C-V2X Architecture
- Technical Enablers: MEC & Network Slicing
- The Evidence: Field Trials & Verification
- Trade-offs, Limitations & Engineering Q&A
- Conclusion & Future Work
- Glossary (Acronyms)
- References
- Team & Repository
- License & Attribution
- The gap: Safety-critical driving services (collision avoidance, platooning, remote driving) need < 10 ms latency and > 99.99% reliability. LTE (~50 ms) and DSRC/802.11p (no QoS guarantee) cannot deliver this deterministically. [1][6]
- The fix: 5G C-V2X (3GPP Rel-16) combines PC5 direct sidelink, Uu cellular, MEC edge computing, and network slicing into one architecture that can be tuned per service class. [6]
- The proof: EU cross-border trials (5G-DRIVE, 5G-MOBIX, 5GCroCo, 5GCAR) report all target KPIs met under live multi-operator, cross-border conditions — including ~5 ms end-to-end remote driving and continuous platooning through coverage gaps. [4][5][7][8]
- The catch: "KPIs met in a trial" ≠ "guaranteed everywhere." Dense urban congestion, handover spikes, and PC5 spoofing remain genuine engineering risks — addressed by sensor fusion, redundancy, congestion control, and PKI, but not fully solved. (See Trade-offs.)
Autonomous driving is no longer a "smart car in isolation" problem — it is a network-centric system. Vehicles must continuously exchange state with each other (V2V), with roadside infrastructure (V2I), with the network/cloud (V2N), and with pedestrians (V2P). [1][2]
This shift is visible in the 3GPP standards themselves: LTE-V2X (Rel-14, 2017) introduced basic sidelink safety messaging, and NR V2X (Rel-16, 2020) turned vehicular communication into a first-class citizen of 5G with enhanced sidelink, Uu integration, and URLLC support. [6]
Why it matters in the real world. These systems are safety-critical: a dropped or late message is not a buffering annoyance, it is a potential collision. Applications like cooperative driving and remote control demand ultra-low latency and high reliability simultaneously — exactly the combination that traditional best-effort networking was never designed to provide. [5][6]
Job-ready value. The technologies surveyed here — URLLC, sidelink, Multi-access Edge Computing (MEC), and network slicing — are the working vocabulary of modern networking, cloud infrastructure, and autonomous-mobility engineering.
The core challenge is determinism. Conventional IP networks deliver "best effort" — fast on average, but with no guarantee on the worst case. For autonomous driving, the tail is what kills you.
| Legacy option | Limitation |
|---|---|
| LTE (Uu) | ~50 ms latency — too slow for safety-critical V2X [1][6] |
| DSRC (IEEE 802.11p) | Limited range, contention-based access, no QoS guarantee [6] |
Neither legacy technology can guarantee deterministic performance. Against this, the service-level targets for Level 4/5 autonomy are demanding: [1][6]
| Requirement | Target |
|---|---|
| Latency | < 10 ms |
| Reliability | > 99.99% |
Logical deduction: if the average must be a few milliseconds and the failure rate must be below 1-in-10,000, then the network can no longer treat all traffic equally. It must be able to reserve, prioritize, and shorten the physical path of safety traffic. That requirement is what drives every architectural choice in the rest of this report.
This is a literature-review + comparative case-study project (no lab hardware). We triangulate three classes of source:
Concept ──▶ Industry Adoption ──▶ Use Cases ──▶ Experimental Results
(3GPP/5GAA) (OEMs, telcos, (platooning, (5G-DRIVE, 5G-MOBIX
chipset vendors) remote driving) cross-border trials)
- Standards & requirements: 3GPP TR/TS releases and 5GAA service-level requirement reports. [1][2][3][6]
- Interfaces & enablers: PC5 vs Uu, MEC-based latency reduction, network slicing. [6]
- Real-world validation: EU projects 5G-DRIVE, 5GCroCo, 5G-MOBIX, 5GCAR. [4][5][7][8]
The deliberate design here is to follow one logical chain: standardized requirement → architectural mechanism → measured field result. Each KPI claim later in this document is traced back to a trial, not a spec sheet.
NR V2X did not appear overnight. Rel-14 delivered the sidelink concept; Rel-15 laid the 5G NR foundation and formalized V2X service requirements; Rel-16 completed the picture — enhanced sidelink + Uu integration + URLLC — unlocking all four advanced use cases (platooning, extended sensors, advanced driving, remote driving). [6]
Figure 1 — 3GPP V2X release timeline. Phase 01 (basic V2V) → Phase 02 (platooning, extended sensors, advanced/remote driving) → Phase 03 (5G URLLC: low latency, high bandwidth, ultra-high reliability). Source: [6].
Figure 2 — V2X communication modes. V2V (direct, PC5 sidelink), V2I (to roadside RSU), V2N (to network via Uu → gNB/MEC), V2P (pedestrian safety alerts). Source: [6].
The architectural heart of C-V2X is that it does not force a single radio path. It offers two complementary interfaces and, under NR V2X, runs them together.
| PC5 (sidelink) | Uu (cellular) | |
|---|---|---|
| Path | Direct device-to-device | Vehicle → gNB → core/edge |
| Infrastructure | None required | Needs network |
| Strength | Lowest latency, works in coverage gaps | MEC + network slicing, wide reach |
| Best for | Collision avoidance, local cooperation | Remote driving, cloud/control-center |
NR V2X Dual Mode (Rel-16): uses both interfaces simultaneously to provide redundancy for safety-critical services — if one path degrades, the other carries the traffic. [6]
Logical deduction: redundancy is not a luxury here, it is the mechanism that converts two "best-effort-ish" links into one near-deterministic service. This single idea — diversity of path — reappears in every trial result in Section 6.
The main legacy alternative for direct vehicular communication is DSRC (IEEE 802.11p). It works, but its Wi-Fi-derived, contention-based design does not scale to safety-critical density. C-V2X (PC5) was engineered specifically to fix those gaps:
| Dimension | DSRC (IEEE 802.11p) | C-V2X (PC5 / NR sidelink) |
|---|---|---|
| Channel access | CSMA/CA — contention-based, collisions rise with density | Sensing-based / scheduled resource selection |
| Range | ~300 m | ~1 km+ under NR V2X enhancements |
| Latency | No deterministic guarantee | Sidelink < 3 ms (Rel-16 NR V2X) |
| Reliability / QoS | No QoS guarantee | URLLC > 99.999% for safety services |
| Scalability | Degrades under high vehicle density | Designed for dense, high-mobility traffic |
| Cellular synergy | Standalone only | PC5 + Uu → MEC, network slicing, wide-area reach |
| Evolution path | Largely static | Clear 3GPP roadmap (Rel-14 → 16 → 17+) toward 5G/6G |
Takeaway. C-V2X does not merely match DSRC — it removes the two structural ceilings (contention and lack of QoS) that made best-effort approaches unsuitable for autonomous driving in the first place, while inheriting the full 5G toolbox (MEC, slicing, URLLC). Source: [1][6]; DSRC-vs-C-V2X comparison is part of this project's defined research scope.
Different services have wildly different budgets. The architecture must satisfy the strictest one (remote driving) without over-provisioning the rest. [1][2][3][6]
| Service | Latency | Reliability | Data Rate |
|---|---|---|---|
| Forward Collision Warning | < 100 ms | > 99% | — |
| Cooperative Lane Change | < 100 ms | > 99.9% | — |
| Platooning | < 25 ms | > 99.99% | — |
| Remote Driving | < 5 ms | > 99.999% | > 25 Mbps UL |
⚠️ These are 3GPP-defined target requirements, not measured trial results. Measured results appear in Section 6. Source: [1][2][3][6].
You cannot beat the speed of light, so you shorten the distance. MEC — Multi-access Edge Computing (originally Mobile Edge Computing) — moves the V2X application server from a distant cloud down to the base station, collapsing round-trip latency from ~50 ms (cloud) to < 5 ms (edge). [1][6]
Figure 3 — MEC-based latency reduction. Processing at the edge enables real-time cooperative perception and remote control. Source: [1][6].
MEC shortens the path; network slicing reserves it. A single physical 5G network is partitioned into isolated logical slices so that an emergency-brake message is never queued behind a passenger's video stream: [1][6]
- URLLC slice (safety): latency < 1 ms, reliability > 99.999% — dedicated to safety messages.
- eMBB slice (infotainment): > 25 Mbps — video, map updates, non-safety traffic.
- Remote-driving slice: isolated from best-effort traffic, guaranteed per-service QoS.
Logical deduction: MEC + slicing together are what turn the targets in §5.1 into something an operator can actually commit to — they address latency (distance) and reliability (contention) respectively, the two ways best-effort networks failed in Section 2.
Architecture is a promise; trials are the receipt. We examined four EU projects; the strongest evidence comes from 5G-DRIVE (controlled comparison) and 5G-MOBIX (live cross-border).
EU–China joint project, tested on UK motorway and urban corridors. [4]
Figure 4 — 5G-DRIVE measured results. 5G NR V2X outperforms LTE-V2X on every KPI: average latency 19 ms → ~5 ms, and packet error rate ~1% → ~0.01% (reliability > 99.99%). Source: [4].
This is the cleanest data point in the study: holding the test environment fixed and swapping only the radio technology isolates the gain attributable to 5G NR V2X itself.
| Problem | Applied Technology | KPI (Requirement) | Result |
|---|---|---|---|
| Coverage gaps disrupt convoy continuity at the GR–TR border | 5G NR V2X + eRSU roadside units; "See-What-I-See" real-time video over PC5/Uu | Latency < 10 ms, Reliability > 99.99%, Rate 10–100 Hz | ✅ All KPIs met under live cross-border conditions; eRSU maintained convoy continuity through coverage gaps [7] |
Figure 5 — GR–TR platooning trial. Source: [7].
Figure 6 — Platooning user stories. (top) "See-What-I-See" video sharing in a cross-border setting; (bottom) eRSU-assisted platooning with handover between platooning service areas. Source: [7].
| Problem | Applied Technology | KPI (Requirement) | Result |
|---|---|---|---|
| Driverless shuttle needs an uninterrupted control signal across the ES–PT border | 5G NR V2X + dual-network redundancy; remote control center via Uu | E2E latency < 5 ms, Reliability > 99.999%, UL > 25 Mbps | ✅ All KPIs confirmed live; dual-link held the control signal through cross-border handover [7] |
Figure 7 — ES–PT remote-driving trial. Source: [7].
Figure 8 — Remote-driving user stories. (top) Automated shuttle handing off to remote control across a border; (bottom) remote driving in a redundant (dual-network) environment. This is the redundancy principle from §4.3, in production. Source: [7].
Figure 9 — KPI compliance. Across platooning, remote driving, and the 5G-DRIVE comparison, measured results met the 3GPP Rel-16 targets. Source: [4][5][6][7][8].
| Trial / Use Case | Requirement | Reported Result | Status |
|---|---|---|---|
| Platooning (Greece–Turkey) | < 10 ms / 99.99% | < 10 ms / 99.99% | ✅ Met |
| Remote Driving (Spain–Portugal) | < 5 ms / 99.999% | < 5 ms / 99.999% | ✅ Met |
| 5G NR V2X (5G-DRIVE) | < 5 ms / 99.99% | ~5 ms / 99.99% | ✅ Met |
Putting it together — the full chain holds: 3GPP standard → architectural mechanism (PC5/Uu + MEC + slicing) → industry deployment → measured cross-border field result. Each link is cited; none is assumed.
A result that only reports its wins is marketing, not engineering. The concerns below were raised in our live audience Q&A session. Rather than answer them in one line, we unpack each as Problem → Solution → Trade-off, because every architectural strength in this design carries a cost or an unresolved question.
Legend: 🔴 Problem = the concern · 🟢 Solution = how C-V2X handles it · 🟡 Trade-off = the residual cost / open question.
❓ "When two networks deliver conflicting information, how do you decide what to trust? And if the vehicle providing the 'See-What-I-See' video loses signal, what happens to the cars relying on it?"
🔴 Problem — Two independent radio paths (PC5 + Uu), plus cross-vehicle video sharing, can deliver contradictory or stale data. In a safety-critical loop, blindly trusting any single message — or any single video stream — is dangerous.
🟢 Solution — The system is designed so that no single source is trusted absolutely:
- Timestamp + sequence numbers on every message let the vehicle identify the freshest data.
- Sensor fusion cross-validates incoming V2X data against the car's own Camera / LiDAR / Radar.
- PC5 + Uu dual-mode provides path redundancy (see §4.3); "See-What-I-See" is an assistive layer on top of each vehicle's own sensors, not a sole dependency — if one stream or link drops, other sensors and paths carry on.
- Under low confidence, the vehicle falls back to conservative behavior (reduce speed / safe mode).
🟡 Trade-off — This robustness assumes redundancy and fusion are always available; driving single-point-of-failure risk to zero is an ongoing goal, not a solved state. The price is added arbitration complexity and the hard requirement that every vehicle carry a full local sensor suite. [6]
❓ "You achieved ~5 ms in the experiment — can you guarantee the same in a real city? And what about MEC-server failure, or handover into a different base station's MEC region?"
🔴 Problem — The < 5 ms / 99.999% numbers in §6 are reported trial results, and the values in §5.1 are 3GPP targets — neither is a blanket guarantee under every dense-urban condition (vehicle density, building multipath, congestion, handover transients).
🟢 Solution — The evidence is stronger than a lab bench: the 5G-MOBIX / 5GCroCo trials ran in real, cross-border, multi-operator environments — where the network and the country/operator change mid-drive, the hardest continuity case rather than the easiest. [5][7][8] For MEC failover and mobility, real deployments use distributed MEC and dual-network redundancy, pre-establishing the next edge connection before the handover completes.
🟡 Trade-off — A handover can still produce a transient latency spike — perfect continuity is not claimed. The honest reading: the trials demonstrate strong feasibility, and production systems hold the line under degradation through MEC + slicing + congestion control + redundancy + an explicit fallback / safe-mode path. [1][6]
❓ "Does PC5 still work when hundreds of vehicles converge at rush hour? And can wireless alone keep reliability high for a hard-braking event — isn't that detected by the car's own sensors first?"
🔴 Problem — PC5 sidelink shares a finite radio resource; at rush-hour density, resource collisions and congestion are real. And for the very hardest safety loop — emergency braking — relying on a wireless link at all is questionable.
🟢 Solution — NR V2X manages contention with sensing-based resource selection, QoS-based prioritization, and congestion control; platooning further smooths flow through synchronized cooperative driving. Critically, the fast safety loop does not depend on wireless: in-vehicle wired networks (CAN, automotive Ethernet) and on-board sensors execute emergency braking locally, while V2X extends perception beyond line-of-sight (warning vehicles further away or out of view) rather than replacing the internal control path.
🟡 Trade-off — Congestion control is a managed compromise, not unlimited capacity; at extreme density no single wireless link can guarantee everything. Reliability therefore emerges from a layered system — wired buses + on-board sensors + PC5/Uu + MEC + redundancy — which is more robust but raises integration cost and complexity.
❓ "Because PC5 talks device-to-device without the base station, isn't it more vulnerable to a device that spoofs a legitimate vehicle — especially when crossing a border?"
🔴 Problem — Since PC5 is direct sidelink, a malicious device could impersonate a normal vehicle and inject false messages — a risk amplified across borders, where trust spans multiple operators and nations.
🟢 Solution — C-V2X does not trust a signal merely because it arrived. It layers authentication + message-integrity verification, generally via PKI (Public Key Infrastructure) and digital signatures, so only authenticated vehicles / infrastructure can issue trusted messages. EU cross-border projects explicitly evaluated interoperability and trust, not just raw throughput.
🟡 Trade-off — This is mitigation, not closure: spoofing / malicious-node resistance remains an open research problem, and PKI itself adds key-management and cross-operator trust overhead that grows with the number of participating domains.
❓ "If 5G NR V2X already satisfies almost every requirement, why do we still need 6G or AI-based resource scheduling? What is actually lacking?"
🔴 Problem — NR V2X already performs excellently on latency, reliability, and continuity, and field trials confirm its applicability — so the need for further evolution is not self-evident.
🟢 Solution / Outlook — Next-generation autonomy raises the bar: ultra-HD real-time video sharing, cooperative perception, digital twins, AI-based real-time decision-making, plus surging vehicle counts, ultra-dense urban areas, and UAV / smart-city integration. These demand not just low latency but resource efficiency, real-time prioritization, and massive connectivity — motivating AI-based resource scheduling (to triage critical / emergency traffic) and 6G (AI-native networking, integrated sensing & communication, ultra-low latency, digital-twin support).
🟡 Trade-off — NR V2X is sufficient for today's validated use cases; 6G / AI is about scaling to tomorrow's workloads — at the cost of yet another full standardization-and-deployment cycle.
❓ "Who should realistically lead this infrastructure investment — automakers, carriers, or government?"
🔴 Problem — Even with the technology proven, the non-technical barriers dominate commercialization: deployment cost, cross-operator interoperability, and stakeholder coordination.
🟢 Solution — No single actor can build this alone. A realistic division of labor: carriers operate the 5G + MEC + slicing network; automakers integrate on-board sensors and C-V2X into vehicles; government / public bodies provide RSUs, road infrastructure, standardization, and regulation. The 5G-MOBIX / 5GCroCo trials are themselves proof of this model — multi-national collaborations spanning governments, carriers, OEMs, and research institutes. [5][7]
🟡 Trade-off — A camera-only, single-vendor approach (e.g., Tesla) sidesteps the coordination problem but cannot fully resolve out-of-sight hazards or cooperative driving; the cooperative path requires sustained public–private coordination, which is slower and politically harder than a single company's roadmap.
5G C-V2X meets the strict latency and reliability requirements of safety-critical autonomous driving, and — crucially — this is backed by real-world EU cross-border validation (5G-MOBIX, 5G-DRIVE), not simulation alone. The end-to-end technology flow is confirmed: 3GPP standards → industry deployment → field verification. [4][5][6][7][8]
The limitations in Section 7 point directly to the research frontier:
- 6G V2X — AI-native networking, integrated sensing & communication (ISAC), ultra-low latency.
- AI-based resource scheduling — prioritizing critical/emergency traffic under massive, ultra-dense connectivity.
- Digital-twin integration — for cooperative perception at city scale.
- Hardening security — robust anti-spoofing and trust management across operators and borders.
- Commercialization — managing deployment cost and cross-operator interoperability through sustained public–private coordination.
| Term | Meaning |
|---|---|
| C-V2X | Cellular Vehicle-to-Everything |
| V2V / V2I / V2N / V2P | Vehicle-to-Vehicle / -Infrastructure / -Network / -Pedestrian |
| PC5 | Direct device-to-device sidelink interface (no base station) |
| Uu | Cellular interface between a device and the base station (gNB) |
| gNB | Next-generation Node B — the 5G NR base station |
| RSU / eRSU | Road Side Unit / enhanced RSU |
| MEC | Multi-access Edge Computing (formerly Mobile Edge Computing) |
| URLLC | Ultra-Reliable Low-Latency Communication |
| eMBB | enhanced Mobile Broadband |
| QoS | Quality of Service |
| KPI | Key Performance Indicator |
| PER | Packet Error Rate |
| DSRC | Dedicated Short-Range Communications (IEEE 802.11p) |
| LTE / NR | Long-Term Evolution (4G) / New Radio (5G) |
| 3GPP / Rel | 3rd Generation Partnership Project / Release |
| CCAM | Cooperative, Connected and Automated Mobility |
| ISAC | Integrated Sensing and Communication |
| PKI | Public Key Infrastructure |
| E2E / UL | End-to-End / Uplink |
| UAV | Unmanned Aerial Vehicle |
IEEE format. Citation indices [n] throughout this document map to this list. Links point to the
publisher, the issuing organization, or the official project deliverables page.
| # | Reference |
|---|---|
| [1] | 5GAA, "C-V2X Use Cases: Methodology, Examples and Service Level Requirements (Vol. I)," 5G Automotive Association, 2019. [5gaa.org] |
| [2] | 5GAA, "C-V2X Use Cases and Service Level Requirements, Vol. II," 5G Automotive Association, Tech. Rep. v2.0, 2020. [5gaa.org] |
| [3] | 5GAA, "C-V2X Use Cases and Service Level Requirements, Vol. III," 5G Automotive Association, 2022. [PDF] |
| [4] | 5G-DRIVE Consortium, "Final Report of V2X Trials," 5G-DRIVE Project Deliverable D4.4, EU H2020, 2021. [PDF] |
| [5] | 5G-PPP, "5G for CCAM in Cross-Border Corridors," 5G Infrastructure Public Private Partnership White Paper, 2020. [5g-ppp.eu] |
| [6] | M. J. Khan et al., "Advancing C-V2X for Level 5 Autonomous Driving from the Perspective of 3GPP Standards," Sensors, vol. 23, no. 4, art. 2261, Feb. 2023. [MDPI] · [doi:10.3390/s23042261] |
| [7] | 5G-MOBIX Consortium, "5G-Enabled CCAM Use Cases and Specifications," 5G-MOBIX Project Deliverable D2.1, v2.0, 2020. [deliverables] |
| [8] | 5G-PPP, "5G Infrastructure PPP — 10 Technical Priorities," 5G Infrastructure Public Private Partnership, Brochure, Nov. 2023. [PDF] |
Note on [6]. The slide deck's reference list cited this paper as "Z. Xu et al."; the correct first author is M. J. Khan et al. (verified via the publisher, MDPI Sensors). The corrected attribution is used here.
Background papers consulted beyond the cited references above. To respect third-party copyright, these are linked to their publishers rather than redistributed in this repository:
- H. Bagheri et al., "5G NR-V2X: Towards Connected and Cooperative Autonomous Driving," IEEE Communications Standards Magazine, 2021. [arXiv]
- H. Yang et al., "Ultra-Reliable and Low-Latency Communications for Connected Vehicles: Challenges and Solutions," IEEE Network, 2020. [arXiv]
- L. Yang, J. Cheng, M. Zhou et al., "Integrated Perception, Communication, and Computation for Autonomous Vehicle and Road Infrastructure Network," IEEE (early access). [IEEE Xplore]
- K. S. Gill, "Latency Analysis of Vehicle-to-Pedestrian C-V2X Communications at Urban Street Intersections," 2022. [arXiv]
- 5GAA, "C-V2X Use Cases Volume II: Examples and Service Level Requirements," 2020 (also cited as [2] above). [5gaa.org]
Team (Computer Networks course project)
| Member | Role |
|---|---|
| Sungjune Kong | Project lead; 3GPP standard evolution (Rel-14→16); C-V2X architecture (PC5/Uu); lead presenter |
| Junmok Lee | MEC & network slicing; 5G-MOBIX trial cases; slide design & production |
| Lana Kim | URLLC requirements & V2X scenarios; 5G-DRIVE D4.4 review; Q&A responses |
- Standards analysis — tracing 3GPP V2X from Rel-14 to Rel-16 and mapping service requirements to concrete mechanisms.
- Network architecture — PC5 vs Uu interfaces, MEC, and network slicing for deterministic, URLLC-grade communication.
- Evidence-based evaluation — linking standardized KPIs to measured EU cross-border field-trial results, not spec sheets.
- Critical analysis — honest trade-offs and open problems (congestion, handover, spoofing, deployment economics).
- Technical communication — a cited, figure-driven write-up with verified IEEE-format references.
.
├── README.md ← this tech blog (the full write-up)
├── LICENSE ← CC BY-NC 4.0 + third-party-figure notice
├── PresentationVideoLink ← YouTube link to the presentation recording
├── assets/ ← 9 figures embedded above (rendered from the team's slide deck)
└── .gitignore ← excludes internal source docs (report, Q&A, slides, 3rd-party PDFs)
Presentation recording: https://youtu.be/gk2YCNwvN5Q Figures in
assets/are rendered from the team's final presentation deck; see each figure caption for its original source citation.
- Original written content of this repository (the text of
README.md) — © 2026 Sungjune Kong, Junmok Lee, and Lana Kim — is licensed under CC BY-NC 4.0: you may share and adapt it for non-commercial purposes with attribution. - Figures in
assets/adapt diagrams and data from third-party sources (3GPP, 5GAA, 5G-MOBIX, 5G-PPP, and the cited papers). These remain the property of their respective rights holders and are included for academic, illustrative use — reusing them may require permission from the original source. - To cite or reuse, please credit the authors and link back to this repository.
Full terms are in LICENSE.