It has been about a year or so since our last blog on VoWiFi service and we finally see how the service has been catching speed in the US with At&T, Vzw and apparently Sprint too, all joining the VoWiFi pioneer T-Mobile. So, since the service is here, we should ask ourselves what and which scenarios need to be tested for a trouble-free deployment and roll out.
Let's remind ourselves that VoWiFi service has been designed to be offered as an improved alternative of OTT best effort voice bearer. Therefore, VoWiFi is challenged by the real time characteristics of the voice service as well as the need for service seamless continuity across the two RANs, cellular and WiFi. The latter is the core of VoWiFi superiority against OTT and the main leverage operators have against OTT providers. It is worth noting that the operators have been focused on LTE only as the cellular network, rather than 3G and/or 2G ,although 3GPP defined the specs for these well.
As we describe in our white paper, launching VoWiFi and securing its expected users' perceived QoE is not a walk in the park. This is expected, though, since we are talking about voice over WiFi over IMS that needs to meet the QoS requirements of the dedicated LTE voice bearer.
Although spoiled with yet another money saving service like VoWiFi, subscribers won't accept giving up neither of their demands for the expected voice QoE nor for the WiFi data and video services QoE that they experienced before voice is offered to them too.
Therefore, operators have to evaluate and analyze various aspects related not only with the delivery of VoWiFi service but also with its interaction with possible data and/or video service running in the background while user is on a call and/or receives/places a call.
As a reminder, here are some aspects that we think need to be investigated, evaluated and monitored in regards to VoWiFi.
First, comes the devices' behavior within the context of the WiFi network selection since they play the decisive role in the network selection process, and the algorithms based on which they are deciding are different and, more importantly,non-standardized. If close to the LTE-WiFi boarder, a call set up can fail and/or quickly drop, or voice interruption can be noticed if a ping-pong effect happens due to improper WiFi selection (e.g. too loaded, poorer quality than cellular, no enough backhaul available).
Second, voice service continuity between the two radio accesses needs to take place seamlessly, with no voice interruptions. One main contributor can be the IP address preservation mechanisms, vendor dependent and non-standardized.
Third, it is about the impact of the WiFi type, trusted (over SaMoG) and non-trusted (over IPsec), which can impact the call set up time and/or handover latency from LTE due to a different number of WiFi encryption levels. In addition, depending on the device, battery life can be drained faster if this is frequently accessing more highly encrypted WiFi networks. The immediate effect of poor battery life can be reflected in the device measurements' quality degradation and can therefore result in poor decision making when selecting the WiFi. Trusted WiFi networks can require longer authentication, registration, APN dedication and IP allocation time, and therefore the delay until voice bearer is established can become annoying for the user.
Last, but not least, is the end-to-end service quality, expressed through quality metrics such as QoE (MOS), set-up time, continuity, mouth to ear delay, as well as block and drop rate.
Now, all these aspects need to be evaluated in different real life scenarios, which can be categorized in WiFi only and mixed WiFi — LTE, covering both directions to/from.
There are two categories of scenarios that are recommended to be tested. The first category refers to voice only, while the second category refers to voice and background data/video services, respectively the interaction and simultaneous coexistence of the real time and non-real time services.
Here are the recommended test scenarios for the first category — WiFi-only quality with calls between two mobiles. In this scenario, the overall end-to-end quality has to cover call set up time, block and drop rate, MOS and mouth to ear delay. This scenario has the scope to evaluate if a WiFi call quality can match VoLTE quality, as well as how it performs versus an OTT best effort voice bearer alternative. It should also show better quality since subscribers will otherwise stick with already free OTT solutions.
Another scenario has to cover all the above metrics as well as handover latency for calls between two mobiles, but with one stationed in LTE and the other in WiFi network. In addition, both alternatives, with call originated in WiFi and in LTE, need to be analyzed. The devices camped in each of the two networks have to remain stationed (stationary and semi-stationary, respectively walking) there. This scenario has the scope to evaluate and analyze possible differences between call set up performance if call originated in LTE and WiFi. In addition, the scenario can unveil latency differences if the handover is placed from WiFi to LTE and vice versa. The measurements' consistency is important in this case, and that is why stationary and/or walking scenarios are both recommended.
The next scenario needs to focus in more detail on service's continuity. Calls are placed between two devices, both in the same network (e.g. WiFi), and then during the call one moves out to the other network (e.g. LTE) and then comes back. The scenario needs to be repeated with LTE as the initial call set-up network. Handover latency performance must be addressed as well, as its correlation with possible speech interruptions and consequently MOS scores has to be evaluated.
Last, but not least, in this category, we have to evaluate all the above scenarios, with time increasing load on WiFi, which can be created either by simulated probes accessing the WiFi or by artificially throttling the WiFi bandwidth. This scenario is aimed to both unveil whether voice quality degradation occurs, as well as to determine if and at which load levels the devices won't select a loaded WiFi network. It is also interesting to evaluate the performances of various devices.
The second category has to repeat all of the scenarios from the first category, but now with background data/video sessions on going (e.g. ftp/video download). The scope of this scenario is to evaluate both the voice service performance as well as the data/video services while the two co-exist.
The next scenario in this category is focused on the data/video service behavior during the voice service set-up as well as after hang up, respectively, if any interruption has been detected and if so for how long.
It is recommended to repeat the scenario with time increasing WiFi load.
And now, you may be asking yourselves “are our tools going to support all of these scenarios?” The answer is yes. We are currently working in developing these and to be ready to start evaluations. Stay tuned!
