Generic Network Slice Template

Description

The Generic Network Slice Template (GST) is a pivotal data model within the 3GPP standards, specifically designed for the management and orchestration of network slices. It serves as a standardized, machine-readable blueprint that describes the complete set of attributes, requirements, and constraints of a network slice instance (NSI). The GST is defined using YANG data modeling language, ensuring it is structured, hierarchical, and suitable for automated processing by management systems like the Communication Service Management Function (CSMF), Network Slice Management Function (NSMF), and Network Slice Subnet Management Function (NSSMF). Its primary role is to act as an information object that is passed between these management functions during the slice provisioning, modification, and assurance processes.

Architecturally, the GST is a core component of the 3GPP management framework for network slicing, detailed in specifications such as TS 28.531 and TS 28.541. It abstracts the complex, multi-domain nature of a slice into a manageable template. The template encompasses several key areas: the service profile (defining the slice's intended service type, e.g., eMBB, URLLC, MIoT), the network slice subnet requirements (detailing the needed resources and performance across the RAN, Transport, and Core Network domains), and the slice performance and policy requirements (including latency, reliability, throughput, and isolation levels). This structured approach allows the management system to decompose the high-level service request into specific, actionable configuration commands for the underlying network functions and infrastructure.

In operation, the GST enables closed-loop, intent-based management. A communication service provider (CSP) or enterprise customer submits a service request, often via a portal or northbound API, which is translated into a GST instance. This GST is then consumed by the NSMF, which interprets the requirements and orchestrates the necessary resources across different administrative and technological domains by generating domain-specific sub-templates for the NSSMFs. The GST ensures consistency and prevents misinterpretation by providing a single source of truth for the slice's intended behavior. It is integral to achieving the promised benefits of network slicing: customized logical networks on a shared physical infrastructure, each with guaranteed performance and isolation.

Purpose & Motivation

The GST was introduced to solve a critical challenge in the practical deployment of network slicing: the lack of a standardized, interoperable method for describing slice requirements. Prior to its definition, each vendor or operator might use proprietary templates or manual processes to define slices, leading to fragmentation, high integration costs, and an inability to automate lifecycle management across multi-vendor environments. The creation of the GST was motivated by the 5G vision of supporting diverse vertical industries (like automotive, manufacturing, and healthcare) with vastly different service requirements. These industries needed a clear, unambiguous way to communicate their network needs to the mobile operator.

Historically, network services were relatively monolithic, and service creation was a slow, manual process involving significant human intervention. The shift towards softwarization and cloud-native networks in 5G demanded a more agile, software-driven approach. The GST provides this by acting as a common 'contract' or 'recipe' that decouples the service intent from the vendor-specific implementation. It addresses the limitations of previous ad-hoc approaches by enabling automated translation of business-level service requirements into technical network configurations. This is essential for scaling network slicing to support a massive number of diverse slices efficiently and reliably.

Key Features

• Standardized YANG data model for machine-to-machine communication
• Comprehensive definition of slice service profiles (e.g., eMBB, URLLC, MIoT)
• Specification of performance requirements (latency, reliability, throughput)
• Definition of isolation and resource sharing policies
• Support for multi-domain decomposition (RAN, Transport, Core)
• Enables closed-loop automation for slice lifecycle management

Evolution Across Releases

Defining Specifications