Issues & Roadmap

This document tracks three categories:

  1. Open questions — gaps, ambiguities, or structural concerns that need discussion or further evaluation before action can be taken.
  2. Pending source corrections — specific changes that should be made to upstream input documents (TVR, SAI, GTL, CTM, STM) but have not yet been applied there. Until they are, these corrections must be applied when processing the relevant source so that the DBR reflects the intended state rather than the current text.
  3. Planned enhancements — improvements to the test status system to be prioritised and scheduled as the programme progresses.

Open Questions

TVR §2.9.6 — Relationship to the Wider Test Set

TVR §2.9.6 defines the E2E performance tests confirmed for Phase 2 (Tables 2 and 3), and these are the tests reflected in e2e-scenarios.md and in the TVR E2E Scenarios (App. 1) entries within status cards. However, §2.9.6 covers only a specific slice of the overall test programme:

  • It lists E2E performance scenarios (e.g. B, E, G, M, …) assigned to testbeds, with KPIs focused on QoE and QoS metrics.
  • It does not capture the full breadth of Strand 2–6 tests, which additionally include functional tests, integration tests, and component-level test cases documented across the GTL sheets and the strand/WP technical notes.

The current dashboard structure does not make this layering explicit. A reader viewing the E2E Scenarios reference page may not readily understand that §2.9.6 is a performance-test overlay on top of a larger functional test programme, or that the GTL is the authoritative source for the complete set of test cases across all strands.

To consider: Whether the dashboard should surface this hierarchy more clearly — for example, by distinguishing E2E performance tests (§2.9.6) from functional/integration tests (GTL strand sheets) within each status card or reference page.


Pending Source Corrections

Changes below are intended for the listed source document but have not yet been made there. When reading or processing that source, apply the correction as if it were already present.

# Source Location Correction
1 GTL v3 — Strand 2 sheet All 13 WP2.1 rows The Responsible, Nature of test, Test level, and KPI columns are blank for every Strand 2 test. These fields should be populated by WP2.1 lead(s) to match the level of detail present in the Strand 3–6 sheets. Until corrected, the DBR represents these tests without Responsible or Nature metadata.
2 GTL v3 — Strand 3 sheet WP 3.1.5, rows 1–2 WP3.1.5 contains two distinct tests: (1) Brightcove player integration with the 5G-EMERGE test setup; (2) Verification of traceability of HTTP GET requests from Open Telemetry clients on the Open Telemetry collector (Responsible: SES / FTA / G-Core / RAI / Brightcove). The DBR previously merged these into a single row. The GTL is correct; the DBR has been corrected to reflect two separate entries (S3-T9 and S3-T10).
3 GTL v3 — Strand 4 sheet WP 4.1.3 Three test descriptions present in earlier DBR versions (Multicast reception; Tracking satellite; Strand 2 integration) do not appear in GTL v3, which lists six WP4.1.3 tests: Closing the link; RTN link protocols switch (5G orchestrator); Live TV over NTN; VoD over NTN; Internet connectivity over NTN; ARCA SATCOM VPN. The DBR has been corrected to match GTL v3. If the three absent titles represent real tests (e.g. from a prior GTL version or TVR), they should be reinstated in the GTL by the WP4.1 lead.
4 GTL v3 — Strand 2 sheet WP 2.1 scenario list TVR Appendix 1 includes Scenarios I and C.1 which were not present in the GTL v3 Strand 2 sheet. As of 12 Apr 2026, a testbed (Arctic Space) is confirmed for both scenarios and they have been moved to performable (A.1) in the DBR's E2E Scenarios reference. The DBR now tracks both scenarios. Action required: verify whether GTL v3 in cache/ has been updated to include Scenarios I and C.1 in the WP 2.1 list. If the GTL still omits them, this remains a pending source correction; if it now includes them, this row can be removed.

Planned Enhancements

Improvements to be prioritised and scheduled as the programme progresses.

  • Deep linking between cards and knowledge — direct links from status card fields to the relevant reference doc section
  • Data card restructure — test data should move to a dedicated data area in the form of data cards, which are then pulled into pages
  • Project branding — logo, colours, and consortium partner names from the 5G-EMERGE website
  • Integration with issue tracking and observability tooling — e.g. Trello, Grafana
  • Trend tracking across reporting cycles — heatmaps, sparklines showing progress over time
  • CI/CD validation for card completeness — automated checks that required fields are populated
  • Bidirectional sync — DBR results (KPI actuals, risk flags, new test cases) flowing back to update GTL, TVR, and CTM on SharePoint (see Information Flow section in Information Sources)