Ref.

Ares(2019)2355755 - 03/04/2019

SOFIE - Secure Open Federation for Internet

Everywhere
779984

DELIVERABLE D3.1

Integration Plan

Project title SOFIE – Secure Open Federation for Internet Everywhere

Contract Number
Duration
Date of preparation
Author(s)
Responsible person
Target Dissemination Level
Status of the Document
Version
Project web-site
H2020-IOT-2017-3 – 779984
1.1.2018 – 31.12.2020
18.3.2019
Mikael Jaatinen (LMF), Santeri Paavolainen (LMF/Aalto),
Antonio Antonino (LMF), Dmitrij Lagutin (Aalto)
Mikael Jaatinen (LMF), mikael.jaatinen@ericsson.com
Public
Completed
1.17
https://www.sofie-iot.eu/

This project has received funding from the European Union’s Horizon 2020
research and innovation programme under grant agreement No 779984.
 Document: H2020-IOT-2017-3-779984-SOFIE/D3.1 – Integration Plan

Security: Public Date: 18.3.2019 Status: Completed Version: 1.17

Table of Contents
1. Introduction..........................................................................................3
1.1 Structure of the Deliverable ........................................................................ 3
1.2 List of Acronyms ......................................................................................... 3
2. Integration Strategy and Methodology ..............................................4
2.1 Strategy for Integration ............................................................................... 4
2.2 Methodology ............................................................................................... 6
2.2.1 Introduction ................................................................................................... 6
2.2.2 Continuous Integration .................................................................................. 7
2.2.3 Continuous Delivery ...................................................................................... 7
2.2.4 Managing the Integration Environment ......................................................... 8
2.2.5 Tools and Documentation ............................................................................. 8
2.3 Platforms & Pilots ..................................................................................... 10
2.3.1 Reference Platforms ................................................................................... 10
2.3.2 Business Platforms ..................................................................................... 10
2.3.3 Pilots ........................................................................................................... 10
3. Actors and Roles for Integration in SOFIE ......................................11
4. Integration .......................................................................................... 12
4.1 Testbed Release (version 0) .................................................................... 12
4.1.1 Features and Requirements ....................................................................... 12
4.1.1.1 General Requirements ................................................................................... 12
4.1.1.2 Partner and Pilot Project Requirements ......................................................... 12
4.1.2 Testbed Deployment ................................................................................... 14
4.2 Pilot evaluation release (version 1) .......................................................... 14
4.3 Final release (version 2) ........................................................................... 14
5. Schedule & Milestones ......................................................................15
6. References ......................................................................................... 16

SOFIE 2(16)
 Document: H2020-IOT-2017-3-779984-SOFIE/D3.1 – Integration Plan

Security: Public Date: 18.3.2019 Status: Completed Version: 1.17

1. Introduction
Fragmentation and lack of security are among the biggest problems of IoT platforms. Most IoT
platforms are vertically oriented closed systems, dedicated to specific application areas. There
are today hundreds of IoT platforms with no or very limited interoperability. The main goal of the
SOFIE project is to enable diversified applications from various sectors to utilize heterogeneous
IoT platforms and autonomous devices across technological, organizational and administrative
borders.
Secure open federation is the key concept of the SOFIE approach, aiming to enable creation of
business platforms, based on existing IoT platforms and distributed ledgers, without needing to
negotiate with any gatekeeper (neither technology- nor business wise). SOFIE exercises
security and data sovereignty by design.
The integration phase in the SOFIE project is responsible for integration of a SOFIE reference
platform and all the business platforms that will be used by the SOFIE pilot projects.
The purpose of this Integration Plan deliverable (D3.1) is to ensure that the SOFIE business
platforms that are validated in WP4 and are used by the WP5 pilot projects are well integrated
according to well defined milestones & time plan and with good software quality, by giving an
overarching principal view for WP3. Technical details of the integration environment setup and
the working practices are described in [WP3IE] and [WP3WP] respectively (these documents
are available on request from the D3.1 authors).
In line with the AGILE approach to software development, integration will be performed
incrementally and continuously. Three main releases will be produced during the lifetime of the
SOFIE project.
• Testbed release (version 0)
• Pilot evaluation release (version 1)
• Final release (version 2)
SOFIE will use Git as the Source Code Management System, Atlassian Jira as the Agile
software development management tool and Jenkins as the Continuous Integration server.
Developer documentation will be written. FOSS components may in addition also use public
resources such as Travis for Continuous Integration.

1.1 Structure of the Deliverable

Chapter 2 discusses the strategy and methodology for integration. Chapter 3 gives an overview
of the SOFIE consortium and the roles (in the context of integration) that the different partners
have. Finally, Chapter 4 describes the actual integration plan.

1.2 List of Acronyms

AWS Amazon Web Services public cloud
CD Continuous Deployment
CI Continuous Integration
DLT Distributed Ledger Technology
BP Business Platform (for pilots)
FOSS Free Open Source Software
RP Reference Platform
WP Work Package

SOFIE 3(16)
 Document: H2020-IOT-2017-3-779984-SOFIE/D3.1 – Integration Plan

Security: Public Date: 18.3.2019 Status: Completed Version: 1.17

2. Integration Strategy and Methodology

2.1 Strategy for Integration
The SOFIE project is committed to deliver four live pilots in three sectors (gaming, energy and
food chain) to demonstrate the benefits that can be achieved with a federated inter-ledger
platform approach.
The code of the project is portioned into the reference platform, business platform templates
and pilots. The reference platform contains all generic FOSS software components developer
under SOFIE, integrations for libraries and protocols used according to the Architecture and
Framework specifications. Business platform templates in turn use the reference platform but
are targeted towards solving a specific problem that cannot be readily generalized into code
that applies over the whole SOFIE project. These may integrate each other, but each will have
also its own build, test and integration processes, as shown in the figure below.

Figure 1: While each separate component should be testable in isolation, SOFIE project
software integration can be multiple layers in depth.
Business Platform (BP) templates are used to define the BPs that are built on top of the
reference platform by adding pilot-specific controls, DLTs, other needed third-party IoT
platforms with needed adapters and a marketplace and/or consumable service APIs. This
means that the BPs will include both FOSS and non-FOSS licensed software components.
Multiple pilots can share a common business platform, according to the following conceptual
diagram.
The different platform components will also include adapters and interfaces to external systems
such as public blockchains.
The functional growth for the integrated platforms will be done iteratively. Initially, the focus is
on the features and functions needed by the first main release, which is the testbed release
(version 0).
There are two models on how pilot software components (and others) are integrated into the CI
and CD pipelines. The main difference is whether the CI step is performed by the pilot, or as
part of the integration environment. The default model with combined CI and CD steps in a
single build pipeline is described in the figure below.

SOFIE 4(16)
 Document: H2020-IOT-2017-3-779984-SOFIE/D3.1 – Integration Plan

Security: Public Date: 18.3.2019 Status: Completed Version: 1.17

Figure 2: Combined CI and CD integration model.

In this model, the CI portion of the pipeline is responsible for compiling, unit testing and building
Docker containers, which, along with other build artifacts, are pushed to artifact repositories
(such as local Docker image registry). These artifacts are used by the CD portion to deploy the
software into a Kubernetes cluster which is then used as a target for integration tests. The figure
also shows several source repositories which contain information related to the Jenkins CI/CD
system configuration, deployment (e.g. Kubernetes) configuration and integration tests. These
may vary in structure depending on the particular pilot needs.
The assumption is that while the above model is preferred, there may be some proprietary
components1 for which no source code can be made available to the integration environment.
In this case the integration model assumes the CI steps are done as part of the pilot’s own
environment. This process results in Docker images to be made available for the integration
pipeline which now essentially performs only the CD workflow as shown in the figure below.

1 These may be due to software licenses of legacy systems, and thus outside the control of a pilot, for example.

SOFIE 5(16)
 Document: H2020-IOT-2017-3-779984-SOFIE/D3.1 – Integration Plan

Security: Public Date: 18.3.2019 Status: Completed Version: 1.17

Figure 3: Integration workflow model when CI workflow is internal to the pilot.

The same workflow applies also to other SOFIE project code. The specific repositories for
Jenkins configuration and deployment configuration are not published openly by default, as they
are likely to both contain environment-specific security-related material, but also because the
integration environment is specific to the SOFIE project and has limited applicability to other
systems overall.

2.2 Methodology
2.2.1 Introduction
Modern Agile Development and Continuous Integration methodologies with well-defined
pipelines for CI and CD will be applied in WP3. Sprint cycles are 4 weeks long (during the project,
the Sprint cycle length can be reconsidered if necessary). Regular weekly team meetings and
bi-weekly SOFIE partner meetings are arranged.
All documentation will be written in English.
WP2 and WP3 intend to work from a common backlog, as explained in the following figure.

SOFIE 6(16)
 Document: H2020-IOT-2017-3-779984-SOFIE/D3.1 – Integration Plan

Security: Public Date: 18.3.2019 Status: Completed Version: 1.17

Backlog management for the SOFIE SW

development and deployment

Common backlog, agreed Suggested Backlog

WP4 (Propose)
WP2 WP3 new features
WP5 SW delivery
flow
Fault
reporting
*) A backlog is a list of features or technical tasks which the team maintains and which, at a given moment, are known
to be necessary and sufficient to complete a project or a release

Figure 4: Backlog management

The aim is to establish public repositories for all FOSS software produced in SOFIE. For
commercial software and existing reused FOSS components, the reference platform will use
the standard dependency management system for the underlying language and framework to
provide information on the dependencies to other developers and Continuous Integration
system.

2.2.2 Continuous Integration

Continuous Integration is a development practice that requires developers to integrate code into
a shared repository at least daily, but typically several times a day. Each check-in is then verified
by an automated build, allowing teams to detect and locate problems early.
When automating the build process, automated tests are introduced into the process, so as to
identify the major areas where things go wrong and get automated tests to expose those failures.
Examples of such failures are software components failing to start up and incompatibilities in
APIs between software components. When a build fails, the key priority of the development and
integration team is to repair the build rather than adding new functionality on a broken base.
This also makes it possible to proceed with development in a separate branch that isolates
development from the base, with the branch tested and developed in isolation until it is deemed
to be ready, passing all test automation, to be merged to the main base code.
Continuous Integration leads to significantly reduced integration problems and enables
transparency and predictability of the software development progress.
In WP3, continuous integration will initially be run with either continuously on each check-in,
where applicable, and where no check-in tracking is available, then with daily or every second
day builds. WP2 FOSS components may in addition also use public resources such as Travis2
for CI, and pilots may also employ their own internal CI processes.

2.2.3 Continuous Delivery

Continuous Delivery, in contrast to Continuous Integration, refers to continuous delivery of
products from CI to a deployment environment. Continuous Delivery operates in multiple levels,
with the most repeated step being deployment of the system under development to a realistic
environment for integration, performance and/or acceptance testing. Successfully tested
deployments are promoted either automatically or manually to staging, demonstration or

2 https://travis-ci.org/

SOFIE 7(16)
 Document: H2020-IOT-2017-3-779984-SOFIE/D3.1 – Integration Plan

Security: Public Date: 18.3.2019 Status: Completed Version: 1.17

production status. The CD environment will automatically deploy any promoted builds to the
appropriate environment.
Continuous Delivery itself uses artefacts generated during CI, such as service deployment files,
containers stored in a container registry, virtual machine images etc. (the exact artefact type
depends on the software and system in question).

2.2.4 Managing the Integration Environment

Docker3 containers are preferred for as many SOFIE software components as possible as they
can be natively used in Kubernetes4. In this manner the containers can be used for both local
testing (as direct Docker containers), but also the same containers are applicable for
Kubernetes deployment as part of a Kubernetes pod configuration.
There is one integration/testing account and one staging account in AWS. LMF Ericsson will
own and administer both accounts, including access management for SOFIE users.
The integration/testing account will be used for the continuous integration and automated build
process.
The staging account will be used for hosting parts of the business platforms, such as the
reference platform and a private Ethereum network. The pilot projects will be able to leverage
on the hosted services rather than having to (re)deploy everything.

Integration and hosting environment

Hosted per pilot

Market Place
Pilot1 Pilot2 Pilot3 Pilot4 3P IoT Platforms
...

BP1 BP2 BP3 Use case specific functions and controls

BP template
Common functions and controls for BPs
SOFI E Reference Platform Demo platform
Hosted by WP3 for pilots, demos and affiliates

Figure 5: Integration and hosting environment

2.2.5 Tools and Documentation

SOFIE uses Git as the Source Code Management System and Atlassian Jira 5 for backlog
management. Slack is used for daily team communication. Build notifications will also be
integrated to Slack.
WP3 will use Jenkins6 as the Continuous Integration server. WP2 FOSS components may in
addition also use public resources such as Travis for CI.
Developer documentation will be written.
The primary criteria for different technology selection has primarily been their general availability,
maturity and quality, and secondarily their general applicability and familiarity in the general

3 https://www.docker.com
4 https://kubernetes.io/
5 https://www.atlassian.com/software/jira
6 https://jenkins.io/

SOFIE 8(16)
 Document: H2020-IOT-2017-3-779984-SOFIE/D3.1 – Integration Plan

Security: Public Date: 18.3.2019 Status: Completed Version: 1.17

developer (commercial and OSS) community. Another concern is the scope of the choice: is the
choice relevant to the overall project results (such as selection of DLTs) or constrained to the
integration environment infrastructure (choosing the cloud provider for the integration
environment infrastructure). In general, the latter should not affect the general applicability of
the former – for example, while AWS is chosen for the integration environment infrastructure,
this choice does not affect the general applicability of the Kubernetes deployments of various
software components on different infrastructure providers’ environments.
The table below summarizes the critical technology selections, their scope (project or integration)
and rationale.
Purpose Scope Selection Rationale
Source code Project Git The Git source code revision control system is
management de facto solution in the industry and open source
community. Other functionally similar solutions
such as Mercurial and Bazaar do not have
similar traction.
Repository Project GitHub GitHub is most commonly used for open source
hosting projects. While the repository hosting choice
(other functionally equivalent solutions would be
Bitbucket and GitLab) does not have an effect on
the component functionality, it has an effect on
the component visibility, and the approachability
of the hosting environment to the general
developer audience.
Containers Project Docker Docker is the most widespread containerization
solution. Other applicable solutions such as rkt7
containers do not yet have the support of
Docker.
Deployment Project Kubernetes Kubernetes is currently the most common open
orchestration source container deployment orchestration
solution. It is also universally supported by cloud
infrastructure providers. Other solutions such as
Docker Compose or Docker Swarm would be
applicable, but Kubernetes has become a de
facto solution.
Infrastructure Integration AWS AWS has the largest market share of different
provider cloud infrastructure providers, and the best
tooling support for management and
maintenance available. While the choice of AWS
should have no impact on the project results, its
use will confirm the applicability of SOFIE
components in AWS. Given AWS is often the
default go-to Infrastructure as a Service (IaaS)
platform for new development, this is overall a
positive result.
Continuous Integration Jenkins Jenkins is a CI/CD solution in widespread use. It
integration has a vibrant community and a large selection of
extensions.

7 https://coreos.com/rkt/

SOFIE 9(16)
 Document: H2020-IOT-2017-3-779984-SOFIE/D3.1 – Integration Plan

Security: Public Date: 18.3.2019 Status: Completed Version: 1.17

Purpose Scope Selection Rationale

and
deployment
Internal issue Integration JIRA The internal issue management and tracking
management systems is used internally within the integration
and tracking environment development and maintenance
work.
Public issue Project GitHub The open source components hosted in GitHub
management have the benefit of being able to use GitHub’s
and tracking native issue tracking and management
functionality.

2.3 Platforms & Pilots

2.3.1 Reference Platforms
The purpose of the SOFIE reference platform is to provide a minimal environment that provides
a set of common basic controls for all business platforms.
In the testbed release, the reference platform will include the following features and technologies
that are common for the different partners’ needs:
 Ethereum
o Private network
o Rinkeby public test network
 Hyperledger Fabric
 Hyperledger Indy
 Guardtime KSI®Blockchain
 Demo application to test Ethereum, Hyperledger Fabric 1.0 and KSI®Blockchain
 Adapters to the third-party IoT platforms that are part of the pilot projects

2.3.2 Business Platforms

The functionality of the business platforms is primarily integrated into the system through the
business platform templates being used in pilots. The business platform templates themselves
have functional, sample deployments, that are to be integrated and deployed when they are
available.

2.3.3 Pilots
Integration of the pilot system will occur after the testbed release, to have the majority of the
integration completed by the pilot release (version 1). Please refer to Section 2 for description
of how the integration environment will work in conjunction to the pilot development and pilot
code releases.

SOFIE 10(16)
 Document: H2020-IOT-2017-3-779984-SOFIE/D3.1 – Integration Plan

Security: Public Date: 18.3.2019 Status: Completed Version: 1.17

3. Actors and Roles for Integration in SOFIE

Table 1: Actors and roles for integration in SOFIE
Actor Role
AALTO Produces and delivers SOFIE software for integration

ASM TERNI Contributes to BP integration (Italian energy pilot)

AUEB Contributes to the SOFIE software design, and is also a

receiver of the integrated platforms for WP4 evaluation

EMOTION Contributes to BP integration (Italian energy pilot)

ENGINEERING Contributes to BP integration (Italian energy pilot)

LMF (ERICSSON) Responsible for integration of the RP and BPs

GUARDTIME Contributes to BP integration (Estonian energy pilot)

OPTIMUM Contributes to BP integration (Food chain pilot)

ROVIO Contributes to BP integration (Mobile Gaming pilot)

SYN Contributes to BP integration (Food chain pilot)

SOFIE 11(16)
 Document: H2020-IOT-2017-3-779984-SOFIE/D3.1 – Integration Plan

Security: Public Date: 18.3.2019 Status: Completed Version: 1.17

4. Integration
4.1 Testbed Release (version 0)
4.1.1 Features and Requirements
The integration plan will initially focus on the features and requirements of the first SOFIE main
release, which is the testbed release (version 0).

Figure 6: Integration environment testbed (version 0) functional components

In the testbed release, there will be a deviation from the integration strategy. All functions will
be packaged into one platform that provides minimum test and demonstration capabilities for
WP4 and WP5 in a testbed environment. In the next main release, the reference and business
platform parts will be separated.
The following requirements and indicative and may be subject to change during the Testbed
release development.

4.1.1.1 General Requirements

 Use of Docker containers by default
 Per node, the standard requirements are (any deviations to these are specified):
o RedHat, Centos or Ubuntu Linux
o Network connectivity (external and between test nodes)
o SSH privileges
o Minimum 10Gb of storage for test data, with the option to upgrade

4.1.1.2 Partner and Pilot Project Requirements

LMF (Integration Environment and hosted services)
 Amazon Web Services account and networking infrastructure will be set up, limited at
this step to (refer to [WP3IE] for description of the final environment):
o Account setup
o Continuous integration server setup
o Monitoring and logging configuration (basic level)
 CI process in use with one or more project artifacts (for example, BP1, review demos
etc.)
 Status update integration with Slack (push build information)
 Ethereum (including needed network connections)
o Private network (linked to AUEB and Aalto)
o Rinkeby public test network node

SOFIE 12(16)
 Document: H2020-IOT-2017-3-779984-SOFIE/D3.1 – Integration Plan

Security: Public Date: 18.3.2019 Status: Completed Version: 1.17

 Hyperledger Fabric private network (linked to AUEB and Aalto)

 Hyperledger Indy private network (linked to AUEB and Aalto)

Note that CD processes, artifact storage and a large portion of the functionality described in
[WP3IE] are excluded from the testbed (version 0) release.
Aalto (Development)
 1-2 nodes (2-5 containers) for student project integrations
 Ethereum (including needed network connections)
o Private network (linked to AUEB, Ericsson and Aalto’s miners)
o Rinkeby public test network
 Hyperledger Fabric private network (linked to AUEB and Ericsson testbed)
 Hyperledger Indy private network (linked to AUEB and Ericsson testbed)
 Access to Guardtime KSI®Blockchain
o Interworking with FIWARE, Ethereum and Hyperledger Fabric
 Connectivity with Aalto building automation IoT systems
o ACRE API gateway or BioTope project O-MI/O-DF testbed
 Connectivity with local gateways (COAP and MQTT devices)
 HTLC between Hyperledger Fabric and Ethereum (Interledger demo)
Either BP1 or IL demo with unit tests available for LMF CI integration
AUEB (Evaluation)
 Ethereum (including needed network connections)
o Private network (linked to Aalto and Ericsson)
o Rinkeby public test network
 Hyperledger Fabric private network (linked to Aalto and Ericsson testbed)
 Hyperledger Indy private network (linked to Aalto and Ericsson testbed)
 Access to Guardtime KSI®Blockchain
 A virtual server for running FIWARE
 Connectivity with local IoT nodes (Raspberry PIs, running web of things)
 No VPN required (public IP addresses available)
Guardtime (Hosted Services)
 Hosting access to Guardtime KSI®Blockchain network
o At least one aggregator
o At least one extender
Estonian Energy Pilot (Guardtime)
 3 nodes for the business platform and 3P IoT platforms
 Option to configure a firewall
 Public IP/host name
Italian Energy Pilot (ASM, Emotion, Engineering)
 1 node for the business platform
 1 node for EV/EVSE IoT platform
 Private Ethereum
 Access to Guardtime KSI®Blockchain
Food Chain Pilot (Optimum, Synelixis)
 1 node for the business platform
 1 node for transportation IoT platform
 Static public IP addresses / domain

SOFIE 13(16)
 Document: H2020-IOT-2017-3-779984-SOFIE/D3.1 – Integration Plan

Security: Public Date: 18.3.2019 Status: Completed Version: 1.17

 Private Ethereum
 Hyperledger Fabric
 Access to Guardtime KSI®Blockchain
Mobile Gaming Pilot (Rovio)
 1 node for the business platform
 1 node for Rovio proprietary platform
 Ethereum
o Private network
o Rinkeby public test network

4.1.2 Testbed Deployment

The D4.2 Testbed and Emulation Environment Design and Setup [D4.2] describes the Testbed
Deployment environment in detail. In a short summary, the testbed will be setup in the AWS
staging account by Ericsson for minimum demonstration purposes. Access to partners will be
arranged. Partners may also choose to install the testbed fully in own hosted environment.
The private SOFIE Ethereum network will decentralized across (at least) Aalto, AUEB and LMF.
Other partners (pilots) may choose to join it or to setup their own private Ethereum networks.
There will also be a decentralized Hyperledger Fabric ledger across (at least) Aalto, AUEB and
LMF. Other partners (pilots) may choose to join it or setup their own private Hyperledger Fabric
deployment e.g. as side chains for Ethereum.
A third network will also be set up across Aalto, AUEB and LMF. Such network is made of
Hyperledger Indy nodes inter-connected across the different organizational boundaries. Other
partners (pilots) may choose to join it or setup their own private Hyperledger Indy deployment.
Guardtime will fully host the KSI service components and provide consumable API access to
the service.

4.2 Pilot evaluation release (version 1)

To be added in a later version of the document.

4.3 Final release (version 2)

To be added in a later version of the document.

SOFIE 14(16)
 Document: H2020-IOT-2017-3-779984-SOFIE/D3.1 – Integration Plan

Security: Public Date: 18.3.2019 Status: Completed Version: 1.17

5. Schedule & Milestones

The sprint schedule is a living plan and will be maintained in Jira. The milestones that WP3 is
working against are as follows:

Month Milestone Contents Dependencies

M6 Integration Plan ready D3.1, 1st approved version WP2, WP4,
WP5
M10 Integration Environment Separate document [WP3IE]. WP2, WP4,
defined for D3. WP5
M11 Integration Environment CI/CD ready for D3.2. WP2, WP4
functional (limited)
M11 Working practices defined. Separate document [WP3WP]. WP2, WP4,
WP5
M11 Testbed release (version 0) D3.2 (demo quality) WP2, WP4
M16 Integration Environment Separate document [WP3IE]. WP2, WP4,
defined for all pilots [WP3IE] WP5
M18 Integration Environment CI supporting all pilots. WP2, WP4,
functional for all pilots [WP3IE] WP5
M18 Continuous Deployment for all CD supporting all pilots WP2, WP4,
pilots (staging) and delivery WP5
capability to pilots (production)
M20 Automated testing Automated tests ready for WP4, WP5
D3.3
M21 Pilot evaluation rel. (version 1) D3.3 WP2, WP4,
WP5
M34 Automated testing Automated tests ready for WP4, WP5
D3.4
M36 Final release (version 2) D3.4 WP2, WP5
M36 Final business platform D3.5 WP4, WP5,
integration report WP6

SOFIE 15(16)
 Document: H2020-IOT-2017-3-779984-SOFIE/D3.1 – Integration Plan

Security: Public Date: 18.3.2019 Status: Completed Version: 1.17

6. References
[WP3IE] WP3 Integration and Evaluation: Description of Integration Environments
[WP3WP] WP3 Integration and Evaluation: Working Practices
[D4.2] D. Lagutin et al., “SOFIE Deliverable D4.2 - Testbed and Emulation Environment
Design and Setup”, February 2019. Available at:
https://media.voog.com/0000/0042/0957/files/SOFIE_D4.2-
Testbed_and_Emulation_Environment_Design_and_Setup-v1.00.pdf

SOFIE 16(16)