Description
Dedicated Core Network (DCN) is a 3GPP architectural concept enabling the deployment of logically or physically separate core network instances. These dedicated cores are designed to serve specific categories of subscribers, devices, or service types, such as machine-to-machine (M2M) communications, enterprise customers, or public safety services. The primary mechanism involves steering a User Equipment (UE) to the appropriate dedicated core network node (e.g., a dedicated MME, SGSN, or PGW) based on subscription data, UE capabilities, or requested services during the initial attach or tracking area update procedures. This steering is often facilitated by network nodes like the MME or by using a Dedicated Core Network Selection Function.
Architecturally, DCN introduces the concept of a Network Identifier (e.g., a Dedicated Core Network ID - DCN-ID) to differentiate between the various core network instances. The RAN (e.g., eNodeB in LTE) uses this identifier, provided by the core network during initial context setup or handover, to route subsequent signaling and user data for that UE to the correct dedicated core network nodes. This ensures that all control plane and user plane interactions for a given UE session are confined to its assigned dedicated core instance.
The role of DCN is critical for implementing network slicing precursors, enabling service differentiation, and meeting stringent requirements for latency, security, or reliability for particular verticals. It allows operators to optimize the configuration, scaling, and management of network resources per dedicated core without impacting other user groups. This isolation is fundamental for supporting diverse 5G use cases, where a single physical network infrastructure must simultaneously support services with vastly different characteristics.
Purpose & Motivation
DCN was created to address the growing need for network segmentation and service-specific optimization within mobile operator infrastructures. Prior to its introduction, all subscribers and services shared a common, monolithic core network. This 'one-size-fits-all' approach became inefficient and inflexible with the rise of diverse device types like IoT sensors and mission-critical communication systems, which have requirements (e.g., low bandwidth, high reliability) vastly different from typical smartphone traffic.
The technology solves the problem of inefficient resource utilization and conflicting service policies. For instance, massive numbers of IoT devices could overwhelm signaling resources designed for human-centric traffic. DCN allows operators to isolate such traffic into a dedicated core instance with optimized signaling procedures and policies, protecting the performance of the mainstream mobile broadband core. It also enables tailored charging, security policies, and network function configurations specific to enterprise or vertical industry needs, providing a foundation for customized service level agreements (SLAs).
Historically, DCN laid the groundwork for the more flexible and software-defined concept of network slicing in 5G. It represented an early step towards logical network separation, moving beyond purely physical network deployments and enabling more efficient use of infrastructure while supporting the business and technical requirements of new market segments.
What changed in its specifications
The latest release-to-release comparison of specifications that define DCN. Each summary describes the whole specification, not only this term.
Rel-18 brings only minor changes to TS 21.905: 0 clauses changed, with no change attributed to a release feature.
Full comparison in TR 21.905 →Rel-19 brings only minor changes to TS 23.060: 0 clauses changed, with no change attributed to a release feature.
Full comparison in TS 23.060 →Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (2 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Defining Specifications
3GPP specifications that define or reference DCN, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TR 21.905 vj20 | 3GPP Terminology and Definitions | Rel-19 read |
| TS 23.060 vj00 | GPRS Stage 2 Service Description | Rel-19 read |
| TS 23.236 vj00 | Intra Domain Connection of RAN Nodes to Multiple CN Nodes | Rel-19 read |
| TS 23.401 vk10 | Evolved Packet System Architecture | Rel-20 read |
| TR 23.785 ve00 | Architecture enhancements for LTE V2X services | Rel-14 read |
| TS 25.331 vj01 | UTRAN Radio Resource Control Protocol | Rel-19 read |
| TS 25.401 vj00 | UTRAN Overall Architecture | Rel-19 read |
| TS 25.413 vj00 | Radio Access Network Application Part (RANAP) | Rel-19 read |
| TS 29.272 vj60 | MME and SGSN Diameter interfaces to HSS/CSS/EIR | Rel-19 read |
| TS 29.303 vk00 | DNS Procedures for EPS and 5G Interworking | Rel-20 read |
| TS 32.101 vj00 | PLMN Management Principles and Requirements | Rel-19 read |
| TS 32.102 vj00 | Telecom Management Physical Architecture Framework | Rel-19 read |
| TS 32.371 vj00 | Security Management Concept & Requirements | Rel-19 read |
| TS 32.401 vj00 | Performance Management Concept & Requirements | Rel-19 read |
| TS 36.300 vj20 | E-UTRAN Radio Interface Protocol Architecture | Rel-19 read |
| TS 36.331 vj40 | E-UTRA Radio Resource Control (RRC) Protocol | Rel-19 read |
| TS 36.413 vj20 | S1 Application Protocol (S1AP) for E-UTRAN | Rel-19 read |
| TS 48.018 vj00 | BSS-SGSN Interface for GPRS Control | Rel-19 read |
| TS 52.402 vj00 | GSM Performance Management Measurements | Rel-19 read |