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

Detected Changes Across Releases

from 3GPP Change Requests

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

Studied in Rel-6, normative work from Rel-15.

Rel-15 8 changes

In Release 15, the IP-CAN function was enhanced to support dual connectivity scenarios with NR, including the addition of specific UE and MS NAS capabilities for this support and a NAS indication for when such connectivity is restricted. The release also introduced clarifications for handling access network information during IMS calls in 5G dual connectivity and defined the mapping of Access-Type with IP-CAN-Type. Furthermore, procedures like the handling of PDN Connectivity Reject during an attach and the inclusion of Secondary RAT information for EN-DC were specified.

  • Addition of MS NAS capability for support of dual connectivity with NR TS 24.008CR3071
  • Addition of UE NAS capability for support of dual connectivity with NR TS 24.301CR2892
  • Addition of NAS indication for dual connectivity with NR being restricted TS 24.301CR2893
  • Security algorithm support for Dual Connectivity TS 24.301CR2960
  • Handling of PDN Connectivity Reject (cause #66) during an attach procedure TS 24.301CR3024
  • Clarification on access network information during IMS call in 5G dual connectivity scenario TS 23.228CR1191

+ 2 more changes

Rel-16 3 changes

In Release 16, specific IP-CAN enhancements were standardized, including a defined PDN connectivity procedure for UEs attached in Radio Link Only Suspended (RLOS) state. The release also introduced enhanced EPS location update reporting mechanisms capable of operating in Dual Connectivity scenarios. Furthermore, procedures were formalized to manage a back-off timer initiated when a UE receives a PDN CONNECTIVITY REJECT message.

  • PDN connectivity procedure for RLOS attached UEs TS 24.301CR3163
  • Enhanced EPS Location Update Reporting with Dual Connectivity TS 33.108CR0419
  • Procedure associated with a back-off timer started upon receipt of a PDN CONNECTIVITY REJECT message TS 24.301CR3222
Rel-18 5 changes

In Release 18, enhancements to the IP-CAN function introduced procedures for handling the UE's capability to support SDNAEPC during PDN connectivity, including the ability to reject the procedure if unsupported. The release also specified the inclusion of a DN-specific identity within the PDN CONNECTIVITY REQUEST message. Furthermore, it provided clarifications for abnormal cases in UE-requested PDN connectivity and defined registration rejection for scenarios where AUN3 device connectivity is not permitted.

  • Indicating the capability of supporting SDNAEPC during the PDN connectivity procedure TS 24.301CR3851
  • Rejecting PDN connectivity procedure due to SDNAEPC is not supported by the UE TS 24.301CR3852
  • Include DN-specific identity in PDN CONNECTIVITY REQUEST TS 24.301CR3861
  • Clarification of abnormal case in UE requested PDN connectivity procedure TS 24.301CR3888
  • Registration rejection due to AUN3 device connectivity not allowed TS 24.501CR6068
Rel-19 2 changes

In Release 19, enhancements to the IP-CAN function included enabling the provisioning of a Single-NSSAI (S-NSSAI) directly via the PDN CONNECTIVITY REQUEST message, providing more granular network slice information during connectivity establishment. Furthermore, the release introduced clarifications to the Policy and Charging Rules Function (PCRF) behavior to ensure proper handling in the event of a Packet Data Network Gateway (PGW) failure, improving the robustness of IP-CAN bearer management.

  • Provisioning an S-NSSAI via the PDN CONNECTIVITY REQUEST message TS 24.301CR3655
  • Clarify the behavior of the PCRF in the case of PGW failure TS 29.214CR1704

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