5G-ENSURE Security research archive

Work packages 2 to 5 · Public documents

The 5G-ENSURE deliverables: the complete H2020 document archive

The 5G-ENSURE deliverables in full: 23 public deliverables, 2,673 pages, delivered between February 2016 and February 2018. Each is served at the address it was published under, and each can be downloaded directly.

DHoldings

What the H2020 document archive holds

5G-ENSURE was a research project in the first phase of the 5G Public-Private Partnership, funded under Horizon 2020 as grant agreement 671562, call H2020-ICT-2014-2. Its public output was a set of deliverables: the use cases and risk assessment that framed the problem, a security architecture and a trust model, specifications for the enablers built against them, a testbed and its evaluation, and the project’s own reporting.

Taken together the 5G-ENSURE deliverables are a single argument in four parts, which is why this H2020 document archive is worth reading as a set. Work package 2 establishes what a 5G network has to defend and what it should guarantee. Work package 3 turns that into components. Work package 4 tries them on a testbed and reports what happened. Work package 5 records how the results were carried into standards bodies and to the wider public.

Several documents exist in more than one edition, and both editions are here. A draft and a final are different documents with different numbers, not versions of one file, and a reference to the draft should resolve to the draft.

Figure 1 Flat archival drawer
A pulled-open flat archival storage drawer in a grey steel cabinet, holding tightly packed upright card folders seen from above.
Figure 1. The documents are held at the addresses they were cited under. A reference published years ago resolves to the same file it resolved to then.

WPIndex

The 5G-ENSURE deliverables by work package

Page counts and delivery dates are read from each document’s own cover page. Selecting a title opens the PDF at its original address.

WP2 · Security architecture

  • D2.1

    Use cases 79 pages · delivered 1 Feb 2016

    PDF
  • D2.2

    Trust model (draft) 71 pages · delivered 22 Nov 2016

    PDF
  • D2.3

    Risk assessment, mitigation and requirements (draft) 90 pages · delivered 23 Aug 2016

    PDF
  • D2.4

    Security architecture (draft) 68 pages · delivered 31 Oct 2016

    PDF
  • D2.5

    Trust model (final) 213 pages · delivered 7 Feb 2018

    PDF
  • D2.6

    Risk assessment, mitigation and requirements (final) 205 pages · delivered 15 Nov 2017

    PDF
  • D2.7

    Security architecture (final) 81 pages · delivered 31 Oct 2017

    PDF

WP3 · Enablers

  • D3.1

    Security enablers technical roadmap, early vision 99 pages · delivered 11 Mar 2016

    PDF
  • D3.2

    Security enablers open specifications, v1.0 190 pages · delivered 1 Jun 2016

    PDF
  • D3.4

    Security enablers documentation 229 pages · delivered 30 Sept 2016

    PDF
  • D3.5

    Security enablers technical roadmap (update) 112 pages · delivered 30 Nov 2016

    PDF
  • D3.6

    Security enablers open specifications, v2.0 294 pages · delivered 1 May 2017

    PDF
  • D3.9

    Security enablers technical roadmap (final) 96 pages · delivered 30 Sept 2017

    PDF

WP4 · Testbed

  • D4.1

    5G security testbed architecture, v1.0 60 pages · delivered 30 Jun 2016

    PDF
  • D4.2

    Test plan, v1.0 56 pages · delivered 2 Dec 2016

    PDF
  • D4.3

    Test plan (final) 190 pages · delivered 20 Feb 2018

    PDF
  • D4.4

    Evaluation of the security enablers: results of the testbed runs 97 pages · delivered 16 Nov 2017

    PDF
  • D4.5

    Testbed extension and operation plan 44 pages · delivered 25 Oct 2017

    PDF

WP5 · Communication and exploitation

  • D5.1

    Web platform 23 pages · delivered 1 Feb 2016

    PDF
  • D5.2

    First report on communication, marketing and standardisation 69 pages

    PDF
  • D5.3

    Second report on communication, marketing and standardisation 87 pages · delivered 31 Oct 2016

    PDF
  • D5.4

    First market analysis and exploitation report 30 pages

    PDF
  • D5.5

    Third report on communication, marketing and standardisation 190 pages · delivered 30 May 2017

    PDF

URLAccess

How to download a deliverable, and what its address means

Every document can be downloaded directly: select the PDF link beside a title and the file is served, with no intermediate page. There is no registration and nothing to accept first, which is the behaviour a published research document should have.

The addresses look inconsistent, and that inconsistency is deliberate, not untidiness. The original site generated file paths in more than one way over its life, so the same document could be cited under two or three different addresses depending on when the citation was written. All of them are kept. A download link written into a paper in 2016 resolves to the same file as one written in 2018, because breaking either would break the citation that depends on it.

One consequence is worth stating plainly: a few of these documents are large. The full set runs to several hundred megabytes, and the biggest single deliverable is heavier than most web pages by three orders of magnitude. That is what a 200-page technical report with embedded diagrams weighs.

?Scope

Every public deliverable, and the one that is missing

The list of 5G-ENSURE deliverables above is drawn from the document archive itself rather than from any index of it, which matters because the two disagree. Four deliverables (D2.2, D2.3, D4.3 and D4.4) appear in no external citation at all and would have been missed entirely by working from references alone. They are here because the files are.

One document is genuinely absent. D3.7, a software release accompanying the enabler specifications, was published and is still referenced, but no copy of it survives to be served. It is recorded here instead of quietly dropped, because a gap that is named is more useful than a list that pretends to be complete.

/fRecords

Deliverables held at a second address

Three deliverables were also published through the file listing the original site generated, which gave each one a record of its own at a separate address. Both addresses were cited, so both are served, and the record page states which document it holds and how long it runs.

Each of these is the same document as its entry in the index above, reached by the second address it was published under.

D4.1 is a fourth case and a different one. It was served a second time from a Deliverables/ path, and that copy is not byte-identical to the one in the index above, so the two are separate files of the same deliverable rather than one file at two addresses. Both are kept, at the addresses they were cited under.

QQuestions

Questions and answers

Are these the complete public deliverables?

This is every public deliverable recoverable from the archive: 23 documents. One further identifier, D3.7, was published and is still cited, but no copy of the file survives in the archive, so it is listed here as a known gap.

Why do some documents appear at more than one address?

The original site changed how it generated file paths at least twice, so the same PDF was reachable at more than one address and different citations picked up different ones. Every address that was published continues to resolve to the document, because a reference is only useful if it still works.

What do the D-numbers mean?

The first digit is the work package and the second is the document within it, so D3.6 is the sixth deliverable of work package 3. Numbering is not chronological: a draft and its final version keep separate numbers, which is why the trust model appears as both D2.2 and D2.5.

Can the documents be reused?

Each document states its own dissemination level on its cover page, and the ones held here are marked public. Anything reused from them should be cited to the specific deliverable and version, because several exist in more than one edition.