2. Introduction

2.1. Context

As stated in “Luxembourg’s ultra-high-speed broadband strategy 2021-2025”, connectivity is no longer just a matter of technological advancement, it is a cornerstone of social and economic inclusion in a digitally driven society. While Luxembourg already enjoys extensive ultra-high-speed broadband coverage and a robust digital infrastructure, as highlighted in the state’s strategy, there remains a critical gap: a small yet significant percentage of the population still lacks access to these essential services. The strategy underlines the social urgency of closing the digital divide, which increasingly mirrors a broader societal divide.

As an economic interest group driving national connectivity goals, MyConnectivity plays a pivotal role in realising Luxembourg’s ultra-high-speed broadband strategy through its three core missions. First, it raises awareness and provides information about the challenges and potential of digital technology, ensuring full inclusion of all segments of society. Second, it actively promotes the deployment of and access to Ultra-High-Speed Broadband for everyone by fostering the development of reliable, high-performance, and sustainable technical infrastructures. Finally, it provides support, advice, and training to the public to overcome psychological and technical barriers that may hinder the adoption of new digital practices.

When looking at the mission of promoting the deployment and access to Ultra-High-Speed Broadband for everyone, the problem can be split in two. The first part of the problem is to bring ultra-high-speed connectivity to every building in Luxembourg. In this context, MyConnectivity already performed an analysis on the underserved areas of the country, and this problem is now well understood and under control.

The second part of the problem is that once a building has access to ultra-high-speed connectivity, each individual residential unit that is part of that building needs to be connected to the Network Termination Point (NTP). This is usually trivial for single familly homes but can be a challenge for multi-dwellling units, where the installation of vertical cabling can slow down the adoption of very high capacity networks (VHCN). These challenges can be due to technical reasons, such as the complexity of the installation (space constraints, building architecture, …), financial reasons (costs of the installation) or lack of awareness and consent of the multiple owners of the multi-dewlling units.

To tackle the challenge linked to the deployment of vertical cabling, the first step consists in documenting and quantifying the problem. In this context MyConnectivity launched a project that aims to bridge this knowledge gap by creating a “National registry of vertical cabling", in french "Registre National du Câblage Vertical (RNCV)”, which will be a centralised, neutral Database System that empowers telecom operators to efficiently populate and manage a comprehensive, centralised, nationwide inventory of vertical cabling infrastructure data, with a focus on multi-dwelling buildings.

The primary objectives of the RNCV are to identify buildings and building units lacking the necessary cabling standards to prioritise the necessary work to reach 100% VHCN connectivity within the multi-dwelling units. This approach is necessary to enable informed decision-making in prioritising infrastructure investments as well as to enable safe and fair vertical cabling inventory exchanges among telecom operators and other stakeholders. Additionally, it will create the ground for an ecosystem of services around this platform in the future.

2.2. Document purpose and scope

The present document describes the data architecture of the RNCV that has been designed to respond to the requirements expressed by the different stakeholders.

The document contains:

Following aspects are out of scope of this document:

It is important to note that this is a living document. The stakeholders can make suggestions or request changes, these changes will then be validated. If the changes are approved, they are then integrated into the data architecture documentation before being implemented.

This document should drive the direction, but any specific aspect can be challenged/adapted, but any change must become part of the document again

2.3. Targeted audience

2.3.1. Confidentiality

This document is an internal and confidential document and restricted access to selected audience is provisioned.

2.3.2. MyConnectivity and their shareholders

MyConnectivity and their shareholders are responsible and accountable for the the RNCV project. They are the owner of the solution and are the final approvers of the present document, making sure that the targeted data architecture fulfils the initial scope of the project and aligns with their long term strategy.

2.3.3. Operators

In a first phase, the operators are the main contributors and consumers of the RNCV, this document will help them understand the target data architecture.

The operator’s role is to make sure that the resulting data architecture can be used in practice and comply with their requirements. Operators may also suggest improvements when needed.

2.3.4. LNDS

LNDS is MyConnecitivity’s partner of choice regarding data privacy, data security, data quality and data governance. LNDS will qualify the data quality, security and privacy measures and provide valuable insights and suggest improvements to the data architecture.

2.3.5. Software developers of the RNCV

The software developers that will implement the RNCV, will use the document as requirement document for the data architecture. The document will also provide valuable suggestions for the system architecture.

The developers are 100% responsible for the system and its development, therefore they can challenge any part of the document and suggest modifications. These modifications requests will be taking into consideration, validated and if accepted, they will be integrated into the documentation.

2.3.6. MyConnectivity legal support

2.3.7. Data Architect

The data architect is responsible for the document’s content. The architect will be in charge of gathering and centralising the requirements and change requests to the data architecture.

The data architect will keep this document alive and up to date and will use it as a reference to support the software development.