Introduction
The evolution of 5G networks continues to revolutionize the telecommunications landscape, particularly in the realm of voice services. As we move into 2024, updated protocols and techniques are enabling more efficient, high-quality voice communications over 5G. This blog will explore the latest advancements in 5G voice services, focusing on key aspects such as header compression, VoNR, and fallback procedures.
5g Voice Services Overview
Header Compression in 5G Networks
The protocol stack layers targeted by header compression are illustrated in Figure below. Header compression operates between the UE and the Base Station so it benefits the Radio Access Network but does not benefit the connection from the Base Station towards the IMS. Header compression generates a significant increase in air-interface capacity in terms of the maximum number of supported speech connections.
Figure below compares the throughput requirement for Circuit Switched voice over 3G when using a Dedicated Channel (DCH), with the throughput requirement for VoNR, both with and without header compression. The comparison assumes an AMR 12.2 kbps codec for 3G and an EVS 13.2 kbps codec for VoNR. The comparison also assumes: 1 byte of header information added by the EVS codec; TPv6 rather than IPv4; no header added by the SDAP layer (and so excluded from the figure); a 12 bit Sequence Number for the PDCP layer which leads to a header size of 2 bytes; no segmentation at the RLC layer allowing the use of a single byte header without Sequence Number; a MAC header which includes an 8 bit Length field which leads to a header size of 2 bytes.
Protocol Stack Layers and Header Compression
Circuit Switched voice over a 3G Dedicated Channel uses transparent RLC and MAC layers so the resultant throughput requirement is equal to the bit rate generated by the AMR codec.
In the case of VoNR without header compression, the RTP/UDP/11 protocol stack layers generate a significant overhead. The resultant throughput requirement at the top of the Physical layer is 39.6 kbps, i.e. 3x the bit rate generated by the EVS codec. It is assumed that header compression reduces the overheads generated by the RTP/UDP/TP layers to 4 bytes. This results in a throughput requirement of 17.2 kbps at the top of the Physical layer
RoHC Profiles and UE Capabilities
The IETF defines multiple RoHC profiles to support different protocol stack combinations. Table below presents the set of profiles specified for use by NR within 3GPP TS 38.323. Profiles 1 and 101 are applicable to the speech protocol stack, whereas profiles 2 and 102 are applicable to the RTCP protocol stack. Profiles 101 and 102 are updated versions of profiles 1 and 2.
It is not mandatory for UE to support all of these profiles. UE report their PDCP capability within the RRC: UE Capability Information message. UE specify which RoHC profiles arc supported and also the maximum number of concurrently active RoHC contexts.
Header Compression Techniques
The main principles of header compression are:
avoid sending fields which do not change between consecutive packets
allow the receiver to deduce some changing fields without sending them
apply efficient coding to other changing fields
For example, within an 1Pv6 header, the Source Address (16bytes) and Destination Address (16bytes) do not change for a specific connection. In addition, this information is not used to transfer the packets between the Base Station and UE. Thus, the sending device can remove both of these fields while the receiving device can re-insert them. This is possible after the receiving device has learnt the Source and Destination Addresses by receiving at least one non-compressed header.
RLC and MAC Layer Operations
The PDCP layer can also provide integrity protection and ciphering to maintain the security of the connection. If integrity protection is enabled, the PDCP layer adds a MAC-1 field to the end of the speech packet. The MAC-1 has a length of 4 bytes and is used by the receiver to verify that the packet is authentic.
The PDCP header includes a Sequence Number which is configured by the RRC layer to have a length of either 12 or 18 bits. A 12 bit Sequence Number is accommodated within a header size of 2 bytes, whereas an18 bit Sequence Number is accommodated within a header size of 3 bytes. A 12 bit Sequence Number is expected to be sufficient for the voice service so a header size of 2 bytes can be assumed. The Sequence Number is used to provide in-sequence delivery of the packets to the higher layers.
The Radio Link Control (RLC) layer is specified by 3GPP within TS38.322. Both the RTP and RTCP protocol stacks belonging to VoNR use Unacknowledged Mode (UM) RLC to transfer packets without ARQ re-transmissions. The ARQ re-transmissions supported by Acknowledged Mode RLC are relatively slow and would impact the VoNR delay budget.UM RLC supports segmentation so a packet can be segmented and transferred using multiple resource allocations if the link budget does not permit the throughput required to transfer the whole packet in a single transmission. The UM RLC header size is 1 byte when segmentation is not required. If segmentation is required then the header size can increase to3 bytes when using a6 bit Sequence Number, or to 4 bytes when using a 12 bit Sequence Number.
The Medium Access Control (MAC) layer is specified by 3GPP within TS38.321 . The MAC layer provides support for HARQ re transmissions which are relatively fast and can be completed without having a significant impact upon the VoNR delay budget. The MAC layer also supports multiplexing of data belonging to different logical channels. For example, a speech packet can be multiplexed with a SIP signalling packet, an SRB packet or a data packet.
The MAC header includes a Logical Channel Identity (LCID) and a Length indicator. An 8 bit Length indicator is accommodated within a header size of 2 bytes, whereas a16 bit Length indicator is accommodated within a header size of 3 bytes. An 8 bit Length indicator is sufficient for the voice service so a header size of 2 bytes can be assumed.
Radio Resource Management (RRM) Enhancements
In terms of Radio Resource Management (RRM) the voice service can benefit from:
Discontinuous Reception (DRX): which allows theUE to 'sleep' between consecutive packet transfers. AUE can be configured with a DRX cycle period of 20 ms to match the rate at which the codec generates speech packets. The UE power consumption is reduced if theUE is permitted to sleep for the majority of the 20 ms DRX cycle. For example, aUE could be DRX Active for 4 ms and DRX Inactive for16 ms. The timing of the periodic Scheduling Request cycle can be aligned with the DRX pattern to ensure that the UE only transmits a Scheduling Request when theUE is already DRX Active. This avoids theUE disrupting its sleep cycle to transmit a Scheduling Request. AUE is typically required to disrupt its sleep cycle after transmitting an uplink packet. This is necessary for theUE to check whether or not the Base Station has requested a HARQ re-transmission.
Packet Aggregation: which is used to increase the period between packet transfers. For example, speech packets could be transferred every 40 ms rather than every 20 ms. This requires the sender to buffer packets so there is a negative impact upon the delay budget. Packet Aggregation improves the efficiency of the air-interface by transferring a relatively small number of larger transport blocks, rather than a relatively large number of smaller transport blocks. It reduces the PDCCH load when using dynamic resource allocations because PDCCH transmissions arc required once every 40 ms rather than once every 20 ms (assuming a 40 ms aggregation period). Packet Aggregation also helps to improve the sleep ratio provided by DRX because theUE becomes DRX Active less frequently. An aggregation period of 40 ms can be implemented by configuring a 40 ms Scheduling Request period and a 40 ms DRX cycle duration.
Semi-Persistent Scheduling in the downlink and Configured Grants in the uplink: which can be used to reduce the PDCCH load generated by the speech service. The speech service requires a continuous stream of periodic PDCCH transmissions_when using dynamic resource allocations. Semi-Persistent Scheduling and Configured Grants reduce the requirement for dynamic resource allocations on the PDCCH (resources for re-transmissions are still allocated using the PDCCH). Semi-Persistent Scheduling and Configured Grants rely upon RRC signalling to pre-configure information regarding the resources to be allocated. The PDCCH (or a MAC Control Element) can then be used to activate/deactivate the resources. This approach reduces the flexibility ofthe Packet Scheduler and Link Adaptation because the resource allocations become relatively fixed. However, these solutions remove the risk of resource allocations being missed due to the UE failing to receive a PDCCH transmission, or the Base Station failing to receive a Scheduling Request.
PUSCH Repetition: which is the equivalent of TTI Bundling in LTE. The UE repeats each transmission in consecutive uplink slots. There is one repetition within each slot and each repetition uses the same allocation of symbols. The PUSCH is limited to a single transmission layer when repetition is used, i.e. it is intended to improve coverage and should not be required at locations where the PUSCH is able to benefit from multiple transmission layers.
VoNR Capability Signalling
The UE provides VoNR capability information during the Non Access Stratum (NAS) Registration procedure presented in Figure below.
The NAS: Registration Request message can include the' UE 's Usage Selling' field presented in Table below. Inclusion of this field within the NAS: Registration Request indicates that the higher layers of the UE support the IMS Voice service. The actual value of the field indicates a preference for voice services or data services but docs not indicate any further UE capability information, i.e. a UE which specifies a value of 'Data Centric' also supports the voice service.
The AMF can use the NGAP: UE Radio Capability Check Request to obtain information regarding the UE's support for IMS Voice within the Radio Access Network. This message triggers the Base Station to forward an RRC: UE Capability Enquiry to the UE. Within the context of the NR voice service, the UE responds with the information shown in Table below. The UE indicates its support for IMS voice when this air-interface is EUTRA (LTE) rather than New Radio (NR). In the case of Voice over NR, the UE implementation for handling voice packets can be differ between Frequency Range 1 and Frequency Range 2. This means that the UE is required to signal its support for each Frequency Range separately.
The Base Station responds to the AMF using the NGAP: UE Radio Capability Check Response. This message includes the IMS Voice support lndicator, which specifics whether or not the UE supports the IMS Voice service when using the air-interface provided by the Base Station.
The UE is informed whether or not it is able to use the IMS Voice service within the NAS: Registration Accept message. This message provides information regarding the availability of the IMS Voice service for both 3GPP and non-3GPP access networks. The latter can be applied to Voice over WiFi if a WiFi access network is connected to the 5G Core Network.
EPS Fallback In 5G Voice Services
EPS Fallback can be triggered when a UE initiates an IMS voice call while connected to the 5G Core Network using New Radio (NR). It requires the 5G Core Network to have connectivity to an IP Multimedia Subsystem (IMS) so the SIP signalling procedures can be initiated while the UE is connected to the NR Radio Access Network. The fallback procedure moves the UE onto a 4G Core Network using EUTRA. The 4G Core Network also has connectivity to the TMS so the voice call setup can then be completed. The general network architecture for EPS Fallback is illustrated in Figure below.
EPS Fallback avoids the 5G system having to support a QoS Flow with 5QI = 1, i.e. the 5G system can focus upon providing non-real time data services. In addition, the EUTRA Radio Access Network is likely to have wider coverage than the NR Radio Access Network (at least during early deployment) so the setup of IMS voice calls on 4G avoids the requirement for a 5G to 4G inter-system handover during an ongoing call.
Figure below illustrates the general signalling flow associated with the EPS Fallback procedure. It is assumed that the UE is already registered with the IMS before the procedure begins. The IMS voice call setup is initiated using the SIP Invite message. Figure below illustrates a mobile originated message but the SIP Invite could also be mobile terminated. The first stages of voice call setup proceed in the normal manner, i.e. the IMS triggers the PCF to setup a QoS Flow with 5QI - 1 and the Base Station receives an NGAP: PDU Session Resource Setup Request.
The Base Station is then responsible for taking the decision to apply the EPS Fallback procedure. After taking the decision, the Base Station rejects the request to setup the QoS Flow with 5QI = 1, using the NGAP: PDU Session Resource Setup Response. This message specifies the failure cause as 'IMS voice EPS Fallback or RAT Fallback triggered'. The Base Station is then responsible for moving the UE across to EUTRA from where it can connect to the 4G Core Network. This can be done using an RRC Release with Redirection or a handover. An RRC Release with Redirection uses the RRC Release message to specify a target carrier. This procedure does not specify a target cell. The UE may be requested to complete measurements before the redirection to verify that the target carrier has coverage. A handover uses the RRC Reconifguration message to specify a target cell. Handover procedures usually take advantage of measurements to identify the target cell but it is also possible to use a blind handover procedure without measurements.
If the UE is moved to the 4G network using a handover then the UE completes a Tracking Area Update upon arrival. Similarly, the UE completes a Tracking Area Update if the UE is moved using an RRC Release with Redirection and there is an N26 interface between the AMF and MME. If the UE is moved to the 4G network using an RRC Release with Redirection and there is no N26 interface, then the UE completes an Attach procedure.
The IMS voice call setup procedure then continues on 4G. Once the EPS Bearer with QCI = 1 has been setup, it is possible to trigger an SRVCC towards 2G or 3G. This would change the Core Network domain from packet switched to circuit switched. It is also possible for the 4G network to trigger a CS Fallback procedure towards 2G or 3G during the initial setup.
A UE does not explicitly indicate its support for the EPS Fallback procedure. lt is assumed that the UE supports the procedure if the UE has indicated that it supports VoLTE. The AMF uses the Redirection for Voice EPS Fallback' flag within the NGAP: Initial Context Setup Request to inform the Base Station whether or not EPS Fallback is supported for a specific UE. This flag can also be provided within the NGAP: Handover Request and NGAP: Path Switch Request Acknowledge messages.
RAT Fallback In 5g Voice Services
RAT Fallback can be triggered when a UE initiates an IMS voice call while connected to the 5G Core Network using New Radio (NR). It requires the 5G Core Network to have connectivity to an IP Multimedia Subsystem (IMS) so the SIP signalling procedures can be initiated while the UE is connected to the NR Radio Access Network. The tailback changes the Radio Access Network from NR to EUTRA while maintaining connectivity to the 5G Core Network. The general network architecture for the RAT Fallback is illustrated in Figure below..
RAT Fallback avoids the NR Base Station having lo support QoS Flows with 5QI = 1. In addition, EUTRA Base Stations may provide better coverage than NR Base Stations typically due to lower operating bands and larger site numbers during early NR deployment.
The signalling flow associated with RAT Fallback is similar to the signalling flow associated with EPS Fallback. The SIP signalling used to initiate the IMS voice call setup is initiated while the UE is using the NR air-interface. The fMS triggers the PCF to sen1p a QoS Flow with 5QI = 1 and the Base Station receives an NGAP: PDU Session Resource Setup Request.
The Base Station is then responsible for taking the decision to apply the RAT Fallback procedure. After taking the decision, the Base Station rejects the request to setup the QoS Flow with 5QI = 1, using the NGAP: PDU Session Resource Setup Response. This message specifics the failure cause as IMS voice EPS Fallback or RAT Fallback triggered. The Base Station is then responsible for moving the VE across to EUTRA. This can be done using an RRC Release with Redirection or a handover.
The IMS voice call setup procedure then continues on EUTRA in combination with the 5G Core Network. In this case, it is not possible to trigger an SRVCC towards 2G nor 3G when the system is based upon the release 15 version of the specifications. An SRVCC towards 3G is planned for the release 16 version of the specifications.
Conclusion
The 2024 updates to 5G voice services bring significant advancements in efficiency and coverage, particularly through the use of header compression and fallback procedures. These enhancements enable better voice quality and seamless connectivity, ensuring that 5G networks continue to meet the demands of modern communication.
As 5G deployment continues to expand, these technical innovations will play a critical role in delivering high-quality voice services across diverse network environments.
References
Comments