Zeroize: A new method to improve utilizing 5G networks when running VoIP over IPv6

5G technology propagation curve is ascending rapidly. 5G will open up the horizon to improve the performance of many other IP-based services such as voice over IP (VoIP). VoIP is a worldwide technology that is expected to rule the telecommunication world in the near future. However, VoIP has expended a significant part of the 5G technology bandwidth with no valuable use owing to its lengthy packet header. This issue even worsens when VoIP works in IPv6 networks, where the wasted bandwidth and airtime may reach 85.7% of 5G networks. VoIP developers have exerted many efforts to tackle this snag. This study adds to these efforts by proposing a new method called Zeroize (zero sizes). The main idea of the Zeroize method is to use superfluous fields of the IPv6 protocol header to carry the digital voice data of the packet and, thus, reduce or zeroize the VoIP packet payload. Although simple, the Zeroize method achieves a considerable reduction of the wasted bandwidth of 5G networks, which also directly affects the consumed airtime. The performance analysis of the Zeroize method shows that the consumed bandwidth is saved by 20% with the G.723.1 codec. Thus, the Zeroize method is a promising solution to reduce the wasted bandwidth and airtime of 5G networks when running VoIP over IPv6.


Introduction
The world of technology world is continually changing and developing to advance the current technologies with new services and features that make people's lives easier, faster, and better. As an advancement of 4G, 5G technology opens up the horizon to improve many other services and technologies owing to its superior bandwidth and download speeds [1]. The number of subscribers of 5G technology is predicted to increase 10 times by 2025 and reach 1.7 billion [2].
Voice over IP (VoIP) is a promising technology that brings substantial benefits for subscribers. VoIP allows subscribers to communicate to anyone around the world freely using smartphones or any other smart devices. This is because the VoIP data move in IP packets over the data connection. The number of mobile VoIP users is expected to be more than 3 billion [3,4]. Mobile VoIP technology necessitates little latency in data transmission. Accordingly, one of the services that will remarkably improve when working with 5G technology is VoIP. VoIP systems are anticipated to wholeheartedly embrace 5G technology. VoIP will benefit from the high speed of 5G to boost the call quality up to user satisfaction. VoIP will also benefit from the high bandwidth of 5G to tremendously maximize the call capacity [5,6].
In spite of these possible benefits, VoIP is wasting a considerable share of the 5G technology bandwidth with no valuable use. This is due to the lengthy header of the VoIP packet compared with its payload [7,8]. For instance, assume the G.728 codec is used, which produces 10-byte digital voice data (packet payload). In the case of IPv4, the header of the VoIP packet, which consists of 40-byte RTP/UDP/IPv4 (12-byte RTP, 8-byte UDP, and 20-byte IPv4), will waste up to 80% of the bandwidth specified for a VoIP call. When it comes to IPv6, the problem even worsens. That is, the header of the VoIP packet, which consists of 60-byte RTP/UDP/IPv6 (40-byte IPv6), will waste up to around 85.7% of the bandwidth specified for a VoIP call. This is a huge waste of bandwidth resources. Table 1 shows the apportioned bandwidth of different voice codes [9,10,11]. A huge amount of wasted bandwidth is evident with all the codecs. Theoretically, this also consumes the same percentage of the transmission time of the 5G networks. Year after year, the propagation of the IPv6 protocol has increased. IPv6 has emerged from the "Innovators" and "Early Adoption" stages of deployment and is now in the "Early Majority" phase [12]. According to [12], the global adoption of IPv6 rate has increased from 2.8% in 2014 to 23.48% as of 2018. The worldwide adoption of IPv6 has been growing intensely with an average of more than 51% each year [13]. The integration of VoIP and IPv6 over 5G networks is inevitable. Therefore, the above problem of wasting the resources of 5G networks should be considered and carefully investigated. VoIP developers have come out with many solutions to the lengthy header of VoIP. These solutions include combining the VoIP packet in one header, compacting the header of the packet, replacing the VoIP header protocols with new VoIP-specific protocols, and utilizing the header superfluous fields to carry the voice data of the packet [11,14,15]. The main advantage of the last solution is that many of the methods proposed under it are compatible with the existing standards and equipment, so they are workable in the current environment with no major changes. However, none of these methods have been developed for VoIP when using IPv6 specifically over 5G networks. In this article, a new method is put forward to enhance the bandwidth utilization of 5G networks when running VoIP on IPv6. The proposed method uses the superfluous fields of the IPv6 protocol to carry the digital voice data of the packet. Doing so reduces the payload size and enhances the bandwidth utilization of 5G networks. Indirectly, this also affects the quality of the voice connection owing to the decrease in packet loss and delay.
The paper is presented as follows. Section 2 reveals the main solutions that handle the bandwidth problem of VoIP. Section 3 reveals the introduced method, including its core idea of handling the bandwidth issue using the IPv6 protocol fields to carry the packet payload. Section 4 reveals the performance of the proposed method versus the other comparable methods. Section 5 summarizes the findings of this study.

Related Works
The bandwidth obstacle has slowed the propagation of VoIP for some time. Many solutions have been proposed to overcome this obstacle and accelerate the adoption of VoIP. One of the first solutions suggested is collecting the packets that are sharing the same path and encapsulating them in one header, which is known as the packet/frame aggregation standard. A considerable number of methods have been invented under this packet/frame aggregation standard. Some of these methods have been designed to aggregate the frames at layer 2 in one header, whereas others have been designed to aggregate the packets at layer 3 in one header. Performing the aggregation at layer 2 accomplishes better bandwidth utilization. In addition, maximizing the number of aggregated packets, which is based on the parameters of the environment, saves more bandwidth [3,16]. Seytnazarov et al. came up with one of the best aggregation methods in 2018. Seytnazarov's method works in the IEEE 802.11n wireless networks. At the transmitter, several layer-2 frames (i.e., multiplexing MAC protocol data unit [MPDU]) are grouped in one aggregated (A-MPDU). If one of the grouped MPDUs is spoiled, then it causes the re-sending of only that MPDU. The frames in the suggested method are also split into three groups, i.e., voice, video, and streaming groups with priority queuing (PQ), which assumes scheduling. The A-MPDU's allowable length fluctuations adapt according to the urgency delay (UD), which is the remaining period to dequeue the frame. The frame with the minimal UD is the first frame added to the A-MPDU. Basing on the remaining UD of this frame, the allowable aggregation time of the A-MPDU is set. In addition to frame aggregation, a new scheduling mechanism has been suggested to handle the drawbacks of the PQ scheduler under saturated conditions. The analysis of the suggested technique shows an advanced throughput rate with minor delay and packet loss than the other comparable methods [16].
Another established solution for the bandwidth snag is compacting the header of the packet, which is known as header compression, by eliminating some of the header's fields. The other end of the call can obtain their values using simple derivations because they are following certain patterns. The header is compacted up to 2-byte when using IPv4, which greatly saves the bandwidth. William A. Flanagan designed one of the recent compression methods in 2020, which was named "Session Bridging." It is a new custom of header compression that lessens bandwidth poverty. This method splits links into end chunks marked by distinct protocol instances using standard headers. A chunk segment between them conveys voice data with compressed headers. This method takes the benefit of MPLS/virtual Ethernet connections in current networks. The analysis of certain network proof that Session Bridging is viable for latency-sensitive applications (e.g., VoIP and gaming) [17].
Some of the VoIP developers have suggested creating other VoIP-specific protocols such as the IAX protocol. Although IAX can carry all kinds of streaming media, it is mainly developed for voice calls over IP commuter networks. IAX uses its 4-byte mini-header to carry the digital voice data and replace the 12-byte RTP protocol, which saves a good amount of bandwidth. In addition, the IAX protocol supports trunking in which voice data from several sessions are combined in one stream of packets. This saves a huge share of bandwidth consumed by the IP header with no extra delay [18].
Finally, one of the most recent considered solutions is to utilize the header's superfluous fields to carry the voice data of the packet. This solution is based on the assumption that the VoIP packet header protocol is used to transfer various types of application data. Therefore, some of the fields in these protocols are necessary with some applications, but they are not with some other applications. The latter are burdening the bandwidth with no valuable use. These fields are called the superfluous fields [14,15]. This last solution to the bandwidth problem uses the superfluous fields to carry the voice data of the packet and, thus, reduce or even eliminate the payload and save the bandwidth. One of the best methods under this solution is by Abualhaj et al., and it is named short voice frame (SVF). The SVF method successfully utilizes the seven superfluous fields of the packet header on the basis of certain assumptions. These fields manage to save 17-byte of each VoIP packet, which is typically between 50-byte and 70-byte. The analysis result proves that the saved bandwidth can reach around 29% in certain cases [14]. Another method, called zero size payload (ZSP), is developed to utilize superfluous fields. The ZSP method uses different assumptions than the SVF method. Therefore, it manages to utilize the 10 superfluous fields with 19-byte. The analysis result confirms that the saved bandwidth can reach around 32% in certain cases [15].
Developers have exerted great effort to save the bandwidth when running VoIP. The bandwidth issue becomes more of a dilemma when integrating VoIP and IPv6 protocol owing to the large size of the IPv6 header. However, the bandwidth dilemma of VoIP and IPv6 protocol is not addressed enough, especially with 5G wireless networks. In this study, a new method is designed to solve this dilemma using the superfluous fields in the VoIP packet header. The proposed method minimizes the VoIP packet payload size or make it zero. Accordingly, the designed method is called Zeroize (zero sizes).

Zeroize Method Design
This section discusses the working mechanism of the designed Zeroize method. The main aim of the Zeroize method is to increase the capacity of the 5G network channel when running VoIP over IPv6 protocol. The Zeroize method applies to the caller client (e.g., Xlite) as well as the intermediary wireless equipment (e.g., wireless router). Implementing the Zeroize method on either can enhance the channel capacity with the same ratio. This study assumes that the Zeroize method can be applied to the caller client. Figure 1 shows a topology in which the Zeroize method can be implemented.

Core Idea
The Zeroize method uses the superfluous fields of the VoIP packet header to increase the call capacity. The superfluous fields are used to keep the digital voice data of the packet. The works in [14] and [15] deem several fields of the VoIP packet as superfluous for VoIP applications based on certain rules. Several fields throughout the RTP, UDP, and IPv4 meet the rules yet deemed superfluous, including the source IPv4 address. However, the Zeroize method is intended for VoIP over IPv6 protocol. The size of the source IPv6 address is 128-bit (16-byte), which is greater than any common codec frame, as shown in Table 1. Therefore, only the source IPv6 address is deemed as a superfluous field and used to keep the digital voice data of the packet.

Source IPv6 Address
In packet-based networks, the purpose of the source IPv6 address is to identify the sender of the data. Then, the receiver uses this source IPv6 address to send back a response to the sender [19]. In VoIP applications, the call is started over two stages, namely, signaling and media transfer. In the signaling stage, a specific protocol is utilized (e.g., SIP protocol) to start the call and agree upon the call parameters, including the IPv6 address of each of the call ends. In other words, each of the calls knows the IPv6 address of the other end at this stage. In the media transfer stage, a different specific protocol is utilized (e.g., RTP protocol) to carry the voice data [20,21]. The RTP, with the help of other protocols (i.e., UDP/IPv6), uses the call parameters from the first stage, including the IPv6 address, to send the voice data to the intended destination. The point is that the source IPv6 address is included in every voice data packet (media packets). However, the VoIP media transfer session is not a request/response and, thus, the callee client does not send back a response to the sender by itself. Moreover, in case the callee replies to the caller, then the callee client will use the source IPv6 address, which is known from the first stage [14,15,19]. Accordingly, the source IPv6 address in the voice data packets is superfluous and can be assigned a different purpose such as carrying the voice data itself. This reduces the consumed bandwidth by each call and, thus, increase the channel call capacity.

Carrying the Voice Data
The Zeroize method uses the source IPv6 address of the packet to carry the voice data. The sender client extracts the voice data from the packet. Then, the voice data are placed in the source IPv6 address field. As the voice data are small, the remaining bits of the IPv6 address are padded. This process changes the packet payload length and, thus, affects the Payload Length field in the IPv6 header and the Length field in the UDP header [19]. Therefore, the value of these fields should be modified appropriately on the basis of the new size. The pseudo-code in Figure 2 clarifies the process performed at the sender side by the VoIP client. At the receiver, the VoIP client extracts the voice data from the source IPv6 address field and places it in the playout buffer. Only the voice data must be extracted without the padding. For this, the VoIP client should check the used codec to specify the length of the voice data. The used codec is specified in the signaling stage of the VoIP call. Figure 3 clarifies the process performed at the receiver side by the VoIP client.

Zeroize Method Performance Analysis
This section analyzes the proposed Zeroize method. Although intended for 5G networks, the Zeroize method applies to many other wireless technologies (e.g., IEEE 802.11). The method is thus analyzed on the basis of the layer 3 header and above as the layer 2 header changes depending on the used technology. The Zeroize method is tested and analyzed versus the standard RTP (S-RTP method) method of transferring the VoIP packets, the SVF method proposed in [14], and the ZSP method proposed in [15]. The SVF and ZSP methods are selected because they are similar to the proposed Zeroize method. They are using the same concept of superfluous fields and they are one of the recent robust methods in this area. The proposed Zeroize method is tested versus the other methods in terms of channel capacity and apportioned bandwidth reduction. The LPC, G.726, and G.723.1 codecs are assumed for the comparison.

Channel Capacity (Ch-Capacity)
The Ch-Capacity of the proposed Zeroize method is revealed in this section. The Ch-Capacity is analyzed for each channel bandwidth between 100 kbps and 1000 kbps. Losing the packets designates that the channel is saturated. Hence, the Ch-Capacity of a channel equals the number of calls afore losing the packets, and it is measured accordingly. Figure 4, Figure 5, and Figure 6 explore the Ch-Capacity for the Zeroize method in comparison to the S-RTP, SVF, and ZSP methods with G.723.1, G.726, and LPC codecs, respectively. The Ch-Capacity when using the Zeroize method outperforms (more calls) the S-RTP method. In addition, the difference in the Ch-Capacity increases with the existing bandwidth. This is due to eliminating the payload by utilizing the superfluous field (source IPv6 address) of the header to carry the payload. However, the Ch-Capacity when using the Zeroize method underperforms (fewer calls) the SVF and ZSP methods. This is because the header of the IPv6 protocol header is twice the IPv4 protocol header and, thus, it consumes more bandwidth for each call. In addition, the size of the superfluous fields of both SVF and ZSP methods is more than that of the Zeroize method. Note that the Ch-Capacity of the SVF and ZSP methods is the same as the LPC codec.

Apportioned Bandwidth Reduction
The apportioned bandwidth ratio of the proposed Zeroize method is revealed in this section. The apportioned bandwidth ratio is analyzed with 10 to 100 calls. The Zeroize, SVF, and ZSP methods are analyzed in comparison to the S-RTP method. Figure 7 shows the bandwidth reduction of the Zeroize, SVF, and ZSP methods in comparison to the S-RTP. The apportioned bandwidth saving when using the Zeroize method is around 20% compared with that of the S-RTP method, with the G.723.1 codec. However, the bandwidth saving when using the Zeroize method underperforms  the SVF and ZSP methods. This is because the header of the IPv6 protocol header is twice the IPv4 protocol header and, thus, it consumes more bandwidth for each call. In addition, the size of the superfluous fields of both SVF and ZSP methods is more than that of the Zeroize method.
As we can notice, the SVF and ZSP methods outperform the Zeroize method Ch-Capacity and apportioned bandwidth reduction. However, the Zeroize method works over IPv6 networks, unlike both SVF and ZSP methods, which are working over IPv4 networks. In addition, the SVF and ZSP methods utilize many fields as superfluous fields to carry the voice data. This makes them workable only in specific scenarios; the scenarios which they designed for. However, the Zeroize method utilizes only the source IPv6 address field as a superfluous field to carry the voice data. This makes the Zeroize method a more general method that works in all scenarios. Finally, due to the use of many superfluous fields, the SVF and ZSP methods make many calculations, which will consume more resources that might burden the network. On the other hand, the Zeroize method is very simple and consumes lesser resources.

Conclusion
VoIP services provide plenty of features that make them very wide-reaching in the telecommunication sector. The integration of VoIP and IPv6 over 5G networks is unavoidable. This integration leads to wasting up to 85.7% 5G networks bandwidth and airtime. This study contributes to the efforts in solving this issue by proposing the Zeroize method. The method succeeds in using the source IPv6 address field in the IPv6 protocol header to carry the digital voice data of the packet and, thus, reduces or eliminates the VoIP packet payload. The Zeroize method is compared with S-RTP, SVF, and ZSP methods using three different codecs (LPC, G.726, and G.723.1). The Zeroize method reduces the wasted bandwidth by 20% compared with the S-