a qos model for collaboration through distributed virtual environments

Journal of Network and Computer Applications(2000)23, 311–334

doi:10.1006/jnca.2000.0116, available online at http://www.idealibrary.com on

A QoS model for collaboration throughDistributed Virtual Environments

Zi ed Choukair and Damien RetailleauENST Bretagne, D´epartement Informatique, Technopˆole de l’Iroise, 29285 Brest cedex,France. E-mail: (Zied.Choukair,Damien.Retailleau)@ enst-bretagne.fr

Today’s virtual environments are expected to be distributed to allow collaboration forcommon purposes. However, they must ensure a high level of Quality of Service (QoS)to the user, especially in an open context with unknown,a priori, man-in-the-loop eventoccurrence. This paper presents our Distributed Virtual Environment Collaboration Model(DVECOM) and its implementation which aims to provide an end-user QoS supportfor distributed virtual reality applications. This model aims to reconcile openness andreal-time requirements for collaborative relationships using virtual environments. Real-time requirements ensure the logical synchronization between the displayed scenes ofthe same virtual world on a set of distributed machines. The DVECOM model is basedpartially upon COREMO concepts and further work done in the context of the AmusementEuropean Esprit project.

DVECOM integrates QoS provision and management. The major idea is to guaranteethe consistency of scene rendering and the synchronization of the display from the userpoint of view. The other idea is to auto-adapt rendering in accordance with the retainedstrategy, ensuring best effort and least suffering virtual world rendering. Representationdegradation is driven by the users’ choices and is assisted by the system. The receiver-side protocol is based upon end-user preferences, physical level capability information,as well as pertinence of notification to each client (contextual end-user information). Themodel should be able to guarantee logical consistency and synchronization of virtualworld distributed displays, with the least rendering degradation possible. When avail-able, such guarantees would make it possible to use DVE out of a closed, oversized,very restricted context for industrial collaborative applications with an expected QoS.

2000 Academic Press

1. Introduction

Distributed virtual reality environments are often referred to as DistributedVirtual Environments (DVE). DVE is a new paradigm at research stage, whereascentralized virtual environments are considered nowadays and have enteredindustrial applications. Next-generation applications are, for example, DVE intele-medecine, collaborative CAM/CAD, electronic meeting areas, and severalothers [1,3,26]. Combining DVE, Internet, and Intranet technologies will providemore interactive collaborative virtual environments for the specified needs.

The underlying mandatory distribution of DVE raises issues. Some of themare classical such as ‘consistency of copies’, ‘transparency’, ‘naming’, ‘trad-ing’, ‘security’. Others are more specific to VR such as ‘multicast communi-cations’, ‘continuous media support’, and ‘adaptivity to the presentation’. With

1084–8045/00/030311C 24 $35.00/0 2000 Academic Press

312 Z. Choukair and D. Retailleau

respect to real-time, for example, multimedia applications require specific pro-tocols to fit their temporal constraints [2]. For such systems, soft real-timeapproaches are more appropriate unless we use QoS transfer protocol and network(ATM [3], VPN).

In our DVE research, we developed a model called DVECOM to supportreal-time collaborative applications. Our objective was to study whether wecould integrate Quality of Service with Real-Time Constraints (RT-QoS) as anintegral part of DVE models. RT-QoS, in our approach, consists of guaran-teeing that each participant in a virtual world benefits from an awareness ofquality, so that each participant is logically synchronized with other partici-pants. DVECOM-compliant applications offer each participant the possibility ofspecifying alternative and rendering strategies providing that the semantic staysidentical.

In this paper, we will briefly present DVE and associated issues. We will outlinethe general approach taken in our work and introduce our collaboration model,based upon [2]. After which, we will develop the architecture and its underlyingmechanisms capable of auto-adaptive management of system resources basedupon application-level QoS specifications. The second major part of the paperis dedicated to the description of our VirtualArch platform, which supportsDVECOM in its latest version. The last section preceding conclusions is dedicatedto our future research directions concerning the evolution of the model towardsmore consultation for the provision and the management of QoS for collaborativevirtual platforms.

2. DVE

Virtual reality (VR) is an alternative of physical reality. It allows us to over-step physical reality by defining a virtual world and letting users enter itthrough avatars or HMI. Numerous new types of interactions could be imag-ined such as design, simulation and restoration inside new worlds designed inan imaginary (science fiction, imaginary past, fantastic) or symbolic perspective.Possible application domains include collaborative CAM/CAD, tele-operationswith behavioural interfaces, real-time simulations, or virtual casino to ease theinteraction between people through their avatars. When used as a medium forcollaborative work within virtual teams upon virtual items, VR eliminates geo-graphical and physical constraints, supports low-cost experimentation and helpsto adapt presentation to personal constraints or preferences.

From the distribution perspective, each user involved in a virtual realitycollaboration needs to have an up-to-date local representation of the virtual worldin which he’s evolving. The inherent distribution of the virtual scene resultsin duplication of each logical virtual entity called avatar (the original copy isthe one which initiated the last update event), and as many ghosts as updatereceivers.

A QoS model for collaboration through Distributed Virtual Environments 313

2.1 Distribution approaches

Two major distribution approaches can be distinguished for virtual reality:the classical approach and the centralized approach. The classical approach isbased upon usual point-to-point, multicast/broadcast active replication proto-cols whereas the centralized approach is based upon collect/dispatch filteringservers.

The centralized approach obviously presents the drawback of a bottleneck, anddrastically decreases the performances of the whole application. It is, however,useful for event-driven communication approaches where the clients subscribeto specific event occurrences and want to be notified when they take place.Unfortunately, continuous dispatch of all information to each client in the classicalmulticast approach is resource consuming, and requires adequate and heavyupdate synchronization and message ordering algorithms to ensure the requiredproperties for such a collaboration environment. Nevertheless, this is still thesimplest approach to distribute those environments by duplicating the objects ofthe world on each site.

In this approach, the system is in charge of making distribution and objectreplication transparent to the user and this implies the implementation of aplethora of protocols. However, virtual environments need to comply with real-time constraints and can not afford to be overloaded in such a way. A firstoptimization approach was to reduce the volume of exchanged messages from a‘continuous update’ approach to a ‘just when necessary’ update approach. Othertechniques, such as dead reckoning (event-oriented re-synchronization betweencopies) and limited focus/nimbus, were developed to limit message exchangesas well as the number of locally managed objects. Another interesting techniqueconsists of making behavioral and rendering distinctions between the originalobject and its copies, called substitutes or ghosts, by divesting them of some oftheir behaviour and degrading their rendering when possible.

There has been considerable research into developing DVE and underlyingdistribution protocols, e.g. DIVE [4], AVIARY [5], MASSIVE [6], SIMNET [7],NPSNET [8], PARADISE [9], Waves/Hydra and Sense8 [10]. A standardIEEE protocol targeted towards entity-level, real-time simulations is calledDistributed Interactive Simulation (DIS). The protocol [11] is the most com-monly used DVE protocol. It provides several powerful ideas and bandwidthsavings. DIS:

ž provides a standard message format through the definition of Portable DataUnits (PDU);ž reduces resource needs by using dead reckoning: each ghost (avatar copy)

estimates its future state without events from the original. When the differencebetween the original and a ghost exceed a givena priori specified threshold,the original sends a re-synchronize event to this ghost. When the low fidelityand high fidelity representations differ by some predetermined threshold, the


owning simulation broadcasts a Portable Data Unit containing the actual (highfidelity) values;ž combines update filtering and areas of interest;ž uses multicasting only for keep-alive and group management messages.

Other recent protocols include the Interactive Sharing Transfer Protocol(ISTP) [5], the Virtual Reality Transfer Protocol VRTP, High Level Architec-ture [12,13], a generalization and extension of DIS (targeted towards entity-level, real-time simulations), and Aggregate-Level Simulation Protocol [14],(targeted towards support for the interoperation of aggregate-level, logical-timesimulations).

2.2 Representation mechanisms

A typical DVE is widely distributed in widely heterogeneous nodes. Enablingtechnologies have become widely available and the associated applications largerand more complex. Hence, the provision of heterogeneity transparency willundeniably ease the development of such VR distributed applications. However,this heterogeneity raises the new problem of managing strict synchronizationbetween displays through presentation auto-adaptivity according to resourceavailability. (The adaptivity of a system is its ability to adapt itself dynamically tomeet some predefined QoS.) This auto-adaptivity strategy is mandatory whether ornot the application takes place in an open environment, because available resourcecapabilities have a ceiling and the needs of the VR application are important.The evolution of Internet and VR technologies, as well as their democratization,requires that we consider the scalability problem to make these VR distributedapplications available to numerous users.

To address auto-adaptivity issues, we must balance the differences betweenthe underlying heterogeneous system capabilities through integration of compen-sation algorithms. Many aspects must be taken into account including hardwareparameters (bandwidth and CPU availability, network latencies), software param-eters (OS, VR environments, distribution protocols), awareness of other people’spresence and its implication for resources’ needs and subjectivity in perception.To achieve auto-adaptivity of presentation, we may adjust resource allocationsto satisfy the goal at each site, whether by negotiating an extra or by degradingrepresentation.

Allowing physical-layer characteristic variation requires an application struc-ture that separates the abstract object from its representation. This separationallows us to represent an abstract object according to the available resourceswhile manipulating it. As an example, a landscape may be represented as a videoor as an image or even as a text. Another way to abstract an object consists ofdefining its graph, so that when more resources are available, the componentsin charge of low-level interactions will display more information than strictlyneeded to increase the comfort of the user. An immediate approach to resource


adaptivity is to modify the used media. For example, the system may degradeimages by changing its parameters and degrading its quality. Among the modifiedparameters are resolution, colour range and space, and rate of compression. Thedifficulty of this approach is that the maximal degradation that an image mayreasonably allow depends highly on its contents. Thus it is difficult to definea common degradation that will work for all images without hiding mandatorydetails. This approach is currently used by some game developers to adapt thepresentation of the game to the hardware installed at the user site.

The following is a quick overview of some concrete protocols integrated intoknown DVEs that improve the performance of applications relying on them.MASSIVE adopts representation on the basis of aura (awareness), focus (vision),and nimbus (visibility). It targets the detail of perception due to the tuning ofdifferent media. In PARADISE, different views may be derived from a scene.Objects are grouped into different categories according to the regularity ofthe frequency of their state changes. The optimization consists of using deadreckoning algorithms for each category. An object may also change its modeand density of updates according to its distance from the local user. In AVIARY,an artifact may appear in different areas connected through portals and havingdifferent associated laws with appearance changes. The artifact is composed oftwo entities: a daemon for the behavior and an instance of the world that containsspecific properties and laws relating the artifacts in this world. DIVE/WAVEsystems manage an internal representation of the world through a membershipconcept. An aura manager indicates to each client the ‘lightweight groups’ ofinterest for subscription. The advantage of this partitioning has the advantage oflimiting the range of awareness for each object. Open Community [15] dividesthe virtual world into zones called locales. An object is only conscious of its ownlocale and the adjacent ones. This approach is not adapted to many applicationswhere each avatar needs to be aware of all the participants or to be perceived bymost of them.

At this stage, we can say that to support an application-driven QoS approach,we require the support of an auto-adaptive representation mechanism. In thisway, the application will adapt to the available resources in a best effort andleast rendering degradation approach.

3. DVECOM

3.1 The QoS concerning real-time

DVEs are designed for a wide range of users in an open and free way. Thecharacteristics of open systems are rather unpredictable: they consist of a group ofcollaborating users, the update arrivals being neither predictable nor schedulableapriori . All these unknowns make DVE applications unpredictable and unsuitablefor critical hard real-time applications conceived off-line with a deterministicknown asa priori system [16,17].


From now on, we will consider only soft real-time applications for which thesystem will support the best effort and least suffering approaches concerning real-time on-line management [18]. For such applications, the system will do its best torun the application in a correct way, with respect to functional or temporal aspects.However, in case it is impossible to comply with the requirements, the systemmust reduce the impact on the application by decreasing as little as possible therendering level of QoS. The real-time constraints will not be released as theyare mandatory. Synchronization, as well as identical scheduling of messages aremandatory to simulate the virtual world in the same way, at the same time for eachparticipant, even if the user’s display preferences are taken into account. In fact, itis impossible to be tolerant concerning real-time aspects and to authorize overstep-ping, as in a collaborative real-time environment. We can not delay the effect ofthe occurrence of a user’s event or the participants will no longer be synchronized.

3.2 Our approach

The idea for DVECOM [19] is to guarantee synchronization of the displays, andprovide an environment that supports the best effort and least suffering for therendering of distributed displays of the same virtual scene according to each user’sprescriptions. This way, the participants will benefit from the most adapted displayexpressiveness of the virtual world at the same time. For degradation needs, wedistinguish three main approaches: time polymorphic, imprecise calculus andfeasibility evaluation [2]. We discarded the last two approaches for the followingtwo reasons:

1. Imprecise calculusis acceptable only for specific applications. Moreover, itrequires a mathematical VR adequate modelling of the whole virtual worldfor such a specific purpose. We discarded this approach as it is beyond ourconcerns and skills.

2. Feasibility evaluation, based upon the selection of actions to retain and othersto reject, does not take into account all of the updates and does not guaranteestrict synchronization of the virtual world replica.

Even if it returns degraded functional results, the Time Polymorphic approachwas retained because it keeps accepting update messages and processes them,ensuring the full synchronization of the virtual world replica. The drawback ofthis approach is that the participant may not understand the semantic of themodified entity of the displayed virtual world. That is why we have to takecare of keeping the polymorphic representations of the same entity, guaranteeingidentical semantic, as well as the availability of critical information.

3.3 Overview of the model

We designed, developed, and are still testing VirtualArch, a platform whose lastversion offers the described support. DVECOM guarantees logical consistency


T i + 2

Updatesdisplay

T i + 1T i

Updates acceptanceUpdates treatment

Figure 1. DVECOM update stages.

and synchronization of the distributed virtual world. Each participant needs toperceive the virtual world exactly in the same way as the others. To guarantee suchsynchronization, we defined two update stages: acceptance and treatment. Even ifthe postponement of treatment delays the display, the displayed information willnot only be synchronous but will decrease the rendering degradation [20]. It mustalso ensure that all the updates that occur during a periodTi will be displayedbefore the end of the next period. The update-servers involved are in charge ofblocking the forward of each received update until all of them can do the same.Introducing this delay presents the drawback of shifting the display of the updatein a synchronization concern. But we will show in the ‘policy enforcement’ sub-section how our protocol is optimized and avoids the implementation of greedyalgorithms for real-time atomic diffusion [21,22].

DVECOM therefore maximizes the predictability of distributed virtual applica-tions. Moreover, it improves their rendering quality with the support of predefinedalternatives mastered by each user. For this purpose, each client retains a priorityfor scheduling the received updates and displaying his own scene according tothe local available resources. To measure the rendering level for each user, wedeveloped a metric, composed of a major metric that measures the rate of totallyprocessed updates, and a minor metric which measures the average degradationof updates processed in a polymorphic way.

In addition to the synchronization guarantee, the objective of defining suchmetrics is to be able to quantify whether the model improves the quality of therendering. This improvement will consist mainly in proving that we maximize themeasurements according to the major metric, and optionally, that we minimizethe measurements according to the minor metric.

To allow each update receiver to master the degradation of its displayed scenewhen necessary, the publisher (Site1 in Fig. 2) should specify in its update mes-sage not only the modified data/behaviour, but also meta-data concerning thequality of service. A DVECOM update message is characterized by three addi-tional attributes. We can enumerate the criticality of the update to the application,its pertinence to the perception of other participants and the degradation degreetolerance. To allow each participant to manage his own display, the update mes-sage should also contain temporal information concerning the polymorphic dura-tion of the update for each polymorphic tolerated representation. These attributes


Site 1Updates

Site 3

Site 2

Criticitypertinence

•••

Accept/schedule/degradestrategies

Figure 2. Emitter and receiver strategies.

provide the update receiver with orthogonal, update QoS, meta-information tohelp him construct a coherent policy for handling his virtual world refreshmentin soft real-time.

This model is developed in such a way that all updates are processed duringthe same period and, in case of sudden overload, only the less critical andimpertinent ones are degraded and may not be displayed. This model thusassociates a meta-data space with the virtual space such that each virtualobject will have an associated meta-object with criteria concerning criticality,pertinence, area of evolution and degradation degree tolerance. For example,an avatar Reporter may be associated with the following meta-object criticalityattribute:

CriticalityD( 10 if nimbus<20

5 if 20<nimbus<401 otherwise

)

In other respects, the end-user on each receiver site (site2 and site3), willspecify his rendering vector representing its retained rendering strategy to toleraterendering degradations.

RVD

Rendering degradation tolerancePriority policy

Degradation policyConcurrency control mode

Our degradation policy consists of what we call sensorial perception (SP),

multi-modal representation (MMR) and structural polymorphism (SPO). SPdegradation policy acts upon the visual/hearing perception (granularity, colourrange, etc.) of the scene, whereas theMMR acts upon the retained media.SPOconcerns objects that are structured as a graph. In cases where less resources areavailable, only leaves under a specific level will be displayed.

The priority policy is intended to support scheduling of calculations ofupdates according to the local constraints, and in such a way that all of themwill be satisfied during the treatment period even if they are degraded. Therewill obviously be slight differences between the various distributed displays


Renderingmeta-data

...... ...

.. ........... .....

...... ...

.. ........... .....

...... ...

.. ........... .....

Virtualobjects

Figure 3. Virtual world associated meta-data.

according to each user’s choice, but this scheduling aims to optimize each localrendering so that the degradation takes place in a least suffering manner. Theadopted priority policy will depend, in order of importance, on the criticality ofthe update, its aura for the local avatar (focus), its pertinence for the wholeapplication, and precedence constraints. Degradation will take place, startingwith the last scheduled updates. In addition to information concerning thevirtual world scene, the previously listed criteria lead the designer of the virtualworld to define an algorithm to classify the updates according to ‘semanticalexpressiveness’. Consider, for example, a game with a reporter investigatingan affair in a virtual world containing other participants, objects, places andlandscapes. The game designer may classify each object according to the potentialsemantic expressiveness of its actions (PSEA) in this decreasing order: reporter,participants, objects, places, and finally landscapes. A basic approach to evaluatethe update semantical expressiveness (USE) of a received update message is

USED0.1 .4PSEAC3UCC2UACUP/,

whereUC is update criticality,UA its aura, andUP its pertinence.With this classification, we may apply one of the following priority policies:

ž Highest Rendering First (HRF). This policy privileges expressiveness impor-tance of the semantical rendering. The updates will then be classified accordingto their USE.ž Least Slack Rendering First (LSRF). This policy takes into account the USE

but also the degradation degree tolerance as specified in the received renderingmeta-data. The degradation degree tolerance helps to calculate the worst USE.We then schedule the updates according to their slack in USE (given by thedifference between the calculated USE and worst USE) in increasing order.


ž Least Rendering Flexibility First (LRFF). This is strongly inspired by theprevious policy but takes into account relative slack rendering. We schedulethe updates according to their flexibility in USE (given by the slack in USEupon USE) in increasing order.

Rendering must be among an ordered scalable list of criteria. In a first approachwe can enumerate information rendering, voice rendering, visual granularityrendering, global scene perception rendering, smooth motion rendering.

The Concurrency Control Mode may be fixed by a site for its local updatetreatment period (Fig. 1) between the serial execution mode and the parallelexecution mode. In the serial mode, updates are ordered in a unique file calculatedsequentially. In the parallel mode, a pool of tasks run to process the queuedupdates according to the characteristics of the local environment (real parallelismwith multiprocessors). Concurrency raises synchronization and precedence issuesto avoid absurd scenes. These issues are solved as in [2], using a mutual exclusionring (MER) to deal with concurrent execution of elementary updates on the samemultithreaded object.

3.4 Synoptic of the model mechanisms

In such a collaborative context, each participant generating and receiving updatesexpects to have his display synchronized with those of other participants. More-over, to auto-adapt to the available resources, a possible degradation treatmentwill take place during the update treatment period and will end with the displayof the virtual scene. The scenario of DVECOM takes place as follows. Eachupdate message will include additional meta-information. Consider, for example,a player jumping up 10 measurement units. Its driving site may emit the follow-ing update message to other participants so that they report this move on theirlocal display.

Update(Object D> Player12,Attribute D> Vertical Position,New Value D> Last Value + 10,Criticality D> 1,Pertinence D> 1,Degradationtolerance D> 0,Calculationdurationlist D> (15));

In this example, Player12 had his vertical position increased by 10 and theupdate is emitted with a maximum criticality and pertinence, no tolerance andunique calculation duration of 15 ms.

The sender emits its updates as one-way messages and does not wait foran acknowledgement, as there are no alternatives in such a strict real-time


upd_handler scheduler worker

RV DB

recieve_upd get_next

upid_queue

Treatment

Storecalculations

flush

Acceptance

Figure 4. Receiver scenario.

context. Hence, the emitter does not suffer from overloads and its performance isimproved. The update-servers are in charge of transmitting this update messageto all the other clients using the protocol described in the ‘DVECOM policyenforcement’ section.

When the local server on the receiver side receives an update, it will queue theupdate according to the characteristics in its meta-data. When it detects an arrivingupdate, the local daemon activates an available update handler (Upd Handler) orcreates a new one, and transfers the update data and meta-data. The daemoncan then receive other updates or process other system tasks. After which, theUpd Handler will create anupdateID, extract meta-data information, and insertthe update data with a header containing theupdateID in a queue. The updatemeta-data is sent to the scheduler, which will schedule theupdateID in a FIFOordered listupid queue, whereas the update data is stored in a hash table. Whenfree, a worker will extract the next waiting update data, according to theupdateIDon top of theupid queueand process it. The calculations are stored inside adatabase and will contribute to the displayed scene at the end of the treatmentperiod.

4. VirtualArch: A platform for DVECOM

4.1 Design objectives

VirtualArch is a proprietary virtual reality platform that implements the mainaspects of DVECOM; it is still being improved. The main goal is to provide alarge network for collaborative work through a virtual world representation.

The implementation of such a network involves many critical constraints. First,the ‘large network’ aspect implies the use of nodes situated far away fromeach other. Consequently, we have to take into account high delay values for


transmissions and include them in our model in order to satisfy the soft real-timecriterion. Second, working in a ‘collaborative way’ over this network impliessimultaneity of display.

However, these constraints do not work well together. Indeed, the lag betweenthe nodes of the network allows neither real-time synchronization nor simul-taneity. That is why VirtualArch builds a network collaborative service throughlogical synchronization, doing its best to deal with soft real-time constraints.That is to say, we built a network based upon logical synchronization principles.Our approach guarantees simultaneity in a temporally optimized way. Dependingon the required QoS, we become able to bind the display refreshment periodwith the activity rate, and the hardware characteristics. Otherwise, for a specifiedperiod, the system will dynamically adjust the rendering according to the user’sprescriptions and the material capabilities. The user will then benefit from anenvironment which allows him to monitor the QoS of the rendering. In the nextsub-section, we will give a global overview of the VirtualArch architecture andthe underlying communication model.

4.2 Overview of the architecture

The design of the VirtualArch architecture were dictated by the need to makenumerous users collaborate in a virtual communication area. The master isconnected to a data server (management data, users’ profiles, etc.) which givesuseful information at each connection to optimize it. A virtual world, createdby an administrator (a privileged user), is managed by an update-server. Themaster may then activate a new update-server, which will accommodate a new

Master IDLE Upd-serversServices

DBconnection

run-time

Brest Upd-Server

Virtual_World_1Rennes Upd-server

Virtual_World_2

Rome Upd-Server

Madrid Upd-Server

Figure 5. VirtualArch Architecture.


copy when necessary. The activation of a new update-server results from the loadbalancing strategy, as each update-server will serve its connected clients and isin charge of delivering messages to them. When a client wants to get inside avirtual world, he asks the manager to connect him to the local update-server.

4.3 DVECOM policy enforcement

The DVECOM model divides update management into two phases–‘updateacceptance’ and ‘update treatment’. In our case, ‘updates acceptance’ consistsof the transportation time through the VABone, whereas ‘updates treatment’ isup to the clients (Fig. 6).

The system built upon the update-server assumes a logical synchronizationreferenced to a logical time. As we will see, the client experiences this logicalsynchronization as a shifted real time. In other words, when a client sends amessage to the system at the timet, all participants will have received the messageafter a round trip duration on the VABone at time

TDT0C2Tc

whereT0 is transfer time duration along the VirtualArch bone, andTc is transfertime duration between a client and its update-server. However, as we stated, trans-portation time between a client and update-server is negligible. Consequently, ina first approximation, we estimate ‘updates acceptance’ toT0 which could bealmost constant if the VirtualArch bone has constant characteristics.

In considering the communication topology, the synchronization problemwe face in the real time environment in DVECOM presents similarities withthose encountered in classical telephony applications. One solution consists in a

VABoneT

Tc Tc

Tc Tc

M1(t)M1(t + T)

Acceptance stage

Treatment stage

M1(t + T) M1(t + T)'

Figure 6. Life cycle of the update messages.


classical network offering connections between clients, which are synchronizedby an atomic clock. We might have designed VirtualArch like this. The update-servers of VirtualArch would then communicate and be synchronized with theNTP in a broadcast way protocol. But this solution requires the setting up of astrict synchronization algorithm for the virtual scenes. We discarded this solutionas it is time-consuming and does not offer predictable duration for refreshmentperiods. Another and more recent approach was developed for private telephony.It is based on an optical fibre loop such that each message (MIC) takes about125ms to process its loop and the communication duration between clients isbounded. The VirtualArch approach is inspired by this last approach.

We then opted for such a VABone where each newly instantiated update-server joins. An update-server is instantiated each time a site joins. Due tothe varying number of update-servers on the VirtualArch bone, the round tripduration will be variable. This duration is transmitted to the clients so that theyadapt their refreshment period or improve their QoS rendering. We will discussin Section 4.4, how our protocol allows us to reduce this period duration whenthe display refreshment cycle decreases under a minimum comfort threshold.

The implementation of the VABone communication protocol is based on logicalring principles and mobile agents (Voyager3.0) in charge of the transportation ofupdate messages between update-servers. Update-servers collect update messageson behalf of their managed clients to forward them to their other assigned clientsand to other update-servers participating in the VR application, each of them beingin charge of forwarding the received update to their assigned client. This approachpresents many advantages in comparison with a classical broadcast solution. First,it offers an easier way to monitor bandwidth use. When each update-server sends amessage to the othern update-servers, a broadcast will involvenŁn�1 messages.Using our bone, such operation requires at the maximumn messages, because anupdate may be inserted inside an already looping agent as the predefined orientedtravelling path stays the same. Moreover, efforts provided to control not only thelogical path, but also the physical path will be useful and valid, as long as thereis no newly inserted update-server. Another advantage of such a bone is thatit is prone to setting up a logical synchronization and consistency mechanisms,necessary for the DVECOM model, according to Lamport clocks. Each update-server has to order the messages it receives according to the stamps concerninglogical time carried by each agent so that we respect the orderliness constraintsas stated by DVECOM.

We might worry that due to different transfer duration between update-servers,one client takes into account an update message even though it is not evenreceived by another client. This problem is removed as each update-server waitsfor the carrying agent to finish its round trip along the VABone before forwardingthe dispatched message to its assigned clients. Each logical time will have, oneach update-server, a corresponding buffer on which to store the correspondingupdates. Atk date, ifn update-servers are connected, bufferk�n is flushed after


its content is forwarded to the assigned clients. This buffer will be affected to thedatekC1. This is not a problem since the clients rely only on global logical timeto process and display their local scenes. Figure 7 gives a representation of anexample with three update-servers where the transfer duration between S1 and S2(represented by the circle arc AB) is the shortest, whereas the transfer durationbetween S2 and S3 (represented by the circle arc BC) is the longest. We deploythis circular representation and represent it from each update-server point of view.

Figure 7 shows that the transformation between the physical time and thelogical time is non-linear and depends on distances between update-servers.

S1

S2

A1

B

A

S3

A3

C A2

S1 point of view t

CA

K = 1

B

K = 2 K = 3

A

S2 point of view t

C

K = 2 K = 3

B

S3 point of view t

C A

K = 2 K = 3

C

A

K = 1

B

B

K = 1

T = 0, k = 0

Update period T

Figure 7. Update-servers’ points of view.


However, for each update period, each update-server will have received all themessages emitted atk�3 and consequently may forward them to its client to beprocessed and displayed in a synchronous way with all other clients.

Let us discuss whether or not the clients experience the physical time the sameway or not. This is almost the case as the refreshment period uses the round-robinduration and takes place at the same logical time (an agent may have only one tickdelay as there is no overstepping). We retained the choice of making the update-servers trigger their assigned clients to refresh their display at each logical timemultiple of the number of update-servers on the ring. We discarded the choice ofmaking the update-servers trigger their assigned clients to refresh their displayat the reception of each new agent carrying new deliverable update messages, asvariations may occur between successive periods due to the variation of transferduration between successive update-servers.

4.4 Refreshment period dynamic enhancement

One drawback of our refreshment period calculation is that it may exceedacceptable values in regard to the QoS expected by the client and the minimumthreshold for comfortable perception. However, we provide a solution to managethis period on-line. In case the period is considered to be too long, we maypartition the logical ring into many smaller rings with about the same round-robin duration as shown in Figure 8. One of the update-servers will play the roleof a central dispatching node.

According to this new architecture and considering the update-server S1 sendsa messageE.1, k/, we assume that all other update-servers get the message inless than 2T. The firstT lap time corresponds to the transport of the messagealong the internal ring to the central server, and the second one corresponds toits diffusion on the external rings. The advantage is that the agent’s round tripduration is divided into as many times that there are loops, but one more loopduration is necessary to inform all the sub-servers (and then their assigned clients)of the occurred update. When generalized, the new round trip period isT0D2T/p,whereT is the old period andp the number of partitions.

4.5 Protocol implementation

As an example of our implementation, Figure 9 gives a synoptic representation ofthe management block which handles the communication between update-serversand the agents travelling along the VirtualArch bone.

The block is composed of four items mapped on different communicatingthreads:

1. The logical timer is synchronized with the clock of the active agent and isincremented at each arrival of a new agent. It drives the ‘PDU filter’ bypointing to the new complete list of PDU.


S6S5

S4

S7

S3

S2

S1

S6

S5

S4

Loop 3: T

E (1, k)

Loop 2: T

Dispatching node

S3

S2S1

S7

Figure 8. VABone logical partitioning.

2. A policy agent buffer guarantees agent scheduling and eliminates any overtak-ing among them. It monitors the activation of agents by the update-server withrespect to the mutual exclusion constraint to guarantee that only one agent isactive at a time.

3. A PDU (Protocol data unit) filter is in charge of scheduling issues. There areas many message buffers as update-servers on the VirtualArch bone. At logical


Ai-2

POLICY

AGENT

BUFFER

Ai-1 Ai

Ai+3

Activeagent

putPDUO

putPDUO

Logical clockNextStep0

NextStep0

PDU FILTER

k–(n–1)

k–n

k

k–1

•••

Client

Client

Client

Client

DIS

MANA

G

ER

Sub-Server

Figure 9. Update-server/VABone exchange block.

time k, each bufferk�i contains the received updates emittedi ticks before.The cursor driven by the logical timer points at the oldest logical timek�nbuffer. This buffer contains all the updates emitted by any client at datek�n,then the updates can be forwarded to the clients assigned to the update-serverbefore the buffer is flushed.

4. A DIS Manager: it handles the I/O PDU communication with the clientsdepending on this update-server.

From a dynamic perspective, each agent runs around the VABone and stopsat each encountered update-server. On each update-server, it may have to be


scheduled and wait its turn. The active agent puts each of its messages on the‘PDU Filter’. Each message is inserted inside the buffer that corresponds to thetime stamp of the message. The agent then gets the new messages from its clientsand from the DIS Manager and stamps them with the current logical time. Thebuffer in the ‘PDU Filter’, which is pointed by the cursor, is then flushed and all itsmessages are sent to clients through the DIS Manager. Finally, the logical time isincreased, the pointer refers to the next buffer, and the coming agent is activated.

4.6 DVECOM virtual worlds

This part of the model concerns the user side. VirtualArch manages virtual objectson line and, according to the user-adopted policy, degrades the QoS. Each userhas his own display and material and hence chooses his own client degradationpolicy based upon the DVECOM model. According to the DVECOM model,each virtual object is handled through three orthogonal perspectives shown in thefollowing: ! Representation/rendering

Virtual �! Behaviour and identificationobject

! Communication

ž Representation/rendering: the representation of the virtual object and itsrenderingž Behaviour and identification: the behaviour of the virtual object in its environ-

mentž Communication: the interface with the network and the communication with

other entities. Strategies such as ‘dead reckoning’ may be used to decreasebandwidth consumption.

We provide a general frame for programming each of these aspects of a virtualobject, specifying two JAVA classes for each object: ‘VirtualObject’ and ‘Ghost’.Class ‘VirtualObject’ contains all information concerning the behaviour and ID,as well as a reference to the representation to the object in the virtual worldto determine its rendering. The ‘Ghost’ class contains the network interface andoffers a frame for special mechanisms such as ‘dead reckoning’ or ‘keep alive’.These pairs are managed through a ‘Virtual Object Manager’. Virtual objectsare identified through a UUID and managed dynamically: clients can create ordestroy their own objects during their session in the world.

4.7 Extended DIS implementation

The choice of DIS was dictated by the mandatory need to have a connectionbetween each client and his update-server. However, there is still a wide choicefor the client side protocol. The protocol should be able to transport any type of


information with types compliant with usual 3D virtual reality objects. It mustsupport mechanisms, such as ‘dead reckoning’ to reduce the bandwidth used bythe application and avoid some calculations. DIS provides such support and isan IEEE standard, offering interoperability with other compliant DVE. However,before considering DIS, we considered a solution based on HLA [12] from DODor the VRTP protocol. These were not adapted to our objectives for the followingreasons: HLA is a platform that combines logical and real-time approaches,as well as virtual object management. We encountered technical difficultiesimplementing DVECOM upon HLA. The VRTP protocol was discarded becausewe migrated from VRML towards Java3D so that we could benefit from the wayobjectsarestructured in Java3D to implement structural polymorphic degradation,as well as some other internal features.

We extended the implementation of a DIS written in Java, freely distributedby the ‘DIS-Java-VRML Working Group’ [23]. Upon these PDU modules, webuilt a multi-thread unicast transmitter/receptor that manages all PDU througha subscription mechanism and developed our rendering auto-adaptation strategymodule.

Figure 10 shows a synoptic overview of our DIS implementation. The wholesystem is contained in the ‘DI S Manager’ object responsible for the emission andreception of the DISPDU. Moreover, it is the only interface for the virtual objectsof the virtual world to access the network: virtual objects have to subscribe tothe ‘DI S Manager’ to receive PDU. There is one subscription per PDU type

Manager« Entity state PDU »

Manager« Collision PDU »

Manager« ... »

Virtualobject

Virtualobject

Virtualobject

Receptor

Rendering auto-adaptation

Shadow buffer

UDP SocketDIS Manager

Transmitter

Subscription

Transmitter

Figure 10. Overview of DIS.


managed by a specific manager. The drawback is that this kind of manager maybe overloaded if there is too much PDU of a certain type.

For performance concerns, the DIS manager is also in charge of the lifecycle of each PDU manager, deactivating those without subscribers. Each updatemessage is intercepted by the ‘rendering auto-adaptation’ module that applies theDVECOM degradation strategy retained by the local user. The ‘Shadow buffer’module avoids charging the socket with external processing and loosing messages,whereas the ‘security’ module is in charge of browser security; it is not currentlyused because VirtualArch is not yet available on the web

Figure 11 shows a display of the old version of VirtualArch with VRML, butwith neither synchronization and consistency policies nor degradation manage-ment. Figure 12 shows the new version in Java 3D of VirtualArch which guar-antees synchronization and consistency and provides a DVECOM test platform.

4.8 Current work and perspectives

DVECOM is designed primarily to achieve logical synchronization of updates toensure simultaneity of display. Its second objective is to improve the renderingof open distributed virtual reality applications by taking into account all updates,and process them totally or in a degraded way depending on resource availability.Integrating all updates before handling them and displaying the new scene in astrictly synchronous way seems mandatory and is the major contribution of thiswork. However, we are about to conduct experimentation and expect the resultsto tell us that the integration of our model not only does not degrade the globalrendering of the application but even improves it.

The next stage will then consist of experimenting with the effect of thisQoS guarantee on the performance of the system. The performance is givenaccording to the major metric and the minor metric. We will evaluate the rendering

Figure 11. VirtualArch VirtualWorld.


Figure 12. DVECOM test platform.

degradation of the application when increasing the load in terms of updates to betreated and displayed. The load may vary in relation to the number of participants,with the behavioral complexity of avatars, the complexity of the virtual world andthe frequency of updates. A first test set will concern the relative influence of thedegradation policy (SP, MMR, SPO, and none) upon the rate of updates totallyprocessed and the average degradation of updates processed in a polymorphicway. We also want to explore whether performance will improve or worsenwhen varying priority policy (HRF, LSRF, LRFF, none). We are optimistic asthe policy specified by the user is compliant with his expectations in terms ofthe increase of the rate of updates totally processed and decrease of the averagedegradation of updates processed in a polymorphic way, which represent thesystem performance.

5. Conclusion

DVE is an emerging research area and, to our best knowledge, most of thestandardization and developments are oriented towards the improvement andspecialization of DVE protocols. We think that these efforts are mandatory butnot sufficient to integrate a QoS from the user’s perspective in an unpredictablecollaborative distributed environment and to guarantee mandatory properties suchas synchronisation and consistency. Most, if not all, of the related work in thearea does not provide any end-user QoS guarantee but focuses on improvingthe rendering through massively integrated algorithms (dead reckoning, area ofinterest, behavioural information, etc.).


We developed a distributed virtual environment collaboration model to offervirtual environment users good quality of service, as it is usually the casefor centralized virtual reality applications. The distributed display simultaneityexpectation of the virtual world and the open nature of collaborative applicationsled us to define and implement a protocol that guarantees consistency of scenesas well as their synchronization. The model also provides a rendering degradationframe for the client side and strategies to be used when resources are lacking. Wedetailed the DVECOM model and its mechanisms and presented the VirtualArchplatform that implements it. We then developed the implemented communicationprotocols. We intend, in the near future, to conduct some experiments and expectto confirm that the integration of synchronization and consistency propertiesinherent to the model as well as the QoS management improve performance ofapplications from a rendering point of view according to the users’ preferences.We hope that a good rendering strategy will improve the semantic expressivenessof the scenes.

Acknowledgements

The work reported here was partially supported by the AMUSEMENT ESPRIT project.We are indebted to Robert Rannou and Antoine Beugnard for the comments and feedbackthey provided. Thanks also go to Jose Louis Diez, Yohann Fourteau, Alberto Diez Canteraand Eric Cousin for the work they did on VirtualArch.

References

1. Z. Choukairet al. 1998. Distribution Architecture Overview and Representation Mechanismsfor the Amusement Project.Technical Report ENST Bretagne.

2. Z. Choukairet al. 1997. Real-time Object Orientated Distributed Processing with COREMOECOOP ’97. InProceedings of Object Orientated Technology, ECOOP ’97, Jyvaskyla, Bosh& Mitchell. New York: Springer-Verlag collection LNCS, vol. 1357.

3. T. Goubier 1998. Architecture d’IHM et Adaptativite. Technical Report, ENST Bretagne.4. Carlssonet al. 1993. Distributed Interactive Virtual Environment Homepage. At URL:

http://www.sics.se/dive/.5. R. C. Waterset al. 1997. Design of the Interactive Sharing Transfer Protocol.Postproc. WET

ICE ’97 IEEE Computer Society Press, Los Alamitos CA.6. C. Greenhalgh 1995. MASSIVE: a Distributed Virtual Reality System Incorporating Spatial

trading. In15th IEEE International Conference on Distributed Computing Systems.7. J. Calvin et al. 1993. The SIMNET virtual world architecture. InProceedings of IEEE

VRAIS’93, 394–400.8. Macedonia 1994. NPSNET: a Network Software Architecture for Large Scale Virtual Envi-

ronments.Presence3(4).9. S. Singhal & M. Zyda 1998. Networked Virtual Environments.ACM press, 01/98, (Draft).

10. Sense8 WorldToWorld Reference Manual, Sense8 Corporation, 1998.11. IEEE DIS—Protocols for Distributed Interactive Systems. 1993.International Standard

ANSI/IEEE Std 1278.12. Defense Modeling and Simulation Office. High Level Architecture. At URL:http://www.dmso.

mil/hla/.13. J. S. Dahmannet al. 1997. The Department of Defense High Level Architecture. InProceedings

of the 1997 Winter Simulation Conference(S. Andradottir, K. J. Healy, D. H. Withers,B. L. Nelson, eds), Association of Computing Machinery, New York, NY, 142–149.


14. Aggregate Level Simulation Protocol. At URL:http://www.dmso.mil/.15. D. Andersonet al. 1996. Open Community overview. At URL:http://www.merl.com/opencom.16. L. Lamportet al. 1978. Time, Clocks and the Ordering of Events in a Distributed System.

Communication of the ACM21(7).17. M. Raynal 1988. Distributed Algorithms and Protocols. New York: John Wiley.18. K. Ramamrithamet al. 1990. Efficient Scheduling Algorithms for Real-Time Multiprocessor

Systems.IEEE Transactions on Parallel and Distributed Systems.19. Z. Choukair 1999. DVECOM: an Auto-Adaptive Model for Collaboration within Distributed

Virtual Reality Applications. InProceedings of the Multi-User Object-Oriented EnvironmentsWorkshop of the ECOOP’99 Conference.

20. Z. Choukairet al. 1994. Contraintes Temps-Reel des Applications Multimedia en Environ-nement Distribue. Technical Report ENST Bretagne.

21. Protocole Temps-R´eel de Gestion de Groupe et de Diffusion Atomique. 1998. DEA Thesis,ENST Bretagne.

22. Mise en Œuvre d’un Protocole Temps-R´eel de Gestion de Groupe avec GrassHopper1998.Mastere Project, ENST Bretagne.

23. A Java free downloadable implementation of DIS At URL:http://www.web3d.org/Working-Groups/vrtp/dis-java-vrml/download.html.

24. VirtualArch: A Distributed Virtual Reality Platform. 1998. Mastere Thesis, ENST Bretagne.25. T. Goubier 1998. Architecture d’IHM et Adaptativite. Technical Report, ENST Bretagne.26. J. L. Diezet al. 1998. VirtualArch: A Distributed Virtual Reality Platform.Technical Report,

ENST Bretagne.

Zied Choukairis a senior lecturer in computer science at ENST Bretagne,a higher national enginneering school of telecommunication in Brittany.His research interests include distributed and telecommunication systems,Real-time and Quality of Service. He has a PhD in computer science fromOrsay University.

Damien Retailleauis a student in Master degree at ENST Bretagne.He worked on the ‘Amusement’ European ESPRIT project with ZiedChoukair.

a qos model for collaboration through distributed virtual environments

Documents