How to Design Autonomous Service Level Agreements for 6G

A Service Level Agreement (SLA) is a contract or agreement between a service provider and a customer. The customer can be an organisation or an individual. It is a legal and detailed document that typically includes roles and responsibilities of all parties involved such as service quality, duration, and penalties [1]. Typically, network service providers (e.g., mobile service provider or infrastructure providers) have set procedures in place to monitor their SLAs and generate periodic reports. Such mechanisms allows them to monitor their service quality and keep records in the situations of customer complaints or disputes.

In the 6G networks, many of the existing 5G applications will evolve to be applicable in much more demanding environments. Applications such as remote surgery and extreme uses of the Industry 4.0 paradigms will become prevalent. Robots and machines will be in charge of critical procedures such as direct health and personal care, and piloting of autonomous vehicles. These procedures will be either human or machine-guided and, either way, they require extremely reliable network connections. That is, future network application providers and users (e.g., surgeons or a car manufacturer) will need to prove the reliability of their applications to gain their customer trust in the product or service. For example, in human-guided remote surgery, the patient and the surgeon will want to ensure that the connection between them is reliable.

Indeed, this calls for a reliable contractual mechanism for future networks of 6G. We note two key requirements must be fulfilled for future SLAs. Firstly, the SLAs must be reliable and trustable. This means that all the stakeholders should trust the contractual mechanism, and that the SLAs shall be honored in all circumstances. Secondly, they must be automatically managed throughout their lifetime, with a special focus on SLA monitoring and enforcement stages. The reason is that future networks will face a high demand for connectivity from an ever-increasing number of devices subscribed to B2B and B2C services. This imposes great scalability burdens that can only be alleviated with automation (zero-touch) procedures, at both network and infrastructure levels.

To that end, we propose the use of DLT, particularly Permissioned Distributed Ledgers (PDLs), to design a contractual mechanism for SLAs in future networks. Distributed Ledgers are an immutable and transparent network of nodes, in which all the participants keep an identical copy of the record. The planned executions are recorded in the ledgers in the form of executable software code called “Smart Contracts”. Typically, smart contracts are installed on distributed ledgers and consequently inherit some of the distributed ledgers’ properties such as immutability and automated execution. Some properties of smart contracts are briefly described below:

Immutable – Smart contracts are immutable, when they are installed on a ledger, they cannot be amended or deleted.

Auto-executable – When a smart contract is installed on a ledger it becomes auto-executable.

Transparent – Typically, a smart contract is installed on all nodes of a distributed ledger system. Therefore, a smart contract becomes visible to all the nodes.

From lifecycle perspective, smart contracts inherently resembles SLAs as illustrated in Figure 1. For example, an SLA processing lifecycle usually includes a creation phase, an operation phase, and a termination phase; similarly, the life-cycle of a smart contract consists of equivalent phases such as initialisation/creation, execution/logic, and termination. We believe the smart contract lifecycle and its inherent properties (i.e., immutable, auto-executable, and transparent) are aligned with the design requirements of future SLAs. This paper presents a new SLA approach, which leverages smart contracts and PDL to enable autonomous and accountable SLAs for 6G networks. Our contribution primarily includes:

1. 1.

   Novel SLA requirements for future network SLAs are explored and identified.

2. 2.

   This new SLA architectural framework is proposed, which utilizes smart contracts to automate the entire multi-layer SLA process.

3. 3.

   Several future directions are identified and detailed.

The rest of this paper is organised as follows: Firstly, we review the existing work in Section II, Next, we highlight the recommendations about SLA for 6G in Section III. We propose a novel DLT-enabled SLA architecture in Section IV. Designing a DLT-enabled architecture is not trivial, several considerations, precautions and planning are required. We discuss these considerations for our architecture in Section V. Then, a few future directions on using smart contracts for enabling autonomous SLA for 6G networks are discussed in Section VI. Lastly, we conclude our work in Section VII.

Smart contracts as SLAs have been in discussion for a while, and several applications have been proposed. For instance, in [4] authors propose the use of DLT in the design of an SLA management system for cloud-based services; however, it is limited to smart contract modularization for SLA in the cloud scenario. Also, they do not discuss the pitfalls of the distributed ledgers and the considerations for their adoption in the architecture. The potential of SLA management in 6G through blockchain/smart contracts is proposed in [5] and a platform to manage the SLA between the service providers and customers is presented by [6]. However, none of these define an SLA framework itself with the requirements, challenges, and future directions of SLAs when they are implemented based on smart contracts. A smart contract together with an SLA model is represented by [7] where the authors propose a witness committee based model to monitor the SLA; the system incentivizes committee members for being honest. However, they neither discuss the structure of SLA nor challenges related to adopting a smart contract as SLA. Authors in [8] propose a model for translating SLAs into a smart contract; the proposed model relies on a third party to collect the monitoring data and adjust the metrics (e.g., billing and payment) accordingly. Like other existing works, the work from [8] is also focused on smart contract implementation for SLAs, but neither discusses the limitations of smart contracts nor the requirements for future networks.

6G networks will introduce a new wave of devices, applications and use cases. In this section, we identify the key requirements for future SLAs

Monitorable – The future SLAs must be monitorable during their lifetime, that is, from its initialisation to completion; see Figure 1(a). In future networks, an application such as Industry 4.0 will rely on a an IoT fabric for production and manufacturing services. The most significant challenge with industrial IoT is the management of millions of sensors and monitoring their health.

Transparent – A future network SLA will need to be transparently available to all the contract stakeholders for the reasons such as a prospective audit and external SLA verifiability. For example, in a shared network infrastructure like [9], all the stakeholders (e.g., service providers and vendors) should have an identical copy of the contract, in which any changes in one contract automatically echoed into other copies of the contract.

Auto-Executable – Future network SLAs will need to be auto-executable. That is, they must be executable with the pre-programmed conditions without human intervention. We argue that the automated execution should not be from initialisation to termination but maintain certain checkpoints to ensure that micro targets are being met. This means that the management software should verify the contract details at every milestone and take appropriate actions autonomously if any contract violation is identified.

Dynamic – SLAs will need to be dynamically generated and in real-time as per user demand. For example, once a customer orders an autonomous car, the system should generate a contract per his specifications. Special requests such as a change of delivery date and customisation should adjust the main agreed SLA and all other dependent SLAs accordingly and autonomously.

Zero Touch Network and Service Management – SLAs should be actively monitoring the system and report any anomalies in the system autonomously. In case of potential SLA violations, they must make corrective measurements and adjustments, for instance, to reroute the traffic to another path, and to report this to the control system or the service provider.

AI-Enabled – Managing an ever-growing number of customers will be a significant challenge in the future. The service providers will need to work diligently to resolve customer problems along with the everyday activities such as service requests and QoS monitoring. Indeed, software automation is already a common practice for tasks such as network management. Yet, disputes and disagreements are often done manually and on a case-by-case basis.

In future generation of contractual systems must have the cognitive ability to make human-like decisions in unforeseen situations like network anomalies and participants’ disputes.

Intent-Enabled – Intent-based management is a potential and prominent shift from complicated service provisioning commands to understandable and straightforward statements referred to as intents. As per IETF Definition: “An intent specifies the goals and outcomes of the network without specifying how to achieve them”.

Intent-based management allows the provider to fulfill customer expectation (target service requirements) in a non-prespective manner. In fact, the customer can specify from a wide variety of intents, and the provider has the liberty to allocate resources to achieve those functionalities as per the network feasibility and resource availability.

Cross-Provider Collaboration – Cross-providers collaboration is already a common practice (e.g., RAN sharing, roaming) to allow operators to extend their service footprint at reasonable costs. However, service providers must adopt this (i.e., collaboration) practice at a broader scale; instead of installing new infrastructure, first consider collaboration and share the existing front-haul and mid-haul resources mutually.

Based on the requirements identified in Section III, in this section, we present our contractual system for future networks of 6G. Our architecture exploits permissioned DLT (i.e., PDL) to enable an automated and transparent contractual tool. As a use case, we position the modularized SLA components in a typical service providers’ network slicing architecture [10]. The components (see Figure 2) are placed in a complete telco stack, that is, in the BSS (Business Support System), OSS (Operation Support System) and network layers (Figure 3).

Following are the key players involved in the architecture:

Service Customer – including end-users (B2C market) and most notably enterprise customers (B2B/B2B2C market), such as hyperscalers and large-scale content service providers.

Governance – A group of players, which oversees the network management and operations; they also maintain the compliance strategies within the architecture and watches for wrongdoings. There are two types of governance involved in the architecture: 1) Local Governance that belongs to one network architecture only; and 2) Inter-PDL Governance which sits atop more network architectures and performs the management tasks.

Typically, an SLA has several modules or subcontracts, which form an end-to-end SLA or contract. The most common subcontracts in our architecture are detailed below. Note that, in this work, we provide a generic contractual system architecture. As per the application, a contractual mechanism can have more/fewer subcontracts.

Intent-Translation Smart Contract (IT-SC) – records the agreed SLA terms established on the intent to the ledger. The IT-SC is executed by the ITF (Intent Translation Function)

Access Control Smart Contract (AC-SC) – records the access control credentials to the ledger. It includes an internal timers, which automatically revokes the access rights when the assigned access time elapses. The AC-SC is executed by the P-ACF (PDL Access Control Function) and

Service Orchestration Smart Contract (SO-SC) – sets up the service provisioning through resource allocation; for instance, types and duration of resources used. It is executed by the P-SOF (PDL Service Orchestration Function).

Service Recording Smart Contract (SR-SC) – records the service usage to the ledger. It is executed by executed by the PDLF (PDL Function).

Our architecture is underpinned by the following strata, which further includes functional elements of the architecture:

This section highlights the considerations necessary for adopting smart contracts as SLAs.

This work highlights the requirements of the SLAs for future 6G networks. Based on the identified requirements, we argued that smart contracts are the key to future SLAs. They pose the essential properties for future SLAs, and on this notion, we proposed a modularised, PDL-enabled SLA architecture for future networks of 6G. Like every technology, distributed ledgers have limitations, which may hinder their adoption as SLAs. We discussed these limitations in detail and argued that these limitations could be managed and mitigated through comprehensive planning and standardization. We believe this work will mark a new era of SLAs which are trustable by all the stakeholders.