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.
- 23documents
- 4work packages
- 2,673pages
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.
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.
- 213 pp.
D2.5 Trust model (final)Public deliverable
PDF - 96 pp.
D3.9 Security enablers technical roadmap (final)Public deliverable
PDF - 190 pp.
D4.3 Test plan (final)Public deliverable
PDF
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.