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
Detected Changes Across Releases
from 3GPP Change RequestsSpecific 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.
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
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.
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
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.
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.
| Specification | Title | Release |
|---|---|---|
| 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 |