IP-CAN

IP-Connectivity Access Network

Core Network →
Introduced in Rel-6 Also in: Services

IP-CAN is the conceptual network that provides IP connectivity between a User Equipment and an external IP network, forming the foundation for all IP-based services in 3GPP systems.

Category
Core Network
Introduced
Rel-6
Where
Core Network › 5G Core
Also touches
1 segments
Specifications
26 specs
IP-CAN Description Purpose Related Classification Detected Changes Specifications

Description

The IP-Connectivity Access Network (IP-CAN) is not a single physical network element but a logical architectural concept defined within the 3GPP framework. It represents the entire set of network entities and functions that collectively establish and maintain IP bearer connectivity for a user. This connectivity originates at the User Equipment (UE) and traverses the radio access network (e.g., UTRAN, E-UTRAN, NG-RAN) and the core network (e.g., GPRS core, EPC, 5GC) to reach a Packet Data Network (PDN) Gateway (PGW) in 4G or a User Plane Function (UPF) in 5G, which serves as the anchor point to external IP networks.

From a functional perspective, the IP-CAN encompasses all layers and protocols involved in the IP session. This includes the establishment, modification, and termination of bearers or QoS Flows that carry the user's IP traffic. Each IP-CAN session is associated with a specific UE IP address and is uniquely identified for the purposes of policy and charging control. The architecture is designed to be access-agnostic in later releases, meaning the core policy logic can apply uniformly whether the UE is connected via 3G, 4G, 5G, or non-3GPP access like Wi-Fi.

The IP-CAN's primary role is to serve as the context for the Policy and Charging Control (PCC) architecture. The Policy and Charging Rules Function (PCRF) or the Policy Control Function (PCF) in 5GC uses the IP-CAN session as a key anchor point for applying policy decisions. The PCRF/PCF receives information about the IP-CAN session (e.g., IP address, access type, default bearer characteristics) from the network element acting as the Policy and Charging Enforcement Function (PCEF), typically the PGW or UPF. Based on subscriber profiles, service requests, and network conditions, the PCRF/PCF then installs dynamic PCC rules into the PCEF. These rules govern QoS parameters (like guaranteed bitrate), gating (allowing/blocking packets), and charging methods for specific service data flows within the IP-CAN session.

Key components involved in realizing an IP-CAN session include the UE, the radio access network, the serving gateway (SGW) in EPC, the PGW/UPF (which acts as the IP-CAN bearer termination point and the PCEF), and the PCRF/PCF. The interfaces between these elements, such as the Gx interface (between PCRF and PGW) or the N7 interface (between PCF and SMF), are used to manage the IP-CAN session's policies. The concept is fundamental to enabling seamless, quality-assured, and billable IP multimedia services across evolving network generations.

Purpose & Motivation

The IP-CAN concept was introduced to provide a standardized, abstract model for IP connectivity within 3GPP networks, which was essential as networks evolved from circuit-switched voice to all-IP architectures supporting rich multimedia services. Prior to its formalization, managing QoS and charging for diverse IP services was complex and often proprietary. The IP-CAN model created a clear demarcation point and a consistent session context, enabling the development of a unified Policy and Charging Control (PCC) framework.

Its creation solved the critical problem of how to dynamically apply network policies (for quality of service, traffic gating, and charging) to a user's IP session, regardless of the underlying access technology. By defining the IP-CAN session, operators could correlate a user's service usage (e.g., a video stream) with their network connection, allowing for service-aware charging (like zero-rating) and guaranteed bandwidth for premium services. This was a key enabler for the IP Multimedia Subsystem (IMS) and commercial data service plans.

Furthermore, the IP-CAN abstraction future-proofed the policy architecture. As new access technologies emerged (like LTE and later 5G NR), the core PCC logic could remain largely unchanged by simply updating the definition of the IP-CAN session parameters for that new access type. This allowed for smooth evolution from 3G to 4G and 5G while maintaining consistent service and business logic for operators.

Classification

Part ofPCEF
Specific typesTMU
Related approachesPCRF

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (1 CRs across 1 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-15 1 change

In Release 15, the specification introduced a new mapping between the Access-Type and the IP-CAN-Type for the IP-Connectivity Access Network function. This provides a more precise technical linkage for the underlying IP transport connectivity between the UE and IMS entities. The change clarifies the network resource model when identifying the IP-CAN, such as GPRS, which provides bearers like PDP Contexts.

  • The mapping of Access-Type with IP-CAN-Type TS 29.214CR1623

Explore further

Broader topics and technologies where IP-CAN plays a role.

Defining Specifications

3GPP specifications that define or reference IP-CAN, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TR 21.905 vj00 3GPP Technical Terms and Definitions Rel-19
TS 23.203 vj20 Policy and charging control architecture Rel-19
TS 23.228 vj50 IMS Stage-2 Service Description Rel-19
TS 23.417 v1700 IMS Core Component for NGN Architecture Rel-7
TS 23.517 v1800 IMS Core Component for NGN Architecture Rel-8
TS 23.701 vc00 WebRTC Access to IMS Architecture Study Rel-12
TS 23.722 vf10 Common API Framework (CAPIF) for 3GPP Northbound APIs Rel-15
TS 23.802 v1700 Enhanced End-to-End QoS Architecture Rel-7
TS 23.803 v1700 PCC Architecture Harmonization Study Rel-7
TS 23.806 v1700 Voice Call Continuity between CS and IMS Rel-7
TS 24.008 vj50 3GPP TS 24008: Core Network Protocols Rel-19
TS 24.147 vj00 IMS Conferencing Protocol Details Rel-19
TS 24.229 vj50 IMS call control protocol based on SIP and SDP Rel-19
TS 24.301 vj60 NAS protocol for Evolved Packet System Rel-19
TS 24.424 vj00 XCAP over Ut for Supplementary Services MO Rel-19
TS 24.501 vj50 5G NAS Protocols Specification Rel-19
TS 24.525 vj00 Business Trunking Architecture & Requirements Rel-19
TS 24.623 vj00 XCAP Protocol for Supplementary Services Rel-19
TS 24.819 v1700 IMS Services via Fixed Broadband Access Rel-7
TR 24.930 vj00 IMS Session Setup Signalling Flows Rel-19
TR 26.944 vj00 QoE, ESQoS and SQoS metrics for 3G multimedia services Rel-19
TS 29.214 vj20 Policy and Charging Control over Rx Rel-19
TS 29.816 va00 PCRF Failure & Restoration Study Rel-10
TS 31.829 vd00 ISIM Conformance Requirements Technical Report Rel-13
TS 32.251 vj00 PS Domain Charging Management Rel-19
TS 33.108 vj00 LI Handover Interface Specification Rel-19
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.