Voice over LTE (VoLTE) is expected to become the predominant solution for providing voice services in commercial LTE networks in the upcoming years. VoLTE integrates voice over IP (VoIP), LTE radio network (i.e., E-UTRAN), LTE core network (i.e., EPC), and the IP Multimedia Subsystem (IMS) to support voice services.
Key Components of VoLTE.
- VoIP (Voice over IP): This technology enables voice communication over the internet using IP protocols.
- E-UTRAN (Evolved Universal Terrestrial Radio Access Network): The radio network component of LTE, responsible for the air interface and radio resource management.
- EPC (Evolved Packet Core): The core network architecture of LTE, providing data and connectivity services.
- IMS (IP Multimedia Subsystem): A framework for delivering IP multimedia services, including voice, video, and messaging over IP networks.
SIP Protocol in VoLTE.
The Session Initiation Protocol (SIP) is crucial in VoLTE calls. SIP is used to create, update, and terminate VoLTE calls. During a VoLTE call, SIP messages are transmitted, resembling those in 2G/3G voice calls, such as CALL SETUP, SETUP, ALERTING, and CONNECT.
QCI5 and SIP Signaling.
SIP messages in VoLTE are transmitted in Quality of Service Class Identifier 5 (QCI5), which is a default EPS bearer from the User Equipment (UE) towards the IMS Access Point Name (APN). Therefore, SIP signaling in VoLTE occurs in the Packet Switch (PS) domain rather than the traditional Circuit Switch (CS) domain.
IMS Network Elements (NEs) in VoLTE.
Voice over LTE (VoLTE) service relies on the deployment of the IP Multimedia Subsystem (IMS), which is a complex subsystem composed of various network elements (NEs). Some of the typical IMS NEs are listed below, along with their full names and descriptions.
| NE | Full Name | Description |
|---|---|---|
| P-CSCF | Proxy-call session control function | This element resides in the visited network and acts as the first contact point for IMS terminals. It serves as a SIP proxy and transmits SIP signaling between SIP users and their home network. |
| I-CSCF | Interrogating-call session control function | This element serves as the first contact point of the home network. It queries the Home Subscriber Server (HSS) for the address of the Serving-Call Session Control Function (S-CSCF), assigns it to a subscriber performing SIP registration, and forwards SIP requests or responses to the S-CSCF. |
| S-CSCF | Serving-call session control function | This central node of the IMS network resides in the home network. It handles subscriber registrations, authentication, sessions, and service triggering control, and provides routing services. |
| SBC | Session Border Controller | This element provides anti-attack and Network Address Translation (NAT) traversal functions, and converts between IPv4 and IPv6 addresses on signaling and media planes. |
| PCRF | Policy and charging rules function | This element provides Quality of Service (QoS) policies and charging rules to ensure proper service delivery and billing. |
| ATCF | Access Transfer Control Function | This element resides between the P-CSCF and I/S-CSCF and generates a session transfer number for Single Radio Voice Call Continuity (SRVCC) to correlate the session being handed over with the remote session. |
| ATGW | Access Transfer Gateway | This element also resides between the P-CSCF and I/S-CSCF and is responsible for changing the local media plane to a Circuit Switch (CS) access leg without changing the remote media plane. The Media Gateway (MGW) connected to the SRVCC Interworking Function (IWF) provides the media access leg on the CS network. |
| MGCF | Media Gateway Control Function | This element converts between SIP and ISUP/BICC signaling and instructs the IP Multimedia Media Gateway (IM-MGW) to perform media bearer switching. |
| Convergent-HSS | Convergent Home Subscriber Server | This element stores the data of VoLTE subscribers and sends the data to the CS, IMS, or EPC network when requested. |
Bearers for VoLTE
Voice over LTE (VoLTE) utilizes different Quality of Service Class Identifiers (QCIs) to ensure the appropriate handling of voice and video calls over LTE networks, as recommended by 3GPP. Each QCI is standardized with specific parameters to cater to various purposes such as priority and packet loss rate (PLR). The relevant QCIs for VoLTE are detailed below:
QCI Attributes
| QCI | Resource Type | Priority | Packet Delay Budget | Packet Error Loss Rate | QCI Purpose |
|---|---|---|---|---|---|
| 1 | GBR | 2 | 100 ms | 10-2 | Conversational Voice |
| 2 | GBR | 4 | 150 ms | 10-3 | Conversational Video |
| 5 | Non-GBR | 1 | 100 ms | 10-6 | IMS Signaling |
- QCI 1: Dedicated for conversational voice with high priority, low packet delay, and acceptable packet error loss rate.
- QCI 2: Used for conversational video (live streaming) with slightly lower priority and higher packet delay compared to QCI 1, but with a lower packet error loss rate.
- QCI 5: Utilized for IMS signaling, characterized by the highest priority, low packet delay, and extremely low packet error loss rate.
Bearer Setup for VoLTE Services.
The radio network can establish bearers with QCI 1, QCI 2, and QCI 5 for supporting VoLTE services, ensuring higher scheduling priority, reduced packet loss rate, and lower latency.
Bearer Combinations in Different Scenarios
| Scenario | Bearers |
|---|---|
| Non-VoLTE UE | QCI 9 |
| VoLTE UE – Idle | QCI 5 + QCI 9 |
| VoLTE UE – Voice Call Over LTE | QCI 1 + QCI 5 + QCI 9 |
| VoLTE UE – Voice & Video Call | QCI 1 + QCI 2 + QCI 5 + QCI 9 |
- Non-VoLTE UE: Uses only QCI 9.
- VoLTE UE (Idle): Utilizes QCI 5 and QCI 9 to ensure readiness for IMS signaling.
- VoLTE UE (Voice Call Over LTE): Combines QCI 1, QCI 5, and QCI 9 to support voice calls with signaling.
- VoLTE UE (Voice & Video Call Over LTE): Employs QCI 1, QCI 2, QCI 5, and QCI 9 to handle both voice and video calls along with signaling.
These QCI combinations ensure that VoLTE services are delivered with the required quality, prioritizing voice and video traffic appropriately while maintaining efficient signaling.
VoLTE Procedures.
The figure below indicates the standard procedures when a VoLTE UE power on, including registration, calling, and termination.
Architecture of SIP Stack
The Session Initiation Protocol (SIP) is an application-layer control protocol that is used for creating, modifying, and terminating sessions with one or more participants. It is defined in RFC 3261 by the Internet Engineering Task Force (IETF). SIP is widely used in VoIP (Voice over IP) communications and multimedia distribution.
SIP Protocol Stack Overview.
SIP operates on top of the Internet Protocol (IP) and can use either the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP) at the transport layer. The following figure illustrates the SIP protocol stack:
| Application Layer |
| (SIP) |
+--------------------------+
| Transport Layer |
| (TCP/UDP) |
+--------------------------+
| Network Layer |
| (IP) |
+--------------------------+
| Data Link Layer |
| (e.g., Ethernet) |
+--------------------------+
| Physical Layer |
| (e.g., Ethernet Cable) |
+--------------------------+
Key Points:
- Application Layer (SIP):
- SIP is responsible for initiating, maintaining, and terminating real-time sessions.
- These sessions can include voice, video, chat, and other multimedia communications.
- SIP messages are used to set up and tear down calls, manage call features, and handle user mobility.
- Transport Layer (TCP/UDP):
- SIP messages are transmitted using either TCP or UDP.
- UDP is often preferred for its lower latency, though TCP may be used when reliable transmission is necessary.
- The choice between TCP and UDP can depend on the network environment and specific requirements of the SIP application.
- Network Layer (IP):
- IP provides the addressing and routing needed for SIP messages to travel across networks.
- Both IPv4 and IPv6 are supported for SIP communications.
- Data Link Layer and Physical Layer:
- These layers handle the actual transmission of data over physical media (e.g., Ethernet).
- The data link layer is responsible for node-to-node data transfer and error detection.
- The physical layer defines the hardware specifications for networking equipment and media.
SIP Messages Overview.
SIP (Session Initiation Protocol) messages are categorized into requests and responses. Each SIP request is named by a specific word to indicate its purpose. Below is an overview of various SIP messages, their functions, and typical usage scenarios:
| SIP Message | Purpose | Usage Details |
|---|---|---|
| INVITE | Initiate a session and invite other parties to join. | Contains the proposed session description, including media types and parameters. |
| ACK | Confirm receipt of the final response to an INVITE request. | Sent after receiving a 200 OK response to an INVITE. |
| BYE | Terminate a specific session or an attempted session. | Sent by either the caller or the callee to end a call. |
| CANCEL | Cancel a previous request sent by a client. | Used to cancel INVITE requests if a final response has not been received. |
| REGISTER | Register, deregister, or re-register a subscriber to the network. | Sent by a user agent to a SIP registrar. |
| OPTIONS | Query the capabilities of another UA or a proxy server. | Used before setting up a dialog to check supported methods, extensions, etc. |
| PRACK | Confirm receipt of a 1xx provisional response. | Provides reliable provisional responses in SIP. |
| INFO | Communicate mid-session signaling information. | Used for signaling information not directly related to session setup or teardown. |
| MESSAGE | Send instant messages. | Used for IM services within SIP. |
| SUBSCRIBE | Request current state and state updates from a remote node. | Used to subscribe to events such as presence information. |
| NOTIFY | Notify a SIP node that an event requested by an earlier SUBSCRIBE has occurred. | Sent in response to a SUBSCRIBE request. |
| UPDATE | Update media information during an ongoing session. | Used to modify session parameters without re-establishing the session. |
| REFER | Instruct the recipient to contact a third party. | Used to initiate call transfers. |
| PUBLISH | Publish event state to a state agent. | Used by a client to send its current state information to a server. |
Session Initiation Protocol (SIP) uses response codes to indicate the outcome of a request. These codes are three-digit integers, with the first digit categorizing the response.
| Category | Status Code | Reason Phrase | Description |
|---|---|---|---|
| 1xx | 100 | Trying | The request has been received and processing is underway. |
| 180 | Ringing | The destination user agent has received the INVITE and is alerting the user. | |
| 183 | Session Progress | Provides information about the progress of the call setup. | |
| 2xx | 200 | OK | The request has succeeded. |
| 202 | Accepted | Indicates that the subscription has been accepted, and a NOTIFY will be sent (defined in RFC 3265). | |
| 3xx | 300 | Multiple Choices | The address resolved to one or more alternatives. |
| 301 | Moved Permanently | The requested resource has been assigned a new permanent URI. | |
| 4xx | 400 | Bad Request | The request could not be understood due to malformed syntax. |
| 401 | Unauthorized | The request requires user authentication. | |
| 404 | Not Found | The server has definitive information that the user does not exist at the domain specified. | |
| 407 | Proxy Authentication Required | The request requires authentication by a proxy. | |
| 487 | Request Terminated | The request was terminated by a BYE or CANCEL. | |
| 5xx | 500 | Server Internal Error | The server encountered an unexpected condition that prevented it from fulfilling the request. |
| 501 | Not Implemented | The server does not support the functionality required to fulfill the request. | |
| 503 | Service Unavailable | The server is currently unable to handle the request due to temporary overloading or maintenance. | |
| 6xx | 600 | Busy Everywhere | All possible destinations are busy. |
| 603 | Decline | The called party does not wish to participate in the call. | |
| 606 | Not Acceptable | The user’s location cannot accept the request. |