Description
The Communication Service Customer (CSC) is a functional role defined within the 3GPP management architecture, specifically in the context of the Management and Orchestration (MANO) framework and network slicing. It represents the organizational entity (which could be an enterprise, a vertical industry player, a virtual operator, or even another service provider) that has a commercial agreement with a Communication Service Provider (CSP) to consume one or more communication services. The CSC is not the end-user device but the administrative and business entity responsible for the service relationship.
Architecturally, the CSC interacts with the CSP's management systems through standardized reference points, primarily the Consumer-facing Service Interface (CnF). Through this interface, the CSC can request services, such as the creation of a network slice instance, modify service parameters, monitor service performance, and receive fault and performance reports. The CSC's domain includes its own management systems (CSC Management System) which may integrate with the CSP's Business Support Systems (BSS) and Operations Support Systems (OSS). This separation allows the CSP to expose a controlled set of management capabilities to the customer, enabling self-service and automation.
The role of the CSC is central to the network slicing paradigm defined from 3GPP Release 15 onwards. When a CSC (e.g., an automotive company) requires a dedicated network slice for connected car services, it submits a service request via the CnF. This request, containing the Network Slice Service Profile, triggers the CSP's orchestration systems to instantiate the necessary network functions across the RAN, transport, and core network to fulfill the service-level agreement (SLA). The CSC then receives continuous insight into the slice's performance, including key performance indicators (KPIs) like latency, throughput, and availability, allowing for proactive management of their application's quality of experience.
Key components in the CSC ecosystem include the CSC Management System, which formulates service requests and consumes service assurance data, and the Service Management Function (SMF) within the CSP's domain that handles these requests. The relationship is governed by a Service Level Agreement (SLA) that defines technical performance targets, business terms, and reporting obligations. The CSC concept enables a clear demarcation between the provider's network management responsibilities and the customer's service management responsibilities, which is essential for complex, SLA-driven 5G and beyond services.
Purpose & Motivation
The CSC concept was introduced to formalize and standardize the business-to-business (B2B) and customer-to-provider relationship in telecommunication services, particularly as networks evolved to support diverse vertical industries with 5G. Prior to its formal definition, service management interfaces were often proprietary, limiting automation and hindering the scalable onboarding of enterprise customers. The CSC model addresses the need for a standardized, automated, and programmable interface through which customers can directly interact with the provider's network capabilities.
Historically, enterprise services were provisioned through manual, ticket-based processes with limited customer visibility into network performance. The shift towards network virtualization, cloud-native principles, and network slicing demanded a more dynamic, API-driven approach. The CSC role, along with the CnF interface, was created to solve this by enabling zero-touch service management. It allows vertical customers (in manufacturing, healthcare, logistics, etc.) to order, configure, and monitor their dedicated network services (slices) on-demand, much like consuming cloud computing resources. This is a fundamental change from the traditional monolithic, one-size-fits-all network service model.
Furthermore, the CSC framework supports the monetization of 5G networks by providing the necessary management architecture for Network-as-a-Service (NaaS) business models. It allows Communication Service Providers to expose network capabilities as manageable, billable services with clear ownership and accountability boundaries. This empowers enterprises to innovate by integrating guaranteed network performance directly into their operational technology and applications, driving the digital transformation of industries.
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (26 CRs across 6 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-5, normative work from Rel-15.
In Release 15, the Communication Service Customer (CSC) function was newly introduced as a key architectural element for Mission Critical Push-To-Talk (MCPTT) services. It encompasses several specific reference points, including CSC-1 for identity management, CSC-2 for group management configuration, and CSC-8 for security key delivery between a key management server and client. These interfaces leverage existing HTTP and SIP transport mechanisms to facilitate group communications, security, and service management for public safety and similar applications.
- Adding Integrity Key for KMS communications TS 33.180CR0051
In Release 16, the CSC function was updated to decouple the communication service from the network slice, enhancing architectural flexibility. Furthermore, refinements were made to the communication service assurance service, including updates to its descriptive figures and technical explanations. These changes provided clearer separation and management of the service layer relative to the underlying network resources.
In Release 17, the CSC function was enhanced with a new focus on network prediction-assisted Service Level Specification (SLS) communication service assurance, introducing use cases for network resource usage and performance prediction. The release also updated the description of the communication service lifecycle and refined requirements, including clarifying the communication security context when using a functional alias. These updates provided a more detailed framework for service assurance and lifecycle management without altering the fundamental CSC reference point architecture.
- Communication security context when using functional alias TS 23.280CR0257
- Add use case of network resource usage and performance prediction assisted SLS communication service Assurance TS 28.535CR0001
- Update the network prediction assisted SLS communication service assurance use case TS 28.535CR0053
- Update use cases and requirements to replace Communication Service TS 28.535CR0037
- Update description of communication service lifecycle TS 28.535CR0047
- Clarify communication service in requirement CSA-CON-06 TS 28.535CR0063
In Release 18, the CSC function was enhanced with new procedures for service migration during ongoing group and private communications, and for allowing subsequent MCVideo and MCData communications after an adhoc group emergency alert. It also introduced new use cases, requirements, and a solution for the management of Non-Public Network (NPN) service customers. Furthermore, corrections and updates were made to several CSC reference points, including CSC-7, CSC-16, CSC-19, and CSC-20.
- Migration during an ongoing group communication TS 23.280CR0315
- Migration procedure during and ongoing private communication TS 23.280CR0330
- Partner MC service server stores necessary information for communication redirection TS 23.280CR0355
- Updates procedures for allowing subsequent MCVideo and MCData communications after an adhoc group emergency alert TS 23.280CR0378
- Add use case and requirements for management of NPN service customer TS 28.557CR0003
- Add solution for management of NPN service customer TS 28.557CR005
+ 3 more changes
In Release 19, the CSC function was enhanced to support Lawful Interception (LI) for 5G ProSe Direct Communication and for 5G ProSe Communication via a UE-to-Network Relay. This introduced new LI-related procedures and signaling for these ProSe-based communication services, which are integral to off-network MCPTT and group communications. The specifications detail the necessary Stage 2 and Stage 3 system enhancements, particularly involving the SMF, to enable this interception capability for the CSC.
- SMF enhancement for LI for 5G ProSe Communication via 5G ProSe UE-to-Network Relay - Stage 2 TS 33.127CR0272
- LI for 5G ProSe Direct Communication - Stage 2 TS 33.127CR0273
- SMF enhancement for LI for 5G ProSe Communication via 5G ProSe UE-to-Network Relay - Stage 3 TS 33.128CR0704
- LI for 5G ProSe Direct Communication - Stage 3 TS 33.128CR0721
In Release 20, the CSC function was enhanced by incorporating MCData services into the generic migration procedures for both ongoing private and group communications. Furthermore, the specifications for point-to-point communication were clarified, and CSC-15 was revised to incorporate additional interactions between the LMS (Location Management Server) and MC Service Servers. These updates extended the CSC framework's support for Mission Critical services beyond MCPTT to include MCData.
- Adding MCData to generic procedure for migration during an ongoing private communication TS 23.280CR0657
- Adding MCData to generic procedure for migration during an ongoing group communication TS 23.280CR0658
- Clarification on the point-to-point communication in clause 10.16.4.2 TS 23.280CR0696
- Revised CSC-15: Incorporating Additional LMS and MC Service Server Interactions TS 23.280CR0671
Explore further
Broader topics and technologies where CSC plays a role.
Defining Specifications
3GPP specifications that define or reference CSC, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.179 vd50 | MCPTT Functional Architecture | Rel-13 |
| TS 23.280 vk10 | Common Architecture for Mission Critical Services | Rel-20 |
| TS 25.223 vj00 | UTRA Physical Layer TDD Spreading & Modulation | Rel-19 |
| TR 26.941 vj01 | 5G Media Slicing Extensions | Rel-19 |
| TS 28.530 vj00 | Network Slicing Concepts & Requirements | Rel-19 |
| TS 28.531 vk00 | Management and Orchestration | Rel-20 |
| TS 28.535 vj00 | Closed Control Loop Assurance Management | Rel-19 |
| TS 28.536 vj20 | Management services for communication service assurance | Rel-19 |
| TS 28.557 vj00 | Management of Non-Public Networks (NPN) | Rel-19 |
| TS 28.805 vg10 | Management of Communication Services in 5G | Rel-16 |
| TR 28.812 vh10 | Study on Intent Driven Management Services | Rel-17 |
| TR 28.828 vi00 | Charging Aspects for Non-Public Networks | Rel-18 |
| TR 28.836 vi00 | Technical Report on Intent Driven Management | Rel-18 |
| TR 28.843 vi10 | Technical Report on Charging Aspects for Vertical Scenarios | Rel-18 |
| TR 32.847 vi00 | Technical Report | Rel-18 |
| TS 33.127 vj50 | Lawful Interception Architecture and Functions | Rel-19 |
| TS 33.128 vj50 | 3GPP TS 33.128: Lawful Interception Protocols | Rel-19 |
| TS 33.179 vdc0 | MCPTT Security Architecture and Procedures | Rel-13 |
| TS 33.180 vk00 | Security of Mission Critical (MC) Service | Rel-20 |
| TS 33.879 vd10 | MCPTT Security Study | Rel-13 |
| TS 33.880 vf10 | Security Study for Enhanced Mission Critical Services | Rel-15 |