Exploring Wireless Mesh Networks for Collaborative Augmented Reality Environments

Augmented Reality (AR) has emerged as a technology able to greatly support the interaction between people and digital information by merging virtual objects with the real environment. So far, research in this field has been mainly focused on single-user scenarios with pre-stored digital data whose visualization needs to be appropriately and promptly aligned with physical objects. Instead, latest developments of AR also involve collaborative scenarios where several participants share the same AR environment, generating and exchanging data in real-time, and communicating with each other through VoIP. To this aim, in this work we consider networking issues and possible solutions, as they represent crucial aspects when dealing with collaborative AR environments. Through the use of a real testbed, we discuss how Wireless Mesh Networks (WMNs) can be practically employed to support communications in a department-wide AR environment without the need of a fixed infrastructure. We also analyze the performance limitations of this architecture and, finally, we evaluate a possible practical QoS solution to overcome them.


INTRODUCTION
In recent years, Augmented Reality (AR) has been subject by a raising interest from both researchers and practitioners. This is due the infinite possibilities for AR technology to complement and improve the way we interact with our favorite digital services. Indeed, while sociologists agree that we are living in an Information Society, it is also evident that we are not naturally equipped to manage all the information that is available to us. Simply, our real world is not anymore made of only physical objects but includes also all the digital information that is somehow related to.
AR is perfectly suited to help us in perceiving and managing both our physical world and our information world altogether. Born as a variation of Virtual Reality (VR), AR differs from its ancestor for it does not immerse the user into an exclusively virtual environment; rather, it supplements reality by superimposing digital objects upon the real world, which remains visible for the user.
Most of the studies about AR environments have focused on the problem of promptly aligning digital objects over the real Manuscript received on August 1, 2009 E-Mail: cpalazzi@math.unipd.it world. To this aim, most of the experimental testbeds reported in scientific literature consider an off-line single user with pre-stored information about digital objects to be visualized depending on the user's position and scene in front of her/him, thus requiring efficient technologies in terms of position tracking, image recognition, rendering, and alignment [1][2][3][4][5][6][7][8][9][10][11][12][13].
Studies have been performed analyzing communications in a collaborative AR environment, aiming at improving the synchronization among different terminals [14]. Yet, to the best of our knowledge, no study has been performed that analyzed network traffic performance and limits in complex wireless network topologies with both data and voice communications among participants. Instead, these environments represent a very interesting case study, both for the appealing applications that can be deployed (e.g., team coordination for first aid operations) and for the challenges involved (e.g., prompt delivery of data generated by any participant to the whole team through multi-hop wireless connectivity).
In essence, since the current proliferation of collaborative applications, the advancements of AR technology, and the growing availability of wireless devices, it is now interesting to study how these technologies can be integrated to create effective collaborative AR applications based on wireless communications in a department-wide physical environment. To this aim we deem as particularly suited the use of Wireless Mesh Networks (WMNs) based on the IEEE 802.11s standard. These networks are composed by a dynamic collection of backhaul routers so as to extend the coverage area of a Wireless Local Area Network (WLAN) from a hot spot to a hot zone composed by various hot spots [15].
The use of WMN architecture is ideal for a collaborative AR environment as it enables wireless communications among participants in a hot zone, such as a department, in a quick and simple way. However, we also need to evaluate the performance efficiency of WMNs in supporting the involved services, e.g., control messages and voice over IP (VoIP) communications among several users. To this aim, the main contributions of this paper are related to providing practical directions for the networking support of collaborative AR environments with existing technology, and can be summarized as follows:  analysis of networking issues related to the practical deployment of collaborative AR environments;  proposal of a networking architecture, based on WMN technology, to support communications among participants in the considered context;  creation of a real testbed to evaluate the proposed architecture;  evaluation of a practical Quality of Service (QoS) solution to support the interactivity level of main services offered to participants. The rest of the paper is organized as follows. In Section II we summarize main applications that would greatly benefit by the use of AR technology. Section III provides background information to understand networking issues related to collaborative AR environments. In Section IV we describe our WMN testbed. The experimental evaluation is presented in Section V. Finally, conclusions are drawn in Section VI.

II. AUGMENTED REALITY: COLLABORATIVE APPLICATIONS
Augmented Reality, also known as Mixed Reality, is the technology that enables to superimpose digital data (e.g., images, links to web pages, 3D objects) upon a user's view of the real world [16][17][18]. It is clear how AR descended from Virtual Reality (VR), however, whereas the latter completely immerses a user in a digital environment, the former combines digital and physical world. From a research point of view, AR is particularly interesting both for its technical challenges and for its appealing applications; this is especially true if considering collaborative AR applications. To this aim, we present here a descriptive overview of potential AR applications, whereas a technical discussion is provided in Section III.
Indeed, collaborative AR is potentially able to enhance the way users perceive the world and interact with/through it. By overlaying digital data over the physical view it is possible to provide users with a shared, synthetic, information-based "sixth sense". Possible applications for this technology are limited only by our imagination. In the following we provide a representative list of possible employments for collaborative AR technology.
Medical applications. AR can be used to enhance a doctor's view of a patient, especially for virtual anatomy learning, pre-treatment planning, non-invasive surgery, and remote operations [1]. Data generated by magnetic resonance, computed tomography scans, X-rays, and ultrasounds could be directly projected over the patient's body or over a remote manikin, allowing the doctor to see inside the patient and perform precise operations without the need for large incisions, and wherever the doctor(s) and the patients are located with respect to each other [3,5].
Maintenance and assembly. Assembling, maintaining and repairing could be tough tasks when regarding complex machineries. To ease these tasks, AR can project online instructions, drawings, step-by-step animated examples, known issues, and previously performed reparations over the operator's view of the machinery [6,7]. Furthermore, to help any operator that may be in front of the broken machinery, suggestions could be prepared in real-time by remote highly specialized operators and projected over the machinery, along with instructions and requests simultaneously exchanged by voice communication.
Annotations. People use notes as reminders or to leave messages for others. These notes could be replaced by digital ones left in an AR environment [8,9]. As a major advantage, digital notes could be easily customized to be public or specifically destined to a certain user (and existing only in the AR environment as seen by this user); moreover, they could also be automatically generated from databases (e.g., labels in a store) and instantaneously modified over the entire AR environment with just one click/event in a remote location.
Safety ensuring applications. Virtual lines and objects, even through Head-Up Displays (HUDs), can be used to aid the navigation, especially in conditions of limited visibility (e.g., under water, in outer space, with adverse meteorological conditions), or to support and coordinate first aid squads in an emergency area after a crisis (e.g., earthquake, flooding, major accident) [10]. Indeed, it is not hard to imagine a scenario where first aid squads in an emergency area utilize HUDs with superimposed information about dangers and people's health conditions, while coordinating through voice communication.
Entertainment applications. Entertainment applications can exploit AR technology in several ways. For instance, merging real actors with virtual ones over real or virtual landscapes has become a regular practice in Hollywood movies allowing great visual effects at a reduced production cost. This technology is soon going to be used also for gaming applications bringing real people (maybe organized in squads) into a virtual or mixed-reality arena populated by both digital creatures and human ones [19][20][21][22][23].
Cultural heritage applications. Presentations based on AR technologies provide museum visitors with the possibility to enrich their visit, interact with (the digital representation of) a piece of art, choose the level of reconstruction of artifacts and historical sites, and, in general, foster new participative learning applications [11,12], [24,25]. Furthermore, investigators can use digital notes superimposed on archeological sites or paintings to attach information to the object of study in a non-invasive way and make it available to other researchers to facilitate research in collaboration [26].

III. TECHNICAL BACKGROUND
In this section we discuss technical information related to the performance of a WMN supporting collaborative AR applications. In particular, in the first subsection, we highlight the importance of networking in the considered context. The second subsection discusses main networking issues for the considered application. Finally, in the third subsection, we report on previous experimental studies of WMNs.

Networking in Collaborative Augmented Reality Environments: Provided Services
Applications discussed in Section II can be run off-line, by simply pre-storing on the device all the digital information that will be superimposed on the real world. Yet, this method sensibly limits the potentiality of AR applications. For instance, revising the list of applications provided in Section II, we can envision various appealing services that can be enabled only by networking capabilities. In the following we report a limited but representative list of them.
First, any of the applications mentioned in Section II could be run by a remote location, e.g., remote surgery, remote maintenance, remote annotation. Actions performed by a remote operator could be transmitted in real-time to be locally executed by a machine or just superimposed on the HUD of a local operator in order to assist her/him. Second, when operating in groups, actions performed by a user may affect even other team members. For instance, think of online game players immersed in an AR arena competing with each other: information about "shooting" at a certain player has to be transmitted to the target player and information about decreased points of the hit player has to be transmitted to all participants. Another example is represented by an employer that has to temporarily leave his office and leaves a virtual note on the door that automatically reports his current location within the building in case somebody urgently needs him.
Third, voice communication among users may be of prominent importance for many collaborative AR applications. Indeed, while sending control messages and assigning virtual notes represent important features, voice communications often is necessary, or desirable, or just the fastest way to coordinate a group of users. To this aim, think again of the doctor remotely assisting another one, or of the game players (or first aid responders) organized in teams where members of the same team can communicate with each other. This kind of communication has to be an integral part of the software architecture supporting the collaborative AR environment. In this sense, it may be deployed as a VoIP service integrated within the system.
Last but not least, video streaming may sometimes be used to transmit video generated in real-time. A simple example of this case is represented by a video-chat among doctors (or game players, or first aid responders) located far from each other and needing richer communicative means than simple voice. Note that this case is strictly related to the real-time generation/consumption of the video; otherwise, a video could simply be transmitted as any other file (e.g., a digital note).

Networking in Collaborative Augmented Reality Environments: Challenges
Networking services depicted in the previous subsection may be roughly summarized as: i) transmitting information about virtual notes digitally attached to certain real object to users walking by the area where the object is located; ii) transmitting control messages (e.g., machinery movements, game events) to users belonging to a certain group or located in a certain area; iii) establishing VoIP communications among users or groups of users; iv) establishing video stream communications among users or group of users. Providing these services passes through enabling a continuous coverage in the whole AR area and ensuring a certain performance level.
Focusing on the former, we have to keep in mind that users could be moving in an area wider than a single hot spot, thereby, providing seamless connectivity becomes a non-trivial challenge. However, mesh networks embody a perfect answer to this challenge thanks to their ability in merging various hot spots into a unified hot zone. Yet, having several wireless nodes moving around the AR area transmitting, receiving, and relaying data through different APs may generate interference and congestion that cause the loss of several transmitted packets. Even if the considered applications (e.g., control messages, VoIP) are generally resilient to (few) packet losses, having a highly unreliable channel may negatively affect the performance of the system as perceived by users, for instance, by loosing movements remotely commanded by an operator, or a critical game events such as a shooting, or a position update about a virtual object with respect to a real one. In point of this, scientific literature reports that a packet loss of 5% or more may severely affect the performance of online players [27].
The second requirement has to be interpreted through the considered applications. Delivering control messages and providing VoIP support have different performance requirements/metrics than, for instance, downloading files. The aforementioned network services mostly fall into the realm of real-time applications; it is reasonable to expect that at any moment there will be several people talking and various control message streams going on, whereas file transfers will only happen seldom. We are hence more concerned with the per-packet delay and jitter as these represent performance metrics for real-time applications. More in detail, scientific literature indicates in 100-200 ms the maximum delivery delay for each packet that can be tolerated by online players and VoIP users [28,29].
Jitter is strictly linked to per-packet delay; they are usually present together in a system. Yet, jitter could be even more annoying than delays in the considered context. In fact, even if message delivery delays represent a problem for real-time applications, when these delays are constant, some applications may be built so as to anticipate the delay and correct the effect (e.g., by superimposing the virtual object on the real one while calculating its position few tens or hundreds of ms ahead in time). However, this prediction technique can not be applied in presence of highly variable delays, i.e., a high jitter.
For these reasons, in our experimental evaluation (reported in Section V) we have built a real mesh network in a department-wide area, generating traffic representing the aforementioned AR applications: control messages, VoIP, and background FTP (File Transfer Protocol) flow. In this context, we have mainly (but not only) monitored the packet loss and jitter performance with different network traffic configurations so as to make emerge the behavior of the system when more services and/or more users are simultaneously exploiting the mesh network-based collaborative AR environment.

Real Time Multimedia over WMN: Related Work
Delving into scientific literature, we can find works that relate to our case study such as the preliminary WMN testbed in [30]. However, most works focus on issues such as network capacity, transmission reliability, packet routing, and security [31][32][33]. Although important and inspiring, each of them represents only a part of the scenario we are considering, which involves a real testbed assessment of WMNs to support transmissions (especially real-time ones) in a department-wide AR environment.
In this context, real time applications represent an important source of traffic in the WMN; hence, [34] evaluates the possibility of aggregating packets to ameliorate VoIP performance over a WMN. The hidden terminal problem, the exposed terminal problem, and the binary exponential backoff scheme are indicated by [15] as main causes for transmission delay over multi-hop wireless links, such as in a WMN. The authors hence propose to reserve at least one path having enough bandwidth before starting to transmit real-time multimedia contents so as to reduce this delay. Resource reservation for real-time traffic is what we have been working on earlier; in [35] we present an 802.11-based MAC scheme that allows stations to reserve transmission time before starting to transmit real-time flows. The paper also describes an idea of how the scheme can be extended to be used in multi-hop wireless network.
Analyzing a home WMN scenario, [36] shows that the classic shortest-path selection algorithm with minimum hop counts to search for a gateway can easily lead to load imbalance in the network, thus negatively affecting both the throughput and the per-packet delay of transmitted data flows. Therefore, the authors suggest adopting a wireless home mesh router selection mechanism based on a QoS-driven selection metric that takes into account also the residual capacity on each link. Finally, [37] presents a theoretical study of a G/G/1 queuing model to characterize the average delay and maximum throughput in WMNs, given certain network parameters and assuming intra-mesh communications.
Strongly characterized by a practical aim, our work differs from the preceding ones as it is a real testbed evaluation of networking issues and solutions related to a specific and challenging application instance: collaborative services for AR environments. Yet, some of the aforementioned solutions may be compatible with our tested architecture and contribute in enhancing its performance. We hence do not exclude to test them in our experimental scenario in the future.

IV. DEPLOYING A REAL MESH NETWORK
We intend to analyze with the help of a real testbed how a WMN can support collaborative AR applications. As we have devoted Section II and Section III to discuss typical AR applications and networking issues related to them, it is now important to provide background information about WMNs. First, we overview typical components in WMNs. Then, we describe the software platform we have used to deploy our WMN testbed. Finally, we have performed a preliminary evaluation on a possible QoS solution, whose employment could be extended to provide the required performance degree to collaborative AR applications in a WMN.

WMN Components
A WMN is composed of different kinds of nodes that form a cooperative communication infrastructure. Each node possesses routing capabilities; the network may hence still be operable even if a node or a link breaks down. The nodes composing a WMN can be categorized into:  Mesh Point (MP): Refers to any node in the wireless mesh network; it can be used to relay messages in an ad hoc fashion to any other node in the network.  Mesh Portal Point (MPP): Refers to a node in the network that is an MP, but also provides wired connectivity.  Mesh Access Point (MAP): Refers to a node in the network that is an MP, but unlike an MPP, provides wireless connectivity, instead of wired.  Station (STA): Refers to a user mobile device that is not strictly part of the mesh network; instead an STA can access the resources provided by the mesh only through an MAP. Essentially, we can view a mesh network as a packet switched, multi-hop ad hoc network among MPs.

Microsoft Mesh Connectivity Layer
Microsoft's Mesh Connectivity Layer (MCL) allows the deployment of a WMN using any wireless card [38]. Simply, as a native Windows driver, upon installation the host system can see a virtual network adapter that allows for direct connectivity to the wireless mesh network.
Architecturally, MCL is an interlayer protocol, located between the network and the link layers. Its position allows it to complement surrounding layers in a transparent way, thus minimizing the changes required to existing systems, technologies, and protocols. As its routing protocol, MCL employs an algorithm named Link Quality Source Routing (LQSR), which is a modified version of Dynamic Source Routing (DSR) [39]. Its basic functionalities are as follow: i) it identifies all the MPs in a WMN and assigns relative weights to the links among the nodes; ii) it determines the channel, the bandwidth, and the loss rate for every link and spreads this information to all nodes; iii) the aforementioned information is exploited to compute a routing metric called Weighted Cumulative Expected Transmission Time (WCETT) [40], which defines the best path for the transmission of data from source to destination; iv) if the optimum path between a particular source and destination changes, the route is modified accordingly, without interrupting the link between the nodes. Surprisingly, MCL is provided by Microsoft as open source, allowing anyone to modify its code. For instance, we intentionally tested the system in its simplest configuration, using the aforementioned default routing scheme (LQSR); yet future work may compare the performance achieved when adopting different routing protocols such as Hybrid Wireless Mesh Protocol (HWMP), Ad hoc On demand Distance Vector (AODV), and Radio Aware Optimized Link State Routing (RA-OLSR) [41,42].

Providing QoS to Real-time Applications
As discussed in Section III, collaborative AR environments involve mainly interactive applications such as the transmission of control messages and voice. The nature of these applications calls for solutions able to ensure the satisfaction of their strict real-time requirements.
To this aim, the Wi-Fi Multimedia (WMM) technology, based on IEEE 802.11e, provides IEEE 802.11 networks with QoS support through the standard Enhanced Distributed Channel Access (EDCA) function [43,44]. In essence, network traffic is prioritized at the Media Access Control (MAC) layer into four categories: voice, video, best effort, and background. WMM does not provide guaranteed throughput, yet, for the considered application, providing fast delivery of transmitted messages can be considered of primary importance with respect to the achieved throughput.
Basically, original specifications defined the Type of Service (TOS) field with the ability to specify precedence, delay, throughput, reliability, and cost characteristics [45,46]. Then, [47] defined the value of the Differentiated Services Code Point (DSCP) in the IP header as the high-order 6 bits of the IP version 4 (IPv4) TOS field and the IP version 6 (IPv6) Traffic Class field. During forwarding, DSCP-capable routers read the DSCP value and place the packet into a specific queue.
Since, the WMM specification defines how the WMM access categories map to DSCP values, by configuring DSCP values, we are able to differentiate among traffic services. A WMM-capable device reads the DSCP value and handles the traffic based on its access category. For completeness, we provide in Table I the basic prioritization mapping to the distinct traffic categories.  Fig. 1 provides a bird-eye view of our network topology setup in its most general configuration.
A total of five MPs are part of our WMN; two of them are used as MAP and MPP, respectively (see previous description in Section IV-A). The MPP is connected to an Internet server, whereas a variable number of STAs (clients) are connected to the MAP. The MPs on the mesh backbone are operating on channel 11, while the STAs are communicating with the MAP on channel 1. The rationale behind this choice is that of keeping these two channels far from each other so as to decrease the inter-carrier interference that could affect experimental results and their clarity.
The Mesh backbone is implemented with Dell Latitude D610 Review laptops (Pentium M 760 2.00 GHz, 512 MB RAM) whereas the STAs are Dell laptops with Pentium III CPU and 128 MB of RAM. All nodes utilize ZyXEL AG-225H as Network Interface Card. We used the well-known ping application to determine the transmission range of each MP in the WMN, and then carefully positioned them so that non-neighboring MPs could not communicate with each other. This way, data packets were prevented from using shortcuts among MPs as these would have affected the accuracy and the clarity of collected results by unpredictably decreasing the actual number of hops with respect to our experimental intentions.
For the sake of realism, in our tests, we have run different applications related to a collaborative AR environment that are supported by the networking services listed in Section 3.2 (i.e., file transmission, control messages, VoIP communication, and video streaming). More in detail, the characteristics of those network services are summarized in Table II and explained in the remaining of this section.
File transmission is generally performed through FTP with the support of the Transmission Control Protocol (TCP). This transport protocol is well known for its reliability and congestion control mechanisms. In essence, TCP starts with a low downloading rate, then continuously increase it in the attempt of consuming all the bandwidth that is available on the channel (also considering what is consumed by other simultaneous flows). Therefore, we can say that FTP/TCP based flows consume all bandwidth left available by other (UDP-based flows). However, as emerges from the description of the collaborative applications in Section III, it is legitimate to expect that users in an AR scenario will only seldom download a file; whereas, they will continuously utilize other UDP-based services such as control messages and VoIP. The transmission of control messages is the hardest part to model in our tests because of its variability. Control messages may carry various kinds of contents, from few bytes to much richer information. Furthermore, the amount of control messages directly depends on the number of users; when many users are simultaneously present in the AR environment, their presence, movements, actions, and applications generate many little updates, which together require a significant amount of bandwidth. For instance, if we consider 40 users, each of which automatically generating and transmitting just 50 bytes of information (e.g., identification, position, status of applications run, checksum, etc.) every 50 ms, we would have 320 kbps generated and transmitted every s. Given the size of our WMN, we deemed that this could represent a realistically, yet challenging, configuration for our considered scenario.
Focusing on VoIP communications, in our tests, we have generated a number of streams that is coherent with the mentioned number of 40. Not all users will be simultaneously communicating; we assumed that 10 simultaneous VoIP streams realistically represent an intense use of the AR environment. For the sake of realism, we have generated each voice stream according to the G.711 voice codec [48]. Each generated voice packet carries 2 samples of 80 bytes (i.e., the payload size is 160 B) every 20 ms, thus resulting in 64 kbps per each VoIP stream.
Finally, for the sake of completeness, in some experiments we have also added a video stream. In those cases, the video was an MPG with a bit rate varying from 218 to 456 kbps. This values realistically represents the video that would be generated in a video-chat by a regular webcam [49].
Technically speaking, the VoIP traffic was generated using the Distributed Internet Traffic Generator (D-ITG) [50], while we used VLC media player for video streaming using RTP, and FileZilla [51] for file transfer using FTP. Even if we consider both elastic and real-time applications, we keep the focal point on the performance achieved by real-time ones, as they represent the main service for the considered scenario as depicted in Section III. D-ITG calculates jitter as the average of delay differences between consecutive packets (S i is the sending time and R i is the receiving time of packet i, and n is the total number of packets): In the following subsections we report on the experimental outcomes of the presented WMN testbed. We divide charts into three main subsections. The first subsection regards a scenario with competing elastic and real-time flows; the second one considers different real-time applications sharing the WMN; the third subsection is focused on QoS enforcement.

Elastic Flows vs. Real-time Flows
As our first experiment, we run a single elastic application (i.e., an FTP/TCP download session) over our WMN, varying the number of hops that packets have to traverse from the source (FTP server) to the destination (FTP client). Just to provide a couple of examples, in the considered AR scenario, this data flow could represent a digital note that has to be superimposed on a real object, or a reparation manual for a certain component.
The client was positioned as depicted in Fig. 1 and engaged with the MAP, whereas the position of the server is varied: on MAP to have the 1 hop evaluation, on MP1 to have the 2 hops evaluation, on MP2 to have the 3 hops evaluation, etc. This experiment is aimed at both evaluating the performance of a single elastic flow in a WMN and at verifying the reliability of the outcomes produced by our testbed. Indeed, it is well known in scientific literature that the available data rate for TCP-based decreases for each wireless hop until becoming unable to support any application after a certain "ad hoc horizon" [52][53][54]. This is clearly confirmed by collected results reported in Fig. 2. Considering our collaborative AR environment, the chart shows that users at the edge of the WMN will be clearly disadvantaged.   Then, we consider a scenario with several users simultaneously voice chatting with each other and study the impact of changing the number of hops traversed by the VoIP streams; the configuration also includes one ongoing FTP session run in the background. Again, the FTP session may be used to download the latest version of a digital note superimposed on a certain object. The fact that no control messages is exchanged among users can be interpreted as considering a system where virtual objects are locally saved in the memory of the portable AR visualization tools (i.e., AR helmets); only sporadically, some user will need to download some updated virtual objects (as said, through FTP).
In the experiments, the FTP flow always traverses 2 hops, whereas 10 simultaneous VoIP streams traverse from 2 to 5 hops. Clearly, the more hops the VoIP streams traverse, the more is the impact on their performance. This is confirmed by Fig. 3 and Fig. 4, which show the average jitter and the packet loss experienced in average by the 10 VoIP streams when varying the number of hops. In particular, the performance of the VoIP streams follows an exponential trend when the number of hops grows linearly. This has a devastating effect on the perceived quality of the VoIP application. Participants' voices will result severely scattered, allowing no conversation over the WMN supporting the collaborative AR environment if the distance between the participants is more than 4 hops.
We consider the case where the background traffic is either represented by an elastic flow or by a video stream. In both cases, the traffic is traversing 2 hops between the FTP/video streaming server (connected to MPP) and MP2. Simultaneously, from 1 to 10 VoIP streams traverse all 5 hops of the WMN. The average jitter and packet loss for the VoIP streams are reported in Fig. 5 and Fig. 6, respectively. As expected, both metrics worsen when increasing the number of simultaneous VoIP sessions as they interfere with each other (and with the background traffic).
As the charts show, when the background traffic is represented by the FTP flow, the jitter grows linearly with the number of simultaneous VoIP streams, whereas the packet loss is negligible from 1 to 4 simultaneous VoIP streams and then grows very quickly. At that point however, even the jitter starts to be too high to ensure good performances. Instead, with the video stream set as background traffic, a negligible packet loss is ensured only up to 3 simultaneous VoIP streams. We can hence say that in the tested configuration, with also some FTP or video background, only up to 3-4 simultaneous VoIP streams can be effectively supported. Clearly, when considering the mentioned collaborative AR applications, this represents a serious issue as it significantly limits the number of simultaneous users (e.g., the size of a rescue team utilizing AR applications).

Real-time Flows vs. Real-time Flows
Since real-time applications represent the main source of traffic in the considered WMN scenario, it is important to evaluate how they would affect each other if running simultaneously. To this aim, we analyze how the performance of a VoIP session is affected by other generic UDP-based streams, i.e., how the quality of an ongoing conversation would be affected by control messages automatically sent to synchronize the alignment between digital objects and the real world.
Results for this analysis are reported in Fig. 7 and Fig. 8, showing the average jitter and packet loss of a VoIP stream traversing the whole WMN while the background UDP-based traffic (carrying control messages for the AR appearance) is progressively augmented. The charts demonstrate a sudden performance worsening when the amount of traffic caused by control messages is increased from 640 kbps to 960 kbps. Indeed, even if both the considered applications are not particularly bandwidth-consuming, yet, they continuously send out packets, thus keeping the wireless channel busy. When these transmissions involve multiple hops, they consume their portion of the channel on each of the involved hops, multiplying their congestion and interference effects until causing the sudden deterioration of performances seen in the charts.
Focusing again on the user's point of view, this means that in case of intensive message exchange due to synchronization among terminals or virtual object alignment, VoIP communications will not be feasible (and viceversa). It becomes hence fundamental do discriminate among the various data flows, and to provide adequate performance to the most relevant among them. For instance, when deploying the WMN to support the collaborative AR environment, the designer should decide whether to privilege VoIP streams over alignment-control messages or viceversa. Probably, this decision will be based on cognitive analysis on the impact of providing certain QoS levels to final application users, rather than by networking or computer science studies. Our responsibility as computer scientists is that of providing instruments to be able to enforce this discrimination, once decided its rules. We devote the next subsection to suggest and evaluate a possible solution for this task.

Providing QoS Discrimination among Real-time Flows
As demonstrated in Section 5.1 and Section 5.2, intense network traffic conditions makes impossible to adequately support all simultaneous flows (i.e., VoIP services, synchronization, virtual and physical objects alignment, file download, etc.). In these situations, real-time flows should be privileged as the functioning of the collaborative AR world is mostly based on prompt responsivity (see previous discussion in Section III).
Among the various real-time services that could be simultaneously present, we assume that an intrinsically interactive application such as VoIP has a greater impact on the global performance of the AR system perceived by the user than control messages for the alignment of the synthetic objects over the real world. However, our outcomes would be valid even if cognitive studies proved that we were wrong and that the quick delivery of alignment messages is more important than the quick delivery of VoIP messages. Once the QoS requirements and priorities for each kind of service are decided, our purpose is to factually enforce the chosen policy and provide an adequate performance level to the most important application(s).
As explained in Section 4.3, this can be achieved through exploiting standard IEEE 802.11e EDCA function. To this aim, we have run some preliminary experiments showing the effectiveness of EDCA in prioritizing data flows on a single link. The outcomes are reported in Fig. 9 and Fig. 10, showing the average jitter of a VoIP stream among a node pair, when a variable number (from 1 to 5) of concurrent UDP streams share the same link. Moreover, we also vary the data rate of each of these concurrent UDP streams for a certain testbed configuration from 0 Mbps to 8 Mbps (0 Mbps, 2 Mbps … 8 Mbps in the charts). Fig. 9 presents the average jitter of the VoIP stream when no EDCA priority is exploited, whereas Fig. 10 shows the same outcome when a high priority is assigned to the VoIP packets. As it is evident, with no prioritization (Fig. 9) the average jitter experienced by the VoIP stream grows very quickly as soon as we introduce some background traffic. Instead, Fig. 10 demonstrates that when EDCA is employed, even with 5 concurrent UDP streams of 8 Mbps each, the average jitter experienced by the high priority VoIP stream remains very little.

VI. CONCLUSION
AR technology represents a great complement for many applications. In this context, networking emerges as crucial, even if currently overlooked, when considering AR for collaborative applications. We have proposed to employ WMN technology to quickly deploy and support AR-based collaborative applications in department-wide environments. We have discussed the importance of providing fast packet delivery in this context and showed how performances quickly degrade as soon as the AR environment gets populated by participants. To overcome this problem we have also evaluated the possibility to employ a QoS solution provided by the WMN technology, proving the feasibility of this approach. As future works, we are planning to test a specific AR application (e.g., AR games) in our testbed and to apply formal methods to evaluate system performance [55].