The digital services that can be provisioned to the car are many and diverse. Let’s imagine a driver (and passengers) of a car connected to the Internet. Every move of the car is fed back to Internet services such as Yelp, Opentable, GMaps, GoCallendar, etc making received services ever more relevant and frictionless. Clearly, the use-case possibilities are endless and the most important are captured in a previous post. In Carmesh, we believe that VoIP services will have a reasonable future in the car. Besides the traditional VoIP chat services (e.g., Skype, Hangout, etc), there are a plethora of services that could be built around tourisms. An example here is a city guided tours service, where a user receives a voice description of landmarks and point of interests depending on its location and driving direction. It is easy to imagine other rich content that can come with the voice such as detailed maps, videos for in-depth coverage of landmarks, reviews, etc.
However, one might ask where does the Internet connection come from? In CarMesh we envision a city-wide Wireless Mesh Network (WMN) deployment which enables the car to receive Internet access via either its On-Board-Unit (OBU) or the driver’s mobile phone. While the mobile tsunami means all phones will have decent Internet connections, we still believe that there will be a future for all the existing WiFi infrastructures that are ubiquitous in metropolitan areas, and mostly amortised by their operators. In this post, we’ll elaborate on some thoughts around the issues that arise when using a WMN to place Voice over Internet Protocol (VoIP) calls, which is one of the most cherished Internet services we can expect to see in the future connected car. As described above, we can also expect to see more sophisticated VoIP-based LBS services being built for the connected car.
VoIP is one of the most demanding type of IP traffic. The mouth-to-ear delay that affects any conversation carried over communication networks is one of the most critical requirement. Typically, the recommendation is to keep this delay under 150ms in order to maintain the interactivity of a conversation. How hard is it to meet this requirement? The short answer is “it depends”, a lazy response in appearance but a totally justified one. In wired broadband connections – like those serving our homes – this requirement is not hard to meet. However, in a wireless environment, such as the one used in CarMesh, the situation changes.
The wireless medium such as WiFi is prone to interference and other fading hazards, which means WiFi devices often have to try a few times until a successful transmission is made. Imagining now this nod-ideal situation happening at every WMN relay node composing a WMN network, it becomes clear that the end-to-end (and mouth-to-ear) delay will build up leading to listeners feeling discomfort in conducting a conversation. Is there a solution to this? Research works addressed this topic and came up with two rather obvious solutions: i) giving priority to VoIP packets over other type of traffic in the network and ii) aggregating VoIP packets together so that the wireless medium becomes less congested, squeezing out higher capacity from the network.
These two solutions are capable of keeping the mouth-to-ear delay low enough so VoIP calls are possible in a multi-hop wireless mesh networks altogether. But how is the call quality measured? The International Telecommunication Union devised recommendation P.800, entitled Methods for subjective determination of transmission quality where it is explained how the call quality can be measured. They also proposed a subjective scoring system, nowadays widely used to assess call quality, based on what they call the Mean Opinion Score (MOS). The MOS is also used to assess the quality of video transmissions. For network transmissions, the MOS is obtained using another ITU recommendation (G.107), the E-Model.
Our CarMesh experiments involves a WMN composed of 16 nodes deployed in a grid topology, where the nodes are 125 meters apart. Our network uses two interfaces operating on 802.11a as mesh infrastructure with a 6Mbps physical data rate. In our tests, we were able to support a total number of 48 car users to place calls for which the mean of the MOS remained at satisfactory levels. When aggregating together VoIP packets from the same or different users, the number of calls increased to 67, delivering a not-bad 40% increase in the network’s capacity to support VoIP calls.
In another set of simulations involving the same WMN network described above, we implemented a simple Call Admission Control (CAC) mechanism which was able to reject new call requests in order to protect the existing ones from having their quality degraded. This set of simulations led to the conclusion that undesired situations can occur in unmanaged networks where the QoS levels are not constantly monitored. For VoIP, only one single extra call added to the network over its capacity can degrade the quality of all serving calls – “the drop that spilled the glass” of sorts.
To conclude, VoIP services are possible when used from within a car roaming in a city where Internet connectivity is provided via a wireless mesh network. Its performance can be monitored using the MOS and the E-Model. The prototyping and simulation work conducted under the CARMESH project suggest that VoIP services can be supported in WMNs with a reasonable QoS if the network is appropriately monitored and admission control mechanisms introduced to maintain satisfactory QoS levels.