Thomas Forgione
email: thomas.forgione@irit.fr

Axel Carlier
email: axel.carlier@enseeiht.fr

Géraldine Morin
email: morin@enseeiht.fr

Wei Tsang Ooi

Vincent Charvillat

Praveen Kumar
email: praveen@comp.nus.edu.sg

DASH for 3D Networked Virtual Environment

DASH is now a widely deployed standard for streaming video con-tent due to its simplicity, scalability, and ease of deployment. In this paper, we explore the use of DASH for a different type of media content -networked virtual environment (NVE), with different properties and requirements. We organize a polygon soup with textures into a structure that is compatible with DASH MPD (Media Presentation Description), with a minimal set of view-independent metadata for the client to make intelligent decisions about what data to download at which resolution. We also present a DASH-based NVE client that uses a viewdependent and network dependent utility metric to decide what to download, based only on the infor-mation in the MPD file. We show that DASH can be used on NVE for 3D content streaming. Our work opens up the possibility of using DASH for highly interactive applications, beyond its current use in video streaming.

INTRODUCTION

With the standardization of Extensible 3D (X3D) format from the Web3D Consortium and supports for WebGL in modern browsers, we can now remotely visualize and interact with complex 3D networked virtual environments (NVEs), such as 3D models of cities, buildings, and archaeological sites, with applications ranging from urban planning to tourism. These 3D scenes consist of the geometry data (typically represented as 3D meshes) and textures (represented as images), that can be up to order of hundreds of megabytes or gigabytes in size. There have been a series of research work on how to stream large-scale 3D models over the network for display and interaction with the viewers (e.g., [START_REF] Forgione | Impact of 3D Bookmarks on Navigation and Streaming in a Networked Virtual Environment[END_REF][START_REF] Hu | FLoD: A framework for peer-to-peer 3D streaming[END_REF][START_REF] Hu | WebTorrent based ne-grained P2P transmission of large-scale WebVR indoor scenes[END_REF]). Yet there is currently no widely adopted standard for a 3D streaming protocol, particularly, one that supports adaptation to dynamic network conditions. We believe this lack of widely accepted standard protocol is hindering a broader deployment of Web-based NVEs.

On the other hand, Dynamic Adaptive Streaming over HTTP (DASH), or MPEG-DASH [START_REF] Sodagar | The MPEG-DASH Standard for Multimedia Streaming Over the Internet[END_REF][START_REF] Stockhammer | Dynamic Adaptive Streaming over HTTP -: Standards and Design Principles[END_REF], is now a widely deployed standard for streaming adaptive video content on the Web [START_REF]Information technology -Dynamic adaptive streaming over HTTP (DASH) -Part 1: Media presentation description and segment formats[END_REF]. DASH is simple and scalable. It uses the existing World Wide Web infrastructure and protocols. Hence it is easy to deploy in any network that supports HTTP. DASH works with a standard HTTP server and HTTP caching proxies without modi cation. It supports multiple representations of the same video content at di erent bitrates and lets the clients choose and adapt the quality in response to changing network conditions. As the main adaptation logic lies on the client, the server is stateless and simply acts as a server that responds to HTTP requests. As the Web has demonstrated, such stateless HTTP server can scale to a massive number of users.

Due to the strengths of DASH and a need for a protocol with similar properties for streaming 3D scene, a natural question that arises is whether DASH can be used for adaptive streaming of 3D content for NVE. DASH, however, is designed for video streaming, and adapting it for NVE is non-trivial. Unlike video, where viewing progresses linearly (unless the user seeks), an NVE user can freely navigate within the 3D scene. A typical NVE client would need to determine, and possibly predict, what are the geometry data and textures that fall into the viewing frustum (region de ned by its camera position, viewing angle, and look-at point). This should be done purely in the client with only precomputed, view-independent metadata from the server. Thus, the rst challenge we face is what are the view-independent metadata that the server needs to provide along with 3D data to allow the client to make an intelligent viewdependent decision on what to download? Clearly, the more metadata the server provides along with the 3D data (for DASH, in a Media Presentation Description (MPD) le), the better the decision that the client can make, at the expense of increasing the size of the MPD le. Better decision leads to a more e cient use of the bandwidth, with the aim of being able to download all the visible 3D data content, at the most appropriate resolution, without fetching data that is outside the eld of view or is occluded.

For NVE, the content to stream consists of geometry data (vertices, faces, texture coordinates) and texture images. These data are often provided as a polygon soup without semantic information or a scene graph. The textures can be of di erent resolution levels. The area of the faces can vary signi cantly as well, implying that Figure 1: A subdivided 3D scene with a viewport, with regions delimited with red edges. In white, the regions that are outside the eld of view of the camera; in blue, the regions inside the eld of view of the camera the decision as to which triangle to download can have a signi cant impact on the viewing quality. As such, the second challenge we face is how to organize the soup of 3D data into DASH adaptation sets, representation, and segments to facilitate decision making to the DASH client, without semantic information.

In DASH video streaming, the bitrate of the segment correlates with the quality of the video. A DASH client can maximize the average bitrate (and hence the size) of the segments downloaded to improve the quality of experience. In NVE streaming, the quality of experience is determined by the rendered scene in the image space (view dependent), whereas the size of the textures determines only its quality in 3D space (view independent). A texture can be mapped onto multiple faces and appear in di erent regions of the 3D scene. The relative impact of geometry data and textures on the rendering quality also needs to be quanti ed. Hence, the third challenge we face is what metadata to provide to support client's rate adaptation decisions, particularly the decisions of what to download (geometry data or textures?), and at which resolution?

Contributions. Our contributions for this paper are three-fold. First, we propose an organization of a polygon soup into a DASHcompliant format that facilitates selective and adaptive downloading of 3D content by the client. We do not assume the availability of semantic information nor structured scene graphs. Motivated by the need to view a smaller subset of a large 3D scene most of the time during navigation, we partition the 3D space into spatially coherent cells using an axis-aligned K-d tree. Faces that fall into a cell are assigned to a single DASH adaptation set. Each cell contains approximately the same number of faces (up to N a faces). Within each adaptation set, the faces are grouped into N s segments. To manage the heterogeneity of the faces surface size, we treat faces that are especially large (e.g., the ground or the sky) separately, grouping them into a special adaptation set, allowing the client to download these segments quickly.

The materials are declared in a single le that gives photometric properties and textures of the geometry. This le is described in its own adaptation set, in a single segment. The textures are placed into separate adaptation sets, with di erent representations for di erent texture resolutions. Separating the geometry and textures into di erent adaptation sets allows the DASH client to trade o between the importance of the geometry and textures accordingly. The latter is not possible using the scheme proposed previously in [START_REF] Zampoglou | Adaptive streaming of complex Web 3D scenes based on the MPEG-DASH standard[END_REF]. Note that in this work, we do not implement multiresolution geometry (for reasons we will explain in Section 3.3), even though our content preparation would allow it.

Second, we propose precomputation of a small set of metadata that are helpful to the client in making rate adaptation and download decisions. In particular, for each adaptation set of geometry data, we include its bounding box; for adaptation set of texture, we include its average color. For each segment of geometry data, we include (i) the total area of the faces in 3D space; and (ii) the size in bytes of the segment. For each segment of texture data, we include (i) the mean square error of the image, relative to the highest resolution of the texture, and (ii) the size in bytes of the segment. We show that this minimal set of view-independent information is su cient for complex decision making at the client.

Finally, we present a DASH-based NVE client that is adaptive to network RTT, bandwidth, and navigational pattern. Using only the metadata in the MPD le, the client selectively downloads adaptation sets that intersect with its viewing frustum and prioritizes segments that are likely to contribute more to the viewing quality. We also propose a utility metric that integrates the contribution of geometry data and textures in the image space. This utility metric is, independently, a useful metric that could be useful for other applications that require a comparable objective metric to measure the contribution of geometry data vs. texture data in a 3D scene.

Note that while our proposal is DASH-compliant, the contribution is not limited to DASH. It allows a stateless server to provide only view-independent information and to organize a polygon soup that is friendly to adaptation and selection by the client o ine, in a way that any client can derive on his own an e cient, viewdependent, adaptive to network conditions streaming strategy.

Paper Organization. The rest of this paper is structured as follows: Section 2 reviews the related work, and Section 3 describes our proposal for adapting DASH for 3D content. In Section 4 we detail the proposed DASH 3D client. Then, Section 5 presents the experiments and results highlighting the impact of di erent design parameters for DASH. Finally, we conclude in Section 6.

RELATED WORK 2.1 Streaming 3D Content

Accessing and interacting with 3D content over the web have been explored in previous work. Behr et al. structure the 3D content to allow access from a web browser [START_REF] Behr | A scalable architecture for the HTML5/X3D integration model X3DOM[END_REF]. In a recent standardization e ort, the Khronos group has proposed a generic format called glTF [START_REF] Robinet | glTF -Runtime asset format for WebGL, OpenGL ES, and OpenGL[END_REF] to handle all types of 3D content representations: point clouds, meshes, animated model, etc. Although relevant for compression, transmission and in particular streaming, this standard does not yet consider view-dependent streaming. of freedom in interacting with the video, including panning (e.g., 360-degree videos) and zooming (e.g., zoomable video [START_REF] Quang | Supporting Zoomable Video Streams with Dynamic Region-of-interest Cropping[END_REF]). These schemes partition each video frame into tiles which can be decoded independently by the client. In this context, Niamut et al. proposed a modi ed version of traditional Media Presentation Description (MPD) les using Spatial Representation Description (SRD) [START_REF] Niamut | MPEG DASH SRD: Spatial Relationship Description[END_REF]. Such partial content retrieval and rendering help in zooming and navigating through the content [START_REF] Acunto | Using MPEG DASH SRD for zoomable and navigable video[END_REF].

DASH for NVE shares many similarity with SRD-DASH: a user may view only a subset of the content. SRD-DASH puts each tile into a di erent adaptation set, and the client can only request for the adaptation sets (the tiles) that fall within the current view. Similarly, in our proposal, we partition 3D geometry and textures into cells ("3D tiles") and each cell forms an adaptation set. Unlike SRD-DASH for video however, it is not straightforward to assign a 3D face to a cell, since a large face (e.g., the sky or the ground) may intersect with multiple cells.

MAPPING NVE INTO DASH

In this section, we describe how we preprocess and store the 3D data of the NVE, consisting of a polygon soup, textures, and material information into a DASH-compliant Media Presentation Description (MPD) le. In our work, we use the obj le format for the polygons, png for textures, and mtl format for material information. The process, however, applies to other formats as well.

The MPD File

In DASH, the information about content storage and characteristics, such as location, resolution, or size, are extracted from an MPD le by the client. The client relies only on these information to decide which chunk to request and at which quality level.

The MPD le is an XML le that is organized into di erent sections hierarchically. The period element is a top-level element, which for the case of video, indicates the start time and length of a video chapter. This element does not apply to NVE, and we use a single period for the whole scene, as the scene is static.

Each period element contains one or more adaptation sets, which describe the alternate versions, formats, and types of media. We utilize adaptation sets to organize a 3D scene's material, geometry, and texture.

Adaptation Sets

When the user navigates freely within an NVE, the frustum at given time almost always contains a limited part of the 3D scene. Similar to how DASH for video streaming partitions a video clip into temporal chunks, we segment the polygons into spatial chunks, such that the DASH client can request only the relevant chunks.

Geometry Management. We use a space partitioning tree to organize the faces into cells. A face belongs to a cell if its barycenter falls inside the corresponding bounding box. Each cell corresponds to an adaptation set. Thus, geometry information is spread on adaptation sets based on spatial coherence, allowing the client to download the relevant faces selectively. A cell is relevant if it intersects the frustum of the client's current viewpoint. Figure 1 shows the relevant cells in blue. As our 3D content, a virtual environment, Some work also focus on compression algorithms; Potenziani et al. describe a system that progressively streams 3D content in the context of cultural heritage [START_REF] Potenziani | 3DHOP: 3D heritage online presenter[END_REF]. Google Draco [START_REF]Draco[END_REF] is an opensource e ort to provide an e cient compression and decompression system that can e ciently run on web browsers. Their work is applied to an attributed geometry modeling a single object, but the compression techniques are not suitable for a partitioned large Networked Virtual Environments (NVE).

The work by Limper et al. on Shape Resource Container [START_REF] Limper | SRC -a Streamable Format for Generalized Web-based 3D Data Transmission[END_REF] focuses more on the streaming aspect, aiming at rendering the model progressively and adapting the content to t GPU structures to improve the rendering, but independently of the viewport.

The above does not consider view-dependent 3D streaming. View-dependent 3D streaming has been investigated in the work of Forgione et al. [START_REF] Forgione | Impact of 3D Bookmarks on Navigation and Streaming in a Networked Virtual Environment[END_REF], where the authors use frustum and backface culling on the server to determine a set of polygons to be streamed by the client. Bookmarks provide a way to ease user navigation and improve streaming e ciency. The drawback of this method is that it does not scale well with the number of users due to the computation load on the server. Cheng and Ooi [START_REF] Cheng | Receiver-driven View-dependent Streaming of Progressive Mesh[END_REF] proposed a view-dependent progressive mesh streaming system that is receiver-driven. Their technique leads to a stateless server and is scalable. Their work, however, focuses on a single progressive mesh structure and uses a customized application-level protocol.

Balancing between streaming of geometry and texture data are considered by Tian et al. [START_REF] Tian | Batex3: Bit allocation for progressive transmission of textured 3-d models[END_REF], Guo et al. [START_REF] Guo | Subjective and objective visual quality assessment of textured 3D meshes[END_REF], and Yang et. al. [START_REF] Yang | Optimized Mesh and Texture Multiplexing for Progressive Textured Model Transmission[END_REF]. All three work considered a single, manifold textured mesh model with progressive meshes. Their approach is to combine the distortion caused by having lower resolution meshes and textures into a single view independent metric. Our work focuses on a whole, heterogeneous 3D scene where separate object coding is not applicable, thus their proposed metric is not a good t.

Zampoglou et al. are the rst to propose DASH to stream 3D content [START_REF] Zampoglou | Adaptive streaming of complex Web 3D scenes based on the MPEG-DASH standard[END_REF]. In their work, the authors describe a system that allows users to access 3D content at multiple resolutions. They organize the content, following DASH terminology, into periods, adaptation sets, representations. Their rst a daptation s et c odes the tree structure of an X3DOM. Each further adaptation set contains both geometry and texture information and is available at di erent resolutions de ned in a corresponding representation. To avoid requests that would take too long and thus introduce latency, the representations are split into segments. The authors discuss the optimal number of polygons that should be stored in a single segment. On the one hand, using segments containing very few faces will induce many HTTP requests from the client, and will lead to poor streaming e ciency. On the other hand, if segments contain too many faces, the time to load the segment will be long and the system loses adaptability. The authors conclude that using segments of 5000 faces is a good compromise. This approach works well for several objects, but does not handle view-dependent streaming, which is desirable in the use case of large NVEs.

SRD-DASH

While typical DASH for video is designed for video playback with a single dimension of freedom along the time axis, there are recent work that have extended video playback to allow higher dimension

Segments

To allow random access to the content within an adaptation set storing geometry data, we group the faces into segments. Each segment is then stored as a .obj le that can be individually requested by the client. For geometry, we partition the faces in an adaptation set into sets of N s faces, by rst sorting the faces by their area in 3D space in descending order, and then place each successive N s faces into a segment. Thus, the rst segment contains the biggest faces and the last one the smallest. In addition to the selected faces, a segment stores all face vertices and attributes so that each segment is independent. For textures, each representation contains a single segment.

DASH 3D CLIENT

In this section, we specify a DASH NVE client that exploits the preparation of the 3D content in an NVE for streaming. is biased to spread the most along the horizontal plane, we alternate between splitting between the two horizontal directions.

We create a separate adaptation set for large faces (e.g., the sky or ground) because they are essential to the 3D model and do not t into cells. We consider a face to be large if its area in 3D is more than a + 3σ , where a and σ are the average and the standard deviation of 3D area of faces respectively. In our example, it selects the 5 largest faces that represent 15% of the total face area. We thus obtain a decomposition of the NVE into adaptation sets that partitions the geometry of the scene into a small adaptation set containing the larger faces of the model, and smaller adaptation sets containing the remaining faces.

We store the spatial location of each adaptation set, characterized by the coordinates of its bounding box, in the MPD le as the supplementary property of the adaptation set in the form of "x min , width, min , height, z min , depth" (as shown in Listing 1). This information is used by the client to implement a view-dependent streaming (Section 4).

Texture Management. As with geometry data, we handle textures using adaptation sets but separate from geometry. Each texture le is contained in a di erent adaptation set, with multiple representations providing di erent image resolutions (see Section 3.3). We add an attribute to each adaptation set that contains texture, describing the average color of the texture. The client can use this attribute to render a face for which the corresponding texture has not been loaded yet, so that most objects appear, at least, with a uniform natural color (see Figure 2).

Material Management. The material .mtl le is a text le that describes all materials used in the .obj les for the entire 3D model. A material has a name, properties such as specular parameters, and, most importantly, a path to a texture le. The .mtl le maps each face of the .obj to a material. As the .mtl le is a di erent type of media than geometry and texture, we de ne a particular adaptation set for this le, with a single representation.

Representations

Each adaptation set can contain one or more representations of the geometry or texture data, at di erent levels of detail (e.g., a di erent number of faces). For geometry, the resolution (i.e., 3D areas of faces) is heterogeneous, thus applying a sensible multiresolution representation is cumbersome: the 3D area of faces varies from 0.01 to more than 10K, disregarding the outliers. For textured scenes, it is common to have such heterogeneous geometry size since information can be stored either in geometry or texture. Thus, handling the streaming compromise between geometry and texture is more adaptive than handling separately multi-resolution geometry. Moreover, as our faces are partitioned into independent cells, multi-resolution would cause di cult stitching issues such as topological gaps between the cells.

For an adaptation set containing texture, each representation contains a single segment where the image le i s s tored a t the chosen resolution. In our example, from the full-size image, we generate successive resolutions by dividing both height and width by 2, stopping when the image size is less or equal to 64 × 64. Figure 2 illustrates the use of the textures against the rendering using a single, average color per face.

we account for the area in 3D of all these triangles. We could consider such an o ine measure (attached to the adaptation set containing the texture), but we prefer to only account for the triangles that have been already downloaded by the client. We call the set of triangles colored by a texture T : ∆(s T ) = ∆(T ) (depending only on T and equal for any representation/segment s T in this texture adaptation set). At each time t i , a subset of ∆(T ) has been downloaded; we denote it ∆(T , t i ).

Moreover, each geometry segment belongs to a geometry adaptation set AS G whose bounding box coordinates are stored in the MPD. Given the coordinates of the bounding box BB(AS G ) and the viewpoint (t i ) at time t i , the client computes the distance D( (t i ), AS G ) of the bounding box BB(AS G ) as the distance from the center of BB(AS G ) to the principal point of the camera, given in (t i ).

Utility for geometry segments. We now have all parameters to derive a utility measure of a geometry segment. Utility for texture segments will follow from the geometric utility.

The utility of a geometric segment s G for a viewpoint (t i ) is:

U s G , (t i ) = A 3D (s G ) D( (t i ), AS G ) 2
where AS G is the adaptation set containing s G .

Basically, the utility of a segment is proportional to the area that its faces cover, and inversely proportional to the square of the distance between the camera and the center of the bounding box of the adaptation set containing the segment. That way, we favor segments with big faces that are close to the camera.

Utility for texture segments. For a texture T stored in a segment s T , the triangles in ∆(T ) are stored in arbitrary geometry segments, that is, they do not have spatial coherence. Thus, for each k th downloaded geometry segment s G k , and total downloaded segment K at time t i , we collect the triangles of ∆(T , t i ) in s G k , and compute the ratio of A 3D (s G k ) covered by these triangles. So, we de ne the utility:

U s T , (t i ) = psnr (s T ) k ∈K A 3D (s G k ∩ ∆(T , t i )) A 3D (s G k ) U s G k , (t i )
where we sum over all geometry segments received before time t i that intersect ∆(T , t i ) and such that the adaptation set it belongs to is in the frustum. This formula de nes the utility of a texture segment by computing the linear combination of the utility of the geometry segments that use this texture, weighted by the proportion of area covered by the texture in the segment. We compute the PSNR by using the MSE in the MPD and denote it psnr (s T ). We do this to acknowledge the fact that a texture at a greater resolution will have a higher utility than a lower resolution texture. The equivalent term for geometry is 1 (and does not appear).

Having de ned a utility on both geometry and texture segments, the client uses it next for its streaming strategy.

DASH Adaptation Logic

Along the camera path C = { (t i )}, viewpoints are indexed by a continuous time interval t i ∈ [t 1 , t end ]. Contrastingly, the DASH adaptation logic proceeds sequentially along a discrete time line.

The generated MPD le describes the content organization so that the client gets all the necessary information to make educated decisions and query the 3D content it needs according to the available resources and current viewpoint. A camera path generated by a particular user is a set of viewpoint (t i ) indexed by a continuous time interval

t i ∈ [t 1 , t end ].
The DASH client rst downloads the MPD le to get the material (.mtl) le containing information about all the geometry and textures available for the entire 3D model. At time instance t i , the DASH client decides to download the appropriate segments containing the geometry and the texture to generate the viewpoint (t i+1 ) for the time instance t i+1 . Starting from t 1 , the camera continuously follows a camera path

C = { (t i ), t i ∈ [t 1 , t end ]}
, along which downloading opportunities are strategically exploited to sequentially query the most useful segments.

Segment Utility

Unlike video streaming, where the bitrate of each segment correlates with the quality of the video received, for 3D content, the size (in bytes) of the content does not necessarily correlate well to its contribution to visual quality. A large polygon with huge visual impact takes the same number of bytes as a tiny polygon. Further, the visual impact is view dependent -a large object that is far away or out of view does not contribute to the visual quality as much as a smaller object that is closer to the user. As such, it is important for a DASH-based NVE client to estimate the usefulness of a given segment to download, so that it can make good decisions about what to download. We call this usefulness the utility of the segment. The utility is a function of a segment, either geometry or texture, and the current viewpoint (camera location, view angle, and look-at point), and is therefore dynamically computed online by the client from parameters in the MPD le.

O line parameters. Let us detail rst, all parameters available from the o ine/static preparation of the 3D NVE. These parameters are stored in the MPD le. First, for each geometry segment s G there is a predetermined 3D area A 3D (s G ), equal to the sum of all triangle areas in this segment (in 3D); it is computed as the segments are created. Note that the texture segments will have similar information, but computed at navigation time t i . The second information stored in the MPD for all segments, geometry, and texture, is the size of the segment (in kB). Indeed, geometry segments have close to a similar number of faces; their size is almost uniform. For texture segments, the size is usually much smaller than the geometry segments but also varies a lot, as between two successive resolutions the number of pixels is divided by 4.

Finally, for each texture segment s T , the MPD stores the MSE (mean square error) of the image and resolution, relative to the highest resolution (by default, triangles are lled with its average color). O ine parameters are stored in the MPD as shown in Listing 1.

Online parameters. In addition to the o ine parameters stored in the MPD le for each segment, view-dependent parameters are computed at navigation time. First, a measure of 3D area is computed for texture segments. As a texture maps on a set of triangles, i ditions. Algorithm 1 details how our DASH client makes decisions.

input : Current index i, time t i , viewpoint (t i ), bu er of already downloaded segments B i , MPD output : Next segment s * i to request, updated bu er B i+1 -Estimate the bandwidth BW i and RTT τ i ; -Among all segments that are not already downloaded s ∈ S\B i , keep the ones inside the upcoming viewing frustums F C = FC( (t i )), t ∈ [t i , t i + χ ] thanks to a viewpoint predictor t i → ˆ (t i ), a temporal horizon χ and a frustum culling operator FC ; -Optimize a criterion Ω based on U values and well chosen viewpoint(s) (t i ) to select the next segment to query

s * i = argmax s ∈S\B i ∩F C Ω θ i U(s, (t i )
given parameters θ i that gathers both online parameters (i, t i , (t i ), BW i , τ i , B i ) and o ine metadata; -Update the bu er B i+1 for the next decision: s * i and lowest representations of s * i are considered downloaded; return segment s * i , bu er B i+1 ; Algorithm 1: Algorithm to identify the next segment to query

The most naive way to sequentially optimize the U is to limit the decision-making to the current viewpoint (t i ). In that case, the best segment s to request would be the one maximizing U(s, (t i )) to simply make a better rendering from the current viewpoint (t i ). Due to transmission delay however, this segment will be only delivered at time t i+1 = t i+1 (s) depending on the segment size and network conditions:

t i+1 (s) = t i + size(s) BW i + τ i
In consequence, the most useful segment from (t i ) at decision time t i might be less useful at delivery time from (t i+1 ).

A better solution is to download a segment that is expected to be the most useful in the future. With a temporal horizon χ , we can optimize the cumulated U over [t i+1 (s), t i + χ ] :

s * i = argmax s ∈S\B i ∩F C ∫ t i +χ t i +1 (s) U(s, ˆ (t i ))dt (1)
In our experiments, we typically use χ = 2s and estimate the (1) integral by a Riemann sum where the [t i+1 (s), t i + χ ] interval is divided in 4 subintervals of equal size. For each subinterval extremity, an order 1 predictor ˆ (t i ) linearly estimates the viewpoint based on (t i ) and speed estimation (discrete derivative at t i ). We also tested an alternative greedy heuristic selecting the segment that optimizes an utility variation during downloading (between t i and t i+1 ): ty

Files

s GREEDY i = argmax s ∈S\B i ∩F C U s, ˆ (t i+1 (s)) t i+1 (s) -t i (2)

EVALUATION

We now describe our setup and the data we use in our experiments.

We present an evaluation of our system and a comparison of the impact of the design choices we introduced in the previous sections.

Experimental Setup

Model. We use a city model of the Marina Bay area in Singapore in our experiments. The model came in 3DS Max format and has been converted into Wavefront OBJ format before the processing described in Section 3. The converted model has 387,551 vertices and 552,118 faces. Table 1 gives some general information about the model. We partition the geometry into a k-d tree until the leafs have less than 10000 faces, which gives us 64 adaptation sets, plus one containing the large faces.

User Navigations. To evaluate our system, we collected realistic user navigation traces that we can replay in our experiments. We presented six users with a web interface, on which the model was loaded progressively as the user could interact with it. The available interactions were inspired by traditional rst-person interactions in video games, i.e., W, A, S, and D keys to translate the camera, and mouse to rotate the camera. We asked users to browse and explore the scene until they felt they had visited all important regions. We then asked them to produce camera navigation paths that would best present the 3D scene to a user that would discover it. To record a path, the users rst place their camera to their preferred starting point, then click on a button to start recording. Every 100ms, the position, viewing angle of the camera and look-at point are saved into an array that will then be exported into JSON format. The recorded camera trace allows us to replay each camera path to perform our simulations and evaluate our system. We collected 13 camera paths this way.

Network Setup. We tested our implementation under three network bandwidth of 2.5 Mbps, 5 Mbps, and 10 Mbps with an RTT of 38 ms, following the settings from DASH-IF [START_REF]Guidelines for implementation: DASH-AVC/264 test cases and vectors[END_REF]. The values are kept constant during the entire client session to analyze the di erence in magnitude of performance by increasing the bandwidth.

In our experiments, we set up a virtual camera that moves along a navigation path, and our access engine downloads segments in real time according to Algorithm 1. We log in a JSON le the time when a segment is requested and when it is received. By doing so, we avoid wasting time and resources to evaluate our system while downloading segments and store all the information necessary to plot the gures introduced in the subsequent sections.

Hardware and Software. The experiments were run on an Acer Aspire V3 with an Intel Core i7-3632QM processor and an NVIDIA GeForce GT 740M graphics card. The DASH client is written in Rust1 , using Glium2 for rendering, and reqwest3 to load the segments.

Metrics. To objectively evaluate the quality of the resulting rendering, we use PSNR. The scene as rendered o ine using the same camera path with all the geometry and texture data available is used as ground truth. Note that a pixel error can occur in our case only in two situations: (i) when a face is missing, in which case the color of the background object is shown, and (ii) when a texture is either missing or downsampled. We do not have pixel error due to compression.

Experiments. We present experiments to validate our implementation choices at every step of our system. We replay the usergenerated camera paths with various bandwidth conditions while varying key components of our system.

Table 2 sums up all the components we varied in our experiments. We compare the impact of two space-partitioning trees, a k-d tree and an Octree, on content preparation. We also try several utility metrics for geometry segments: an o ine one, which assigns to each geometry segment s G the cumulated 3D area of its belonging faces A 3D (s G ); an online one, which assigns to each geometry segment the inverse of its distance to the camera position; and nally our proposed method, as described in Section 4.1 (A 3D (s G )/D( (t i ), AS G ) 2 ). We consider two streaming policies to be applied by the client, proposed in Section 4. The greedy strategy determines, at each decision time, the segment that maximizes its predicted utility at arrival divided by its predicted delivery delay, which corresponds to equation [START_REF] Cheng | Receiver-driven View-dependent Streaming of Progressive Mesh[END_REF]. The second streaming policy that we run is the one we proposed in equation [START_REF] Behr | A scalable architecture for the HTML5/X3D integration model X3DOM[END_REF]. We have also analyzed the e ect of grouping the faces in geometry segments of an adaptation set based on their 3D area. Finally, we try several bandwidth parameters to study how our system can adapt to varying network conditions.

Experimental Results

Figure 3 shows how the space partition can a ect the rendering quality. We use our proposed utility metrics (see Section 4.1) and streaming policy from Equation (1), on content divided into adaptation sets obtained either using a k-d tree or an Octree and run experiments on all camera paths at 5 Mbps. The Octree partitions content into non-homogeneous adaptation sets; as a result, some adaptation sets may contain smaller segments, which contain both important (large) and non-important polygons. For the k-d tree, we create cells containing the same number of faces N a (here, we take N a = 10k). Figure 3 shows that the system seems to be slightly less e cient with an Octree than with a k-d tree based partition, but this result is not signi cant. For the remaining experiments, partitioning is based on a k-d tree.

Figure 4 displays how a utility metric should take advantage of both o ine and online features. The experiments consider k-d tree cell for adaptation sets and the proposed streaming policy, on all camera paths. We observe that a purely o ine utility metric leads to poor PSNR results. An online-only utility improves the results, as it takes the user viewing frustum into consideration, but still, the proposed utility (in Section 4.1) performs better.

Figure 5 shows the e ect of grouping the segments in an adaptation set based on their area in 3D. Clearly, the PSNR signi cantly First improves when the 3D area of faces is considered for creating the segments. Since all segments are of the same size, sorting the faces by area before grouping them into segments leads to a skew distribution of how useful the segments are. This skewness means that the decision that the client makes (to download those with the largest utility rst) can make a bigger di erence in the quality. We also compared the greedy vs. proposed streaming policy (as shown in Figure 6 for limited bandwidth (5 Mbps). The proposed scheme outperforms the greedy during the rst 30s and does a better job overall. Table 3 shows the average PSNR for the proposed method and the greedy method for di erent downloading bandwidth. In the rst 30 sec, since there are relatively few 3D contents downloaded, making a better decision at what to download matters more: we observe during that time that the proposed method leads to 1 -1.9 dB better in quality terms of PSNR compared to Greedy.

Table 4 shows the distribution of texture resolutions that are downloaded by greedy and our Proposed scheme, at di erent bandwidths. Resolution 5 is the highest and 1 is the lowest. The table clearly shows a weakness of the greedy policy: as the bandwidth increases, the distribution of downloaded textures resolution stays more or less the same. In contrast, our proposed streaming policy adapts to an increasing bandwidth by downloading higher resolution textures (13.9% at 10 Mbps, vs. 0.3% at 2.5 Mbps). In fact, an interesting feature of our proposed streaming policy is that it adapts the geometry-texture compromise to the bandwidth. The textures represent 57.3% of the total amount of downloaded bytes at 2.5 Mbps, and 70.2% at 10 Mbps. In other words, our system tends to favor geometry segments when the bandwidth is low, and favor texture segments when the bandwidth increases.

CONCLUSION AND FUTURE WORK

Our work in this paper started with the question: can DASH be used for NVE? The answer is yes. In answering this question, we contributed by showing how to organize a polygon soup and its textures into a DASH-compliant format that (i) includes a minimal amount of metadata that is useful for the client, (ii) organizes the data to allow the client to get the most useful content rst. We further show that these metadata that is precomputed o ine is su cient to design and build a DASH client that is adaptive -it can selectively download segments within its view, make intelligent decisions about what to download, balancing between geometry and texture while being adaptive to network bandwidth. We believe our proposed DASH for NVE is exible enough for the community to start the simplicity and ease of deployment of DASH for NVE and to start investigating di erent streaming strategies to improve the quality of experience of NVE users.

In the future, we will try to take into account any semantic information that would be available to avoid splitting buildings in di erent adaptation sets for example. With semantic information, we will also try to embed multi-resolution geometry support, and de ne the utility metrics accordingly.

Figure 2 :

 2 Figure 2: Rendering of the model with full resolution texture (left), and faces with average default color (right).

Figure 3 :

 3 Figure3: Impact of the space-partitioning tree on the rendering quality with a 5Mbps bandwidth.

Figure 4 :

 4 Figure 4: Impact of the segment utility metric on the rendering qualit with a 5Mbps bandwidth.

Figure 5 :

 5 Figure 5: Impact of creating the segments of an adaptation set based on decreasing 3D area of faces with a 5Mbps bandwidth.

Figure 6 :

 6 Figure 6: Impact of the streaming policy (greedy vs. proposed) with a 5 Mbps bandwidth.

Resolutions

Table 1 :

 1 Sizes of the di erent les of the model

		Size	Files	Size
	3DS Max	55 MB	OBJ le 62 MB
	Textures (high res) 167 MB MTL le 0.27Mb
	Textures (low res) 11 MB

Table 2 :

 2 The rst request ( HTTP r equest) made by the DASH client at time t 1 selects the most useful segment s 1 * to download and will be followed by subsequent decisions at t 2 , t 3 , . . . . While selecting s * , i the i-th best segment to request, the adaptation logic compromises between geometry, texture, and the available representations given the current bandwidth, camera dynamics, and the previously described utility scores. The di erence between t i+1 and t i is the s * delivery delay. It varies with the segment size and network con-Di erent parameters in our experiments

	Parameters	Values
	Content preparation	Octree, k-d tree
	Utility	O ine, Online, Proposed
	Streaming policy	Greedy, Proposed
	Grouping of Segments Sorted based on area, Unsorted
	Bandwidth	2.5 Mbps, 5 Mbps, 10 Mbps

Table 3 :

 3 Average PSNR, Greedy vs. Proposed

			30 Sec		Overall
	BW (in Mbps) 2.5	5	10	2.5	5	10
	Greedy	14.4	19.4	22.1	19.8	26.9	29.7
	Proposed	16.3	20.4	23.2	23.8	28.2	31.1

Table 4 :

 4 Percentages of downloaded bytes for textures from each resolution, for the greedy streaming policy (left) and for our proposed scheme (right)

		2.5 Mbps	5 Mbps	10 Mbps
	1	5.7% vs 1.4%	6.3% vs 1.4%	6.17% vs 1.4%
	2	10.9% vs 8.6%	13.3% vs 7.8%	14.0% vs 8.3%
	3	15.3% vs 28.6% 20.1% vs 24.3% 20.9% vs 22.5%
	4	14.6% vs 18.4% 14.4% vs 25.2% 14.2% vs 24.1%
	5	11.4% vs 0.3%	11.1% vs 5.9% 11.5% vs 13.9%

https://www.rust-lang.org/

https://github.com/glium/glium

https://github.com/seanmonstar/reqwest/


Imen Akermi
email: imen.akermi@irit.fr

Mohand Boughanem
email: mohand.boughanem@irit.fr

Rim Faiz
email: rim.faiz@ihec.rnu.tn

A Probabilistic Model for Intrusive Recommendation Assessment

Keywords: Intrusiveness assessment, proactive recommender systems, contextawareness, risk-awareness, mobile applications

The overwhelming advances in mobile technologies allow recommender systems to be highly contextualized and able to deliver recommendation without an explicit request. However, it is no longer enough for a recommender system to determine what to recommend according to the users' needs, but it also has to deal with the risk of disturbing the user during recommendation. We believe that mobile technologies along with contextual information may help alleviate this issue. In this paper, we address intrusiveness as a probabilistic approach that makes use of the several embedded applications within the user's device and the user's contextual information in order to gure out intrusive recommendations that are subject to rejection. The experiments that we conducted have shown that the proposed approach yields promising results.

INTRODUCTION

In certain situations, the user may choose to reject a recommendation regardless of its content. This abstinence may not concern the recommended information itself but it takes part in the situation where the user may be in and during which the user does not want to be interrupted or disturbed. Therefore, it is crucial to assess the intrusiveness level of the user's situation before sending any recommendation. In this paper, we address intrusiveness as a probabilistic decision making process within a proactive recommendation approach that takes into account not only the user's agenda activities but also the user's contextual information with its several level of representation along with other applications and technologies embedded within the user's mobile device. Indeed, the several sensors and information provided by mobile devices can help keep track of the situations during which recommendations are subject to rejection. This paper's main contributions can be summarized as the following:

• A probabilistic intrusiveness assessment approach that integrates contextual information along with the applications and sensors embedded within the user's mobile device.

• An extensive evaluation framework for intrusive recommendation assessment

The paper is organized as follows. We introduce in section 2, a literature review about intrusiveness/risk assessment within proactive recommender systems. We detail in section 3 the proposed approach. Section 4 describes the experiments that we conducted using a user study and we conclude in section 5 with thoughts for future work.

RELATED WORK

The work presented in [START_REF] Djallel Boune Ouf | A contextual-bandit algorithm for mobile context-aware recommender system[END_REF] was the rst to integrate intrusiveness as a phase in which they assess the risk of disturbing the user before recommending. They de ne a "critical" or "risky" situation as a situation in which a user does not want to be disturbed. For each situation, they compute a risk score that depends on the risklevel of the concept describing the user's activity extracted from his/her agenda. They believe that a situation is deemed risky if its risk score exceeds a pre-de ned threshold. They assume that the user indicates, for each activity he/she may undertake, the time and the location information, which is not always the case in real life. Bedi et al. [START_REF] Bedi | A Situation-Aware Proactive Recommender System[END_REF] proposed a situation assessment approach for restaurants recommendation, that uses fuzzy logic as an inference technique that depends on distance, time, budget and reachability, to assess the context level (i.e. intrusiveness level) of a given situation. For example, they prede ne the fuzzy sets for the context level and the distance attribute as: Distance={Near,Moderate,Far}, Context-level={Low,Medium,High}. The context attributes are used in a rule-based approach to infer the context-level, example: IF(Distance IS 'Near') AND (Time IS 'In-Time') AND (Budget IS 'Affordable') AND (Reachability IS 'High') THEN Context-level IS 'High'. In [START_REF] Liu | When privacy meets usability: unobtrusive privacy permission recommendation system for mobile apps based on crowdsourcing[END_REF], the authors tackled non-intrusiveness as a privacy permission issue. They actually ask users explicitly before recommending to choose among three options : "agree", "reject" or "agree only this time" to get a recommendation. The work presented in [START_REF] Ho | Using context-aware computing to reduce the perceived burden of interruptions from mobile devices[END_REF] explored the user's receptivity to noti cations/interruptions and suggested that the opportune moments for a user to get interrupted, regardless of his/her situation or the noti cation's content, is only at activity transitions, which means that they only consider a noti cation as non-intrusive when the user is practically transitioning from the use of a given application to another. The work proposed in [START_REF] Nofar | Please, not now!: A model for timing recommendations[END_REF] considered intrusiveness in a recommendation approach as a classi cation problem which aims at identifying whether a given context is "good" or "bad" to trigger the recommendation process. They collected mobile data over a three weeks user study in order to learn the classi cation model. These works and several others [START_REF] Amini | Capturing scholar's knowledge from heterogeneous resources for pro ling in recommender systems[END_REF][START_REF] Kay-Lynn | A personal, mobile system for understanding stress and interruptions[END_REF][START_REF] Luo | Non-intrusive energy saving appliance recommender system for smart grid residential users[END_REF][START_REF] Sabic | Proactive Recommendation Delivery[END_REF][START_REF] Scha | Hypothetical Recommendation: A Study of Interactive Pro le Manipulation Behavior for Recommender Systems[END_REF][START_REF] Daniel P Siewiorek | SenSay: A Context-Aware Mobile Phone[END_REF][START_REF] Reto | A web-based non-intrusive ambient system to measure and classify activities of daily living[END_REF] tend to deal with the intrusiveness issue from an implicit user pro ling angle and they depend on the user's explicit feedback to gure out if a recommendation is appropriate or not, forgetting that the large amount of applications embedded in the user's phone could be the issue itself. Therefore, we propose in this paper, to assess intrusiveness from a situation assessment perspective, not only in terms of context as generally de ned by time and location, but also considering the actual user' activity inferred from the applications that a user is using at a given situation and the sensors installed within the user's mobile device.

ASSESSING A SITUATION'S INTRUSIVENESS LEVEL 3.1 Situation modelling

The probabilistic intrusiveness assessment method that we propose is integrated within a proactive recommendation approach that covers various domains like POI (Points of Interests), News, Movies, etc. It consists in recommending information that match a user's situation and preferences without waiting for the user to initiate any interaction with his/her device [START_REF] Akermi | Just-In-Time Recommendation Approach within a Mobile Context[END_REF]. The recommendation of an item is only sent after assessing the intrusiveness level of the user's current situation. We model the user's daily routine as a set of situations described by the user's actual activity and the spatio-temporal contextual factors. In a more formal way, a situation is represented as S = (F t , F w , F l , F a ), where: F t is time of the day , F w is day of the week , F l is the user's actual location and F a is the user's activity. Therefore, the recommendation process entails a context model that gures out what and when to recommend the relevant information (news, movies, a place to visit, a restaurant, ...) to the user according to his/her situation. Indeed, we believe that a situation, with its di erent level of representation, de nes the changing user's information need. In this paper, we do not focus on the type of information that may be recommended to the user and that was addressed in [START_REF] Akermi | Just-In-Time Recommendation Approach within a Mobile Context[END_REF], but we rather expose a probabilistic approach for balancing the recommendation process against intrusive interruptions. Indeed, as we are working within mobile devices framework, the risk of disturbing the user becomes increasingly high. Indeed, according to the 2017 Mobile Usage Report 1 , people spend more than 50% of their digital time on smartphone applications. The desktop represents only 34% of the digital time and it was also observed that entertainment and 1 https://www.comscore.com/Insights/Presentations-and-Whitepapers/2017/ The-2017-US-Mobile-App-Report communication applications (social networks, instant messaging) account for almost two-thirds of the time spent. We believe that the amount of information provided by mobile devices not only provide valuable information about the user's interests but also can help gure out the user's situation in general and the user's activity in particular, which can alleviate the problem of assessing whether a situation is conducive to recommendation's rejection or not. In order to assess intrusiveness in this approach, we only consider F t , F w and F a as the features describing a situation S = (F t , F w , F a ). The time feature takes into account two levels: time of the day and the week day. We choose to divide a daily routine into four periods (morning, midday, afternoon and evening) that are framed within 24 hours intervals.

F t ∈ {mor nin [07 : 00, 12 : 00], midda [12 : 00, 14 : 00], af t er noon[14 : 00, 18 : 00], e enin [18 : 00, 00 : 00]}.

Assuming that the user lives in a Western country, the weekdays can be partitioned as following:

F w ∈ {wor k_da s {monda , ..., f r ida }, r est _da s {satur da , sunda , publ ic_holida } }.
This partition is automatically changed according to the user's location. Indeed, while Saturdays and Sundays may be rest days in most Western countries, this is not the case for Middle-Eastern countries, where Friday is typically a rest day and Sunday is not. At a given situation S i , the system takes a snapshot of the user's current activity F a such as driving, texting messages, tweeting or browsing, using the sensors and the applications embedded in the user's mobile device. For example, we can gure out if the user is in a meeting according to his agenda or if the user is driving or jogging by checking the accelerometer sensor.

Intrusiveness assessment

We assess intrusiveness as a probabilistic function measuring the natural logarithm of the conditional probability of recommendation acceptance knowing the user's actual situation upon the conditional probability of the recommendation rejection:

θ = ln P (R|S = S i ) P (¬R|S = S i ) (1)
Where R stands for the act of sending a recommendation and S i refers to the i t h situation, for a given user.

According to the θ 's score, the system decides if the user's situation is appropriate to recommendation, i.e. non-intrusive, or not. As we explained earlier, a situation is modelled as S = (F t , F w , F a ) referring respectively to time of the day, day of the week and the user's current activity. Thus, the intrusiveness score can be estimated as :

θ = ln P (R|F i t , F i w , F i a ) P (¬R|F i t , F i w , F i a ) (2)
Where F i k , k ∈ {t, w, a}, is the k t h feature of situation S i . After applying the Bayes rule, the conditional probability of sending a recommendation R knowing the features of situation S i (respectively ¬R) is written as:

P (R|F i t , F i w , F i a ) = P (F i t , F i w , F i a |R) × P (R) P (F i t , F i w , F i a ) (3)
Assuming that the situation's features are independent and that

P (F t i , F i w , F i a ) is uniform, then P (R|F t i , F i w , F i a ) (respectively P (¬R|F t i , F i w , F i a )
) for a given user can be expressed as:

P (R|F i t , F i w , F i a ) ∝ k ∈ {t,w,a } P (F i k |R) × P (R) (4)
Where P (F i k |R) refers to the probability of having feature F i k (time of the day, day of the week or activity) within situations where recommendations were accepted R (respectively rejected for P (F i k |¬R)).

P (F i k |R) = |S R, F i k user | |S R user | (5)
Where :

|S R, F i k user
| is the number of situations that occurred to the given user and during which feature f k = f i k of situation S i and recommendation was accepted, i.e. R(respectively rejected for ¬R). |S R user | is the number of situations during which the user accepted a recommendation (respectively rejected for ¬R). In order to avoid zero equal probabilities, we consider Dirichlet smoothing [START_REF] David | A hierarchical Dirichlet language model[END_REF] that combines the use of a parameter µ along with judgements of other users regarding a given situation. Therefore, P (F i k |R) (respectively P (F i k |¬R)) can be estimated as:

P (F i k |R) = |S R, F i k user | + µ × |S R, F i k al l | |S R al l | |S R user | + µ (6)
Where : µ ∈ [1, 1000] is a parameter that is set according to experiments.

|S R, F i k

all | is the number of situations that occurred to other users and during which feature f k = f i k of situation S i and recommendation was accepted (i.e. R). |S R all | is the number of situations that occurred to other users and during which the recommendation was accepted (respectively rejected for ¬R).

Deciding whether a recommendation will be perceived by a given user as intrusive or not is determined by the θ score (see Eq 1). If θ > 0, the recommendation is deemed non-intrusive.

EXPERIMENTS

Since work on intrusiveness assessment evaluation within recommender systems (RS) is still at its early stages, we could not nd a suitable dataset to evaluate the approach that we propose. Therefore, we opted for constructing a user study. Indeed, this kind of evaluation allows a subjective assessment of the system as surveys can be conducted along with the experiments.

User study

The user study that we conducted integrates automatically generated situations simulating real life ones. These situations are described by four features: time of the day, the week day, the user's current activity and the type of information that can be recommended (news, POI, restaurant, TV program, etc.). The possible values that can be taken by the rst three features were gathered using a survey that we carried within our lab (colleagues from di erent backgrounds and age range). We made sure that these values could be extracted through the applications and sensors embedded within the user's mobile device. We addressed the type of information that can be recommended according to a user's given situation in a previous work [START_REF] Akermi | Just-In-Time Recommendation Approach within a Mobile Context[END_REF]. The set of the generated situations is then ltered in order to take out those that are not likely to happen, like having a meeting at late night at home. We choose to work with 100 situations to avoid participants getting bored and then bias the study. More than 1400 participants took part in this study. Given a situation they might be in, participants were asked if they accept to get a recommendation or not regardless of the content of the information being recommended. They were also asked to express their opinion with reference to the information they were recommended according to their situation. Here is an example of a situation that can be suggested to a participant:

It is Saturday,Afternoon and you are doing the following activity : Walking Would you accept to get a notification :

• YES • NO Given this situation, do you think that recommending this type of information is interesting : Points of interests(Park, Museum, ...), Concert Theaters Program,Movie Theaters Program:

• YES • NO Comments: (please comment your answers)

We used the Crowd ower2 platform to run the user study. In order to avoid any bias, we con gured several quality control mechanisms such as speed traps measuring the time spent by a participant to answer the questions of the study. We also made sure that the participants understand perfectly English and the questions they were asked. In this paper, we only considered the rst section of this study that addresses the issue of accepting to receive a recommendation or not regardless of its content. We used the Mean Average Precision (MAP) metric to evaluate the intrusiveness assessment accuracy across all the participants and against two baselines.

Results

We run a K-cross-validation evaluation (K=10) in order to put forward the accuracy of the proposed approach for intrusiveness assessment:

MAP = U u=1 A eP (u) U (7)
A eP (u)

K k =1 r el _s S K (8)
Where U is the number of users, rel_s is the number of correctly assessed situations for each run, K is the number of runs (K = 10)and S is the number of situations.

Then, a mean over all users for every possible feature combination is calculated. As we are using the Dirichlet smoothing in the proposed approach, we varied µ within the range of [START_REF] Akermi | Just-In-Time Recommendation Approach within a Mobile Context[END_REF]1000] while computing the MAP.

The results that we obtained have shown that the proposed approach for intrusiveness assessment performs better when µ equals 1, which is normal since we do not address a large volume of data like it is typically addressed within Information Retrieval tasks. As illustrated in Figure 1, the proposed approach using the situation's features that we considered scores 88.5% for the MAP compared to other features' combinations, to two baseline approaches and to a Case Based Reasoning approach that we proposed in a previous work [START_REF] Akermi | Situation assessment for non-intrusive recommendation[END_REF]. Baseline A which sends recommendations without considering the user's interruptibility scores 64% for the MAP. Baseline B which consists in not sending a recommendation when an application is ON, scores 50.81%. The CBR approach proposed in [START_REF] Akermi | Situation assessment for non-intrusive recommendation[END_REF] consists in using the user's analogous past situations, that are most similar to the actual situation, to gure out if we could interrupt the user's current activity and send a recommendation. The CBR approach scored a MAP of 87% which is slightly less accurate than the proposed probabilistic approach. Indeed, while the CBR approach only uses the user's past situations, the probabilistic approach combines the user's and other users' judgements. We also note that, for the probabilistic approach, the combinations that entail the activity feature, like Activity-Time, Activity-Day and Activity, scores a high precision that is quite similar to the MAP of the approach that makes use of all the features. Then, we can assume that users mainly tend to reject recommendations based on what they are doing at a given situation and do not always consider the other features like time of the day or the week day. However, based on a study that we conducted on the same dataset, we noted that these features are important for users to decide whether a given recommended type of information is interesting or not, given the situation they might be in [START_REF] Akermi | Just-In-Time Recommendation Approach within a Mobile Context[END_REF]. Besides, the performance of Baseline B, which considers that a recommendation should not be sent when an application is ON, proves that approaches that automatically consider the use of any random application at a given situation as a hinder to sending a recommendation, are not e ective. It actually depends on the type of the application being used and on the user's behaviour. These ndings are also proved by the analysis that we conducted on the users' responses regarding recommendations and according to the undertaken activity. We measured the proportion of users who considered recommendations, while undertaking some activities, as intrusive or not. Figure 2 puts forward some of the activities that we prede ned for this study. We notice that more than 70% of the participants did not consider recommendations as intrusive while chatting or tweeting. This can be explained by the fact that people may want to share the recommended information with friends. We also note that 59% of the participants against 41% were not disturbed when getting a recommendation while taking a picture which could be somehow interpreted as not making sense because we normally expect users to get annoyed if they were interrupted while typing a message or using the device's camera. These ndings make us believe that the content of the information has to be considered also as a feature. In fact, a user may not want to be disturbed usually when working but perhaps work related news is still acceptable. Indeed, even though the user chose not to be disturbed, the recommended information might be worth being interrupted for, such as breaking news or an accident that happened on the user's way home.

We believe that such trade-o need to be studied. Therefore, we are currently working on integrating into the approach we proposed, a trade-o between the importance of the information to be recommended and the risk of disturbing the user. We also made the conducted user study available 3 for the RS research community as a dataset for intrusiveness assessment. This may help alleviate the datasets shortage and might provide a framework for di erent approaches to be compared on a same basis.

CONCLUSION

We put forward, in this paper, a probabilistic approach for intrusiveness assessment for proactive recommendation that exploits the applications and sensors installed within the user's device along with other contextual information. The user study that we conducted for the experiments has proven that the proposed approach yielded promising results regarding intrusiveness assessment and recommendation accuracy.

Figure 1 :

 1 Figure 1: MAP evaluation for the Intrusiveness assessment approach

  who are disturbed when getting a recommendation Proportion of users who are not disturbed when getting a recommendation

Figure 2 :

 2 Figure 2: Correlation between intrusiveness and activities

https://www.crowd ower.com/