GSMA NG.116 Explained:
What GST and NEST Mean for Network Sharing

What Is GSMA NG.116?

GSMA NG.116, formally titled "Generic Network Slice Template," is a standard published by the GSMA's Network Group. First introduced in 2019 and updated through multiple versions since, it provides a structured, machine-readable way to describe the characteristics of a 5G network slice.

Before NG.116, there was no industry-wide agreement on how to specify what a network slice should deliver. Each operator, each vendor, and each standards body used slightly different terminology and parameters. An MNO in Germany might describe a low-latency slice one way; an MVNO in France might describe the same requirement using entirely different attributes. This fragmentation made automated interoperability between operators practically impossible.

NG.116 solves this by defining two complementary constructs: the Generic Slice Template (GST) and the Network Slice Type (NEST). Together, they form a common language — a shared vocabulary — that any operator or platform can use to describe what a network slice offers or what a service requires.

What Is the Generic Slice Template (GST)?

The GST is the foundational element of NG.116. Think of it as a comprehensive form — a master list of every attribute that could be relevant when describing a network slice. It does not prescribe specific values; instead, it defines the full set of parameters that are available to be filled in.

The current version of the GST includes over 40 attributes, spanning performance requirements, geographic scope, service characteristics, and operational constraints. Not every attribute needs to be specified for every slice — the GST is intentionally broad so that it can accommodate the widest possible range of use cases.

Core GST Attribute Categories

The attributes in the GST can be grouped into several logical categories. Here are the most important ones, explained in practical terms:

• Performance attributes: Maximum and guaranteed latency (in milliseconds), uplink and downlink throughput (in Mbps or Gbps), jitter tolerance, and packet error rate. These define how fast and how reliably data moves through the slice.
• Reliability and availability: Target uptime percentage (e.g., 99.999%), survival time (how long the slice can tolerate a disruption), and reliability class. Critical for industrial and safety-related applications.
• Capacity attributes: Maximum number of connected devices, maximum number of simultaneous sessions, and density requirements (devices per square kilometre). Essential for IoT and venue deployments.
• Coverage and mobility: Geographic area of the slice (expressed as coverage areas or tracking areas), supported mobility levels (stationary, pedestrian, vehicular, high-speed rail), and roaming requirements.
• Isolation and security: Level of resource isolation required (shared, dedicated, or hybrid), security requirements, and data confidentiality needs.
• Service characteristics: Slice/Service Type (SST) as defined by 3GPP (eMBB, URLLC, MIoT, V2X, HMTC), supported data types, and whether the slice supports mission-critical communications.
• Operational attributes: Slice lifecycle parameters — provisioning time, modification flexibility, maximum duration, and energy efficiency requirements.

Key GST Attributes from NG.116 v10.0

The following table lists a representative selection of the 42 attributes defined in the current version of the specification. Each attribute has a presence indicator: Mandatory (M), Conditional (C), or Optional (O). In practice, most attributes are optional because the GST is designed to be flexible across radically different use cases — a massive IoT deployment will specify very different attributes than a URLLC slice for industrial robotics.

This is only a subset of the full 42 attributes. Others cover energy efficiency targets, supported device velocity classes, survival time under failure conditions, NB-IoT support, position-accuracy requirements, and more. The full specification is available to GSMA members through the GSMA's official document portal.

What Is the Network Slice Type (NEST)?

If the GST is the blank template, a NEST is a filled-in version of that template — a specific combination of GST attribute values that describes a particular category of network slice. Each NEST represents a predefined slice profile optimised for a known use case.

The GSMA defines several standard NESTs, and operators can also create custom NESTs tailored to their specific market or customer requirements. The point is that a NEST provides a shorthand: instead of specifying 20+ individual parameters every time a slice is requested, an operator or customer can reference a NEST and both parties immediately understand the full set of requirements.

Predefined NEST Types and SST Values

NESTs are built on 3GPP-defined Slice/Service Type (SST) values. Each SST integer identifies a broad category of network behaviour, and the NEST fills in the specific GST attributes appropriate for that category. The standard SST values defined by 3GPP (TS 23.501) and used in NG.116 NESTs are:

• SST 1 eMBB (Enhanced Mobile Broadband) — The default slice type for consumer data services. Optimised for high throughput with moderate latency. Covers video streaming, web browsing, and high-bandwidth enterprise applications. Typical parameters: 100+ Mbps downlink, latency under 20ms.
• SST 2 URLLC (Ultra-Reliable Low-Latency Communications) — Designed for applications where latency and reliability are paramount: industrial automation, robotics, remote surgery, and autonomous vehicle coordination. Typical parameters: latency under 5ms, availability above 99.999%, dedicated resource isolation.
• SST 3 mIoT (Massive IoT) — Supports very high device density with modest per-device throughput. Built for smart metering, asset tracking, agricultural monitoring, and large-scale sensor deployments. Typical parameters: 1 million+ devices per km², low power consumption, relaxed latency.
• SST 4 V2X (Vehicle-to-Everything) — Combines low latency with high mobility support and optional PC5 sidelink parameters. Covers connected vehicles, traffic management, road safety, and cooperative driving. Typical parameters: latency under 10ms, support for speeds above 250 km/h, v2xPc5ParameterProvisioning enabled.
• SST 5 HMTC (High-Performance Machine-Type Communications) — Tailored for factory automation and deterministic industrial communication where both low latency and high reliability are required alongside precise time synchronisation (synchronicity attribute). Bridges the gap between URLLC and mIoT.

Beyond the standard SST-based NESTs, operators and platforms can define custom NEST templates that pre-populate GST attributes for specific vertical use cases. TEASOL, for example, offers pre-built templates such as:

• Custom Gamer's Edge — A low-latency, high-throughput profile optimised for cloud gaming and competitive esports. Based on eMBB (SST 1) but with tighter latency constraints, isolationLevel set to SHARED_PROTECTED, and performanceMonitoring enabled for real-time jitter tracking.
• Custom Smart Factory — A deterministic communications profile for industrial environments combining URLLC-class latency with IEEE 1588 time synchronisation, dedicated isolation, and performancePrediction for predictive maintenance analytics.

Each of these NESTs — standard or custom — is simply a GST with specific attribute values pre-populated. An operator requesting a URLLC slice can reference the standard NEST, optionally override certain parameters (such as narrowing the areaOfService or adjusting the target latency), and submit that as a complete slice specification.

From GST to ServiceProfile: How the Translation Works

NG.116 defines what a slice should deliver at the service level. But when an MNO actually provisions that slice on its 5G core and RAN infrastructure, the request must be expressed in a different format: the 3GPP NRM (Network Resource Model) defined in TS 28.541. The NRM uses constructs like ServiceProfile, SliceProfile, and subnet-specific profiles (CNSliceSubnetProfile, RANSliceSubnetProfile) to describe how network resources are configured.

Bridging these two worlds — GSMA service-level descriptions and 3GPP implementation-level models — is one of the core functions of TEASOL's Translation Engine. Here is how key GST attributes map to their NRM equivalents:

This is not a simple pass-through. Each MNO may have different API versions, payload schemas, and authentication methods for their network management systems. TEASOL's Translation Engine adapts per-MNO, handling NRM fields that have no direct GST equivalent by flagging them for bilateral negotiation or deriving values from top-level GST attributes. For example, a GST isolationLevel of DEDICATED implies specific resourceSharingLevel settings at the subnet layer, even though the GST does not explicitly define those sub-fields — the engine infers and applies them based on the MNO's published slice capabilities.

This per-MNO adaptation is what allows TEASOL Exchange to operate across heterogeneous operator environments without requiring a single canonical NRM version. The GST/NEST layer provides the common service description; the Translation Engine handles the implementation-specific mapping underneath.

Why NG.116 Matters for Network Sharing

Network slicing is valuable on its own — it lets a single physical network support multiple virtual networks, each optimised for different requirements. But the real transformative potential emerges when slicing works across operators.

Consider a practical scenario: an MVNO needs low-latency coverage in a specific industrial zone, but its host MNO does not have sufficient capacity in that area. A neighbouring operator does. Without a shared standard, arranging this capacity exchange requires weeks of manual negotiation — aligning terminology, comparing incompatible specifications, and drafting bespoke legal agreements.

NG.116 changes this equation fundamentally. When both operators describe their capacity and requirements using the same GST/NEST framework, three things become possible:

• Automated comparison: A platform can programmatically compare what one operator needs against what another operator has available — attribute by attribute, value by value — without human interpretation.
• Multi-operator interoperability: Because the standard is vendor-agnostic, it works regardless of whether Operator A uses one infrastructure vendor and Operator B uses another. The exchange happens at the service description level, not the implementation level.
• Standardised SLA generation: Contract terms can be derived directly from the agreed GST/NEST parameters. Latency guarantees, throughput commitments, and availability targets are already expressed in unambiguous, measurable terms.
• Scalable marketplace dynamics: With a common description language, many operators can publish available capacity simultaneously, and many buyers can submit requirements — enabling a true exchange rather than a series of bilateral negotiations.

How TEASOL Implements NG.116

TEASOL Exchange uses GST and NEST as the foundational data model for all slice and capacity exchange operations. This is not an add-on or an optional integration — NG.116 compliance is built into the core of how the platform works.

Standards-Based Listing and Discovery

When an operator publishes available capacity on TEASOL Exchange, it is expressed as a set of GST-compliant attributes. The platform validates these against the current NG.116 specification, ensuring that every listing is complete, internally consistent, and comparable with listings from other operators. Similarly, when an MNO, MVNO, neutral host provider, or private network operator submits a service request, it is structured as a NEST — either a standard predefined type or a custom configuration.

AI-Powered Matching

This is where the standardisation becomes genuinely powerful. Because every supply listing and every demand request shares the same attribute structure, TEASOL's AI-powered matching engine can automatically identify compatible capacity across multiple operators. The engine evaluates dozens of GST parameters simultaneously — latency, throughput, coverage area, reliability, device density, mobility requirements — and surfaces the best matches ranked by fit, cost, and geographic relevance.

Without NG.116, this kind of automated cross-operator matching would require custom translation layers for every operator pair — an approach that does not scale. With NG.116, the common language is already in place.

Protocol Bridge Integration

TEASOL's protocol bridge translates between different operators' internal systems (OSS/BSS, SMO, network management platforms) and the standardised GST/NEST format used on the Exchange. This means operators do not need to overhaul their existing infrastructure to participate. The bridge handles the translation, ensuring that internal capacity data is accurately represented in NG.116-compliant terms and that matched agreements are properly communicated back to each operator's native systems.

The Bigger Picture: From Standard to Ecosystem

NG.116 is a description standard — it tells the industry how to talk about slices. But a standard alone does not create a market. What transforms a common language into a functioning exchange is the infrastructure that uses it: platforms that can ingest standardised descriptions, match supply with demand, and execute agreements at scale.

This is the role TEASOL Exchange is designed to fill. By building on NG.116 rather than inventing a proprietary description format, TEASOL ensures that any operator already working with GSMA standards can participate with minimal friction. The standard provides the vocabulary; the Exchange provides the marketplace.

As 5G deployments mature and 6G research begins to shape the next generation of network architecture, the importance of standardised slice descriptions will only grow. Operators who adopt NG.116-compliant workflows now are positioning themselves for a future where network capacity is traded as dynamically and efficiently as cloud compute resources are today.

Frequently Asked Questions