Architectures proposed by SDO
Standards have been viewed as a mechanism to avoid vendor lock-in . Specifically, standards provide (i) a broad agreement over a well-defined scope; (ii) a well-accepted policy and intellectual properties guidelines; and (iii) commands authority over the topic being standardized . These are sufficient reasons to consider SDO as important players leading the way of how a technology should be used and influencing other actors to follow those guidelines. The purpose of this section is to provide a vision of the network slicing architectures proposed by the previously mentioned SDO and make a useful comparison among them.
As presented in Section 1.2.1, NGMN is the SDO that owns the network slicing vision. Their generic definition and use cases reflect the intention and what is desirable when using a network slice. NGMN proposes a three layer architecture to realize the network slicing concept. It is illustrated via an example shown in Figure 1.1 which points out a typical near-future scenario for a CSP that provides five services to customers. Each one of them leverages on one or several network slices, customized according to the service requirements. For instance, the architecture depicts the service deployment for a simple case like Service Instance 1, which uses the Network Slice Instance 1. Increasing complexity, Service Instance 3 leverages on three Sub-Network Instances that make up the Network slice instance 3. A more complex case is depicted for Service Instance 4 and 5, which both share the Network Slice Instance 4. NGMN even covers the case in which the yellow Sub-Network Instance is shared between Network Slice Instance 3 and 4. This separation in diverse network slices (or even network slice subnets), allows the CSP to have manageability of the service, to make them run as desired, to provide optimization of the service and manage their interactions and security.
The layers that comprise the architecture are: (i) service instance layer, which represents the services, denoted by a service instance; (ii) network slice instance layer, which provides network characteristics which are required by a service instance; (iii) resource layer, which covers resources (physical or logical) on the network infrastructure. For NGMN, a service instance refers to the realization of an end-user service, made possible thanks to a network slice. This service instance is composed of network slice instances, which group together network functions and required resources to meet a characteristic of the service instance. NGMN specifies further that the network slice instance layer is created via network slice blueprints. Blueprints are created during design (or configuration time) and contains the description of the structure, configuration and the instructions to perform the LCM of the network slice instance .
Challenges in network slicing architecture
This section addresses the challenges that need to be overcome in order to build a network slice, enhance their security and provide better ways to manage them. The challenges have been grouped according to categories to make them more understandable. Even though it is utopian to think that a single architecture can solve all problems, elements for an enhanced architecture are presented as a complete ecosystem, in order to try to solve the issues shown in the following subsections.
Orchestration and management
Orchestration and management constitutes a challenge as networks and services grow in size and complexity, not only of the network functions but of the interactions between components and stakeholders. Heterogeneity of the infrastructure is commonplace, so we need tools to identify domain boundaries belonging to different administrative domains, providing this way a complete multi-domain orchestration to serve the desired functionalities . This challenge gets more difficult if the service sends requirements for resources very frequently (in short timescales), which poses a challenge to the speed of the policy validation while permitting cooperation between management functional blocks and the resource orchestrator . Since physical resources are finite, cooperation is needed between public and private clouds in order to scale up the resource pools as needed, usually at peak times. For this, it is necessary to enhance trust mechanisms, provide cross domain knowledge of the resources, and revise security and administration policies . Enhancing the orchestration capabilities would permit to manage better end-to-end services, nonetheless there is a blockage related to the lack of a common language that standardizes the service definition . Lawful interception is also a challenge, that could be tackled by having higher granularity of NF at expense of the effort to chain those resources .
From the point of view of the application, the challenge is to design a mobility management scheme that is aware of the application running on a network slice, so we can customize the response according to the needs and speed of the required handover, in order to preserve the QoS for the user . To make sure that requirements are fulfilled, standardized API and protocols are required to provide seamlessly network slice and service performance monitoring  .
Secured and isolated by design approach
The secured and isolated by design architecture for network slices has two points of view: the internal to the network slice and the one that has the CSP. Both of them use two concepts, called the Virtual Security Function (VSF) and the hook.
1. The Virtual Security Function (VSF) concept: VSF is the given name to any VNF that has a function useful for security purposes. Examples of such entity are a firewall, an Intrusion Detection System (IDS), an Intrusion Prevention System (IPS).
2. The hook concept: the hook concept makes reference to the quality of a network design to reserve a place on a link to instantiate a VSF. This adds flexibility to the design allowing to modify service by adding a special functionality.
A VSF deployed on a hook helps to tighten and filter the traffic that a NF is supposed to send and receive, limiting the options for an attacker to render the service unusable or to steal information. The VSF and the dynamic hook approach take advantage of the NFV and SDN paradigms to help to increase the security of the services. They are used to enhance the security of the deployment and minimize the risks. They are used for the network slice view and the CSP view.
Access control implementations for 5G
According to the explored literature, access control implementations cover (i) at the application level: Internet of Things (IoT) systems, connected vehicles, medical oriented scenarios and document management; (ii) at the resource level: cloud scenarios, security under NFV MANO environment and traffic segmentation. Some publications seek to apply Multi Layer Security (MLS) to telecommunication networks. For example, in  authors propose a modified BLP security model to be used in a 5G/IoT use case. Their approach is an evolution from the current trust model (between user and network) into a new trust model (between applications and the network). Their security model considers a scheme to label data based on the secrecy level and category, as well as capability token that rules the access scheme. In  authors propose a MLS model based on BLP to avoid leakage of information from internal users in the private cloud environment, being this a key feature in order to have the ability to change the security level of an object dynamically.
Approach and architectures
In , authors deal with the secure distribution of workloads in the cloud by transforming the workloads, and detecting possible breaches in the inter-cloud communication. The transformation process involves awareness of the nature of the data in the workflow, the location of the clouds along with their security level. Authors in  address the security in IoT in relation to the complex data flows. Even if a strict approach using Denning’s lattice model can be implemented, authors prove that using a partial order model can achieve security and more flexibility. Authors in  argue that authorization to access documents in a network is usually enforced at the server side. But since the network is used by actors with different clearances, malicious users can access unauthorized content by attacking the network directly.
Authors in  developed an Access Control Application on a SDN controller to classify the information flows and separate them by implementing VLANs, one for each group of users with similar security clearance.
Table of contents :
Challenges for network slicing realization
The research questions
Organization of the document
1 Network slicing
1.2 Network Slicing Definitions
1.2.1 Definitions provided by SDO
1.3 Architectures proposed by SDO
1.4 Challenges in network slicing architecture
1.4.1 Orchestration and management
1.4.6 Radio access
1.4.7 Other challenges
1.4.8 Final remarks
1.5 Comprehensive definition and proposed architecture
1.5.1 A comprehensive definition
1.5.2 Generic architecture
1.5.3 Secured and isolated by design approach
2 Formalization of a security access control model for the 5G System
2.2 Approach and architectures
2.2.4 Lattice-based access control
2.2.5 Access control implementations for 5G
2.3 New secure access control model for the 5GS
2.3.3 Subjects and objects
2.3.4 Other components
2.3.5 Which model to apply?
2.4 Global description of the model
2.4.1 Entities: subjects and objects
2.4.3 Security Constraint
2.5 Auxiliary concepts for the global model
2.5.2 Assignment operations
2.5.4 Compliance Operator
2.5.5 Final remarks
2.6 Inter-domain interactions
2.6.1 Definition of the architecture
2.6.2 Interaction 1
2.6.3 Interaction 2
2.6.4 Interaction 3
2.6.5 Interaction 4
2.6.6 Interaction 5
3 Managing secure inter-slice communication in 5G Network Slice Chains
3.2 Recent works
3.3 Motivating example
3.4 Network Slice and Network Slice Chain
3.4.1 Network Service (NS)
3.4.2 Network Slice (NSlice)
3.4.3 Communication Service Graph (CSG)
3.4.4 Network Slice Chain (NSliceCh)
3.5 Attributes and metrics involved in inter-slice communication
3.5.3 Final remarks
3.6 Policy validation for Network Slice Chains
3.6.1 Security constraint and optimization problem
3.7 Solving the challenges
3.7.1 Compliance with customer requirements
3.7.2 Optimization of resource utilization
3.8.1 Execution time
3.8.2 Comparison between best and sub-optimal communication service path
3.8.3 Final Remarks
4 Metrics to assess the isolation of Network Slices
4.2 Recent work
4.4 Data Structure
4.4.1 Attributes (A)
4.4.2 Metric Categories (MetCat)
4.4.3 Metric (Met)
4.4.4 Summary tables
4.5 Considerations about mapping
4.5.1 Mapping of metrics to metric categories
4.5.2 Mapping of attributes to layers
4.6 Calculation of metric for isolation
4.6.1 Option 1: weight on attributes
4.6.2 Option 2: weight on Metric Categories
4.6.3 Total calculation
4.7.2 Infrastructure capabilities
4.7.3 Scales, possible values and value assignment to metric categories
4.8 Final remarks
5 Conclusion and Perspectives
6 Publications from the thesis