VoLTE Architecture Explained

VoLTE architecture diagram

Quick facts

Contents

1. VoLTE architecture diagram
2. VoLTE in the LTE Architecture
3. What VoLTE Depends On
4. LTE Access Side of VoLTE
5. EPC Side of VoLTE
6. IMS Side of VoLTE
7. SIP Signaling in VoLTE
8. Default Bearer and Dedicated Bearer in VoLTE
9. QoS and Policy Control in VoLTE
10. VoLTE Registration and Session Setup
11. VoLTE and Emergency Services
12. VoLTE and LTE Security Context
13. Why VoLTE Is a Cross-Domain Architecture
14. Common Troubleshooting Angles for VoLTE
15. Related Pages
16. Key takeaways
17. FAQ
18. References

VoLTE in the LTE Architecture

In the EPS architecture, the UE accesses packet services over LTE, and the operator IMS environment sits beyond the P-GW on the packet-network side. In the IMS architecture, the core contains functions such as the P-CSCF and S-CSCF, which are part of the session-control framework for IP multimedia services. VoLTE uses the LTE/EPC path for connectivity and the IMS path for service control.

What VoLTE Depends On

• LTE packet connectivity: the UE must be attached to EPS and have packet connectivity through LTE/EPC. The default bearer provides connectivity throughout the lifetime of the PDN connection and is a Non-GBR bearer.
• IMS reachability: the UE must be able to reach IMS through the EPC path and operator IP services shown in the EPS architecture. IMS is the subsystem that supports IP multimedia services.
• SIP signaling: VoLTE session control is SIP-based through IMS, with CSCF-based session control including P-CSCF and S-CSCF roles.
• Correct QoS and policy treatment: PCC includes gating control, QoS control, and QoS signaling, which are critical for voice quality and service behavior.

LTE Access Side of VoLTE

On the access side, VoLTE uses the normal LTE radio architecture: UE to eNodeB over LTE-Uu, RRC for access-side control, PDCP/RLC/MAC/PHY for user-plane transport, and S1-MME plus S1-U into the EPC. The eNB provides the LTE radio user plane and RRC control plane toward the UE, so VoLTE media and SIP reachability still rely on standard LTE access behavior.

VoLTE does not bypass LTE radio architecture; it rides on top of it through the same bearer and radio-resource machinery used by LTE packet services.

EPC Side of VoLTE

The EPC carries the UE from radio access into the IMS service environment. The MME handles LTE access-side control-plane and NAS-related mobility/session support, the S-GW anchors the access-side user plane and supports mobility continuity, and the P-GW connects the LTE user to external packet networks and operator IP services such as IMS.

Because the EPS architecture explicitly shows operator IP services such as IMS on the P-GW side, VoLTE voice service is reached through the normal EPC packet path.

IMS Side of VoLTE

VoLTE service control is implemented in the IMS (IP Multimedia Subsystem). 3GPP TS 23.228 defines IMS as the subsystem containing the elements necessary to support IP multimedia services and describes IMS core entities such as P-CSCF, S-CSCF, I-CSCF, and HSS-related IMS support functions.

LTE alone gives the UE packet connectivity. IMS is what turns that connectivity into voice registration, voice session setup, call routing, session control, and multimedia service logic. That is why VoLTE should be understood as voice over LTE using IMS service control, not just generic voice over mobile data.

SIP Signaling in VoLTE

VoLTE uses SIP signaling in IMS for IMS registration, call setup, call modification, and session release. The IMS architecture is built around multimedia session-control functions, which is why SIP signaling is central to VoLTE call flows.

LTE does not replace SIP. LTE provides the packet-access network and bearer framework over which IMS SIP signaling runs.

Default Bearer and Dedicated Bearer in VoLTE

VoLTE is one of the clearest examples of why LTE bearer architecture matters. A default bearer provides base IP connectivity throughout the lifetime of the PDN connection and is a Non-GBR bearer. That bearer gives the UE base IP connectivity to the IMS environment.

VoLTE voice media typically requires service-specific QoS treatment. In the PCC architecture, dedicated-bearer traffic mapping, PCC/QoS rules, and bearer treatment are coordinated through the policy and enforcement framework.

QoS and Policy Control in VoLTE

VoLTE depends heavily on PCC (Policy and Charging Control). PCC includes flow-based charging, policy control, gating control, QoS control, and QoS signaling.

In architecture terms, the PCRF makes policy and charging decisions, the PCEF at the gateway enforces those rules, and bearer/QoS treatment for VoLTE media and related traffic depends on that PCC interaction.

This is one reason VoLTE is not only a radio or IMS problem. It is also a QoS-policy architecture problem. Incorrect PCRF/PCEF behavior can break voice quality or even service establishment.

VoLTE Registration and Session Setup

The exact message details belong in call-flow pages, but architecturally this is the core VoLTE pattern created by combining LTE/EPC, IMS, and PCC.

• UE attaches to LTE and obtains EPS connectivity.
• UE reaches IMS through the EPC packet path.
• UE performs IMS registration using SIP signaling.
• IMS session-control functions process registration and later call/session setup.
• Policy/QoS control and bearer treatment ensure voice traffic receives the correct service behavior.

VoLTE and Emergency Services

VoLTE architecture is also important for IMS emergency sessions. PCC includes architecture support and reference points for IMS emergency session behavior, and emergency bearer services are provided by the serving network to support IMS emergency service under policy and regulatory conditions.

LTE/EPS security specifications also describe security handling for authenticated and unauthenticated IMS emergency sessions, including how EPS security procedures can protect NAS, RRC, and user-plane traffic where applicable.

VoLTE and LTE Security Context

VoLTE runs on top of LTE/EPS security. For IMS emergency bearer services and IMS emergency sessions, NAS and AS protection follows EPS security procedures, and the UE/MME may use the current EPS security context to protect NAS, RRC, and user-plane traffic where applicable.

That means VoLTE does not introduce an entirely separate access security model. It relies on the LTE/EPS security framework for access-side protection while IMS handles service-side signaling and session control.

Why VoLTE Is a Cross-Domain Architecture

VoLTE is one of the best examples of why telecom architecture cannot be split into silos. To understand it properly, the RAN architecture, EPC architecture, IMS architecture, and PCC architecture have to be read together.

• RAN architecture explains radio access and bearer realization.
• EPC architecture explains packet transport, mobility, and gateway connectivity.
• IMS architecture explains service and session control.
• PCC architecture explains QoS, gating, and charging decisions.

Common Troubleshooting Angles for VoLTE

• LTE attach succeeds, but IMS is unreachable.
• UE has default bearer connectivity, but dedicated media-bearer behavior is wrong.
• IMS registration fails.
• SIP signaling succeeds, but media bearer or QoS behavior is wrong.
• PCRF/PCEF policy mismatch affects voice quality or call setup.
• Paging or service-request behavior breaks down for incoming voice.
• Emergency-service behavior differs because of policy or authentication conditions.

Related Pages

Key takeaways

• VoLTE is voice over LTE using IMS, not just generic voice over mobile data.
• LTE/EPC provides the packet-connectivity path to operator IP services such as IMS.
• IMS provides the session-control architecture for registration and call handling, including CSCF functions.
• VoLTE depends on correct bearer and QoS treatment, which is why PCC, PCRF, and PCEF matter.
• The best way to understand VoLTE is as one combined architecture spanning RAN + EPC + IMS + policy control.

FAQ

References

• 3GPP TS 23.401 EPS architecture for E-UTRAN access.
• 3GPP TS 23.228 IMS stage-2 architecture.
• 3GPP TS 23.203 Policy and charging control architecture.
• 3GPP TS 36.300 E-UTRAN overall description.
• 3GPP TS 33.401 LTE/SAE security architecture.