Blockchain-enabled resource management and sharing for 6G communications

The sixth-generation (6G) network must provide performance superior to previous generations to meet the requirements of emerging services and applications, such as multi-gigabit transmission rate, even higher reliability, and sub 1 ms latency and ubiquitous connection for the Internet of Everything (IoE). However, with the scarcity of spectrum resources, efficient resource management and sharing are crucial to achieving all these ambitious requirements. One possible technology to achieve all this is the blockchain. Because of its inherent properties, the blockchain has recently gained an important position, which is of great significance to 6G network and other networks. In particular, the integration of the blockchain in 6G will enable the network to monitor and manage resource utilization and sharing efficiently. Hence, in this paper, we discuss the potentials of the blockchain for resource management and sharing in 6G using multiple application scenarios, namely, Internet of things, device-to-device communications, network slicing, and inter-domain blockchain ecosystems

5G-PPP Software Network Working Group:Network Applications: Opening up 5G and beyond networks 5G-PPP projects analysis

As part of the 5G-PPP Initiative, the Software Network Working Group prepared this white paper to demystify the concept of the Network Applications. In fact, the Network Application ecosystem is more than the introduction of new vertical applications that have interaction capabilities. It refers to the need for a separate middleware layer to simplify the implementation and deployment of vertical systems on a large scale. Specifically, third parties or network operators can contribute to Network Applications, depending on the level of interaction and trust. Different implementations have been conducted by the different projects considering different API types and different level of trust between the verticals and the owner of 5G platforms. In this paper, the different approaches considered by the projects are summarized. By analysing them, it appears three options of interaction between the verticals and the 5G platform owner: - aaS Model: it is the model where the vertical application consumes the Network Applications as a service. The vertical application deployed in the vertical service provider domain. It connects with the 3GPP network systems (EPS, 5GS) in one or more PLMN operator domain. - Hybrid: it is the model where the vertical instantiates a part of its Vertical App in the operator domain like the EDGE. The other part remains in the vertical domain. A similar approach has been followed in TS 23.286 related to the deployment of V2X server. - Coupled/Delegated: it is the model where the vertical delegates its app to the operator. The Network Applications will be composed and managed by the operator. This approach is the one followed in the platforms like 5G-EVE. In addition, the paper brings an analysis of the different API type deployed. It appears that the abstraction from network APIs to service APIs is necessary to hide the telco complexity making APIs easy to consume for verticals with no telco expertise and to adress data privacy requirements

Dynamic Interdomain Network Slicing for verticals in the 5Growth project

Proceedings of: IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN), 9-11 Nov. 2021, Heraklion, Greece.This paper proposes and validates a Interdomain Network Slicing framework for verticals, allowing them to directly participate in the establishment and control of end-to-end Communication Services deployment across multiple inter-operator domains. The framework progresses the means made available by different standards and research initiatives to enhance service requesting and provisioning interfaces for the stakeholders involved, namely operators and verticals. The framework is validated under two different use cases, showcasing effective end-to-end service instantiation and a first assessment towards dynamic service modification capability.This work has been supported by EC H2020 5GPPP 5Growth project (Grant 856709)

View on 5G Architecture: Version 2.0

The 5G Architecture Working Group as part of the 5GPPP Initiative is looking at capturing novel trends and key technological enablers for the realization of the 5G architecture. It also targets at presenting in a harmonized way the architectural concepts developed in various projects and initiatives (not limited to 5GPPP projects only) so as to provide a consolidated view on the technical directions for the architecture design in the 5G era. The first version of the white paper was released in July 2016, which captured novel trends and key technological enablers for the realization of the 5G architecture vision along with harmonized architectural concepts from 5GPPP Phase 1 projects and initiatives. Capitalizing on the architectural vision and framework set by the first version of the white paper, this Version 2.0 of the white paper presents the latest findings and analyses with a particular focus on the concept evaluations, and accordingly it presents the consolidated overall architecture design

5G-PPP Software Network Working Group:Network Applications: Opening up 5G and beyond networks 5G-PPP projects analysis, Version 2

It is expected that the communication fabric and the way network services are consumed will evolve towards 6G, building on and extending capabilities of 5G and Beyond networks. Service APIs, Operation APIs, Network APIs are different aspects of the network exposure, which provides the communication service providers a way to monetize the network capabilities. Allowing the developer community to use network capabilities via APIs is an emerging area for network monetization. Thus, it is important that network exposure caters for the needs of developers serving different markets, e.g., different vertical industry segments. The concept of “Network Applications” is introduced following this idea. It is defined as a set of services that provides certain functionalities to verticals and their associated use cases. The Network Applications is more than the introduction of new vertical applications that have interaction capabilities. It refers to the need for a separate middleware layer to simplify the implementation and deployment of vertical systems on a large scale. Specifically, third parties or network operators can contribute to Network Applications, depending on the level of interaction and trust. In practice, a Network Application uses the exposed APIs from the network and can either be integrated with (part of) a vertical application or expose its APIs (e.g., service APIs) for further consumption by vertical applications. This paper builds on the findings of the white paper released in 2022. It targets to go into details about the implementations of the two major Network Applications class: “aaS” and hybrid models. It introduces the Network Applications marketplace and put the light on technological solution like CAMARA project, as part of the standard landscape. <br/

Multi-site Resource Allocation in a QoS-Aware 5G Infrastructure

Network softwarization has paved the way for 5G technologies, and a wide-range of (radically new) verticals. As the telecommunications infrastructure evolves into a sort of distributed datacenter, multiple tenants such as vertical industries and network service providers share its aggregate pool of resources (e.g., networking, computing, etc.) in a layered \u201das-a-Service\u201d approach exposed as slice abstractions. The challenge remains in the coordination of various stakeholders\u2019 assets in realizing end-to-end network slices and supporting the multi-site deployment and chaining of the micro-service components needed to implement cloud-native vertical applications (vApps). In this context, particular care must be taken to ensure that the required resources are identified, made available and managed in a way that satisfies the vApp requirements, allows for a fair share of resources and has a reasonable impact on the overall vApp deployment time. With these challenges in mind, this paper presents the Resource Selection Optimizer (RSO)-a software-service in the MATILDA Operations Support System (OSS), whose main goal is to select the most appropriate network and computing resources (according to some criterion) among a list of options provided by the Wide-area Infrastructure Manager (WIM). It consists of three submodules that respectively handle: (i) the aggregation of vApp components based on affinities, (ii) the forecasting of (micro-) datacenter resources utilization, (iii) and the multi-site placement of the (aggregated) vApp micro-service components. The RSO\u2019s performance is mainly evaluated in terms of the execution times of its submodules while varying their respective input parameters, and additionally, three selection policies are also compared. Experimental results aim to highlight the RSO behavior in both execution times and deployment costs, as well as the RSO interactions with other OSS submodules and network platform components, not only for multi-site vApp deployment but also for other network/services management operations

Network Slicing

Network slicing is emerging as a key enabling technology to support new service needs, business cases, and the evolution of programmable networking. As an end-to-end concept involving network functions in different domains and administrations, network slicing calls for new standardization efforts, design methodologies, and deployment strategies. This chapter aims at addressing the main aspects of network slicing with relevant challenges and practical solutions

Towards continuously programmable networks

While programmability has been a feature of network devices for a long time, the past decade has seen significant enhancement of programming capability for network functions and nodes, spearheaded by the ongoing trend towards softwarization and cloudification. In his context, new design principles and technology enablers are introduced (Section 7.2) which reside at: (i) service/application provisioning level, (ii) network and resource management level, as well as (iii) network deployment and connectivity level