KR20030064732A - An efficient synchronization mechanism dynamically adapting to the network state for networked virtual environments - Google Patents

Abstract

PURPOSE: A synchronization method in consideration of a variable network state in a networked virtual environment is provided to synchronize an event execution and provide participants with the same view without degrading an interaction performance of a system. CONSTITUTION: A participant 'A' receives a piggyback event storing an event loss rate from other participants 'B' and 'C'. The participant 'A' calculates its event loss rate R(k), an average event loss rate, L(k), and a playout delay P(k+1) to be applied for the next time interval when kth time interval is terminated. When the participant 'A' generates a first event E(A) at a point T1, it sets the playout delay of E(A) as P(k+1) and adds its event loss rate R(k). The participants 'B' and 'C' receive the event the participant 'A' has generated, store it in a buffer until a prearranged playout time point of the event E(A), and execute the event E(A) together with the participant 'A' at a playout time(T1+P(k+1)).

Description

Synchronization method considering variable network status in network virtual environment

The present invention relates to a synchronization method in a network virtual environment, and more particularly, to a synchronization method considering a variable network state for a network virtual environment.

Networked Virtual Environments are systems in which geographically separated participants interact in real time with the same view. Especially in large networks with geographically distributed participants, interaction performance can be improved by replicating virtual environment information at each participant site. In this case, when an event causing a view change occurs at each participant site, the event generated for view synchronization should be transmitted to all participants and executed simultaneously.

However, as the size of the network including participants increases, data transmission and reception rates between participants vary, and traffic on the network varies according to time due to other network services, so that the data transmission time changes over time. This caused a problem of not maintaining the same view among the participants.

To this end, in order to provide the same view to all participants in a network virtual environment, bucket synchronization, dead reckoning and a positive approach by MiMaze have been proposed.

Looking at the above conventional method in more detail, first, in MiMaze's bucket synchronization and dead-reckoning, the time delay between the event sender's event generation and the event execution in the receiver is 'play delay'. Called playout delay ', a fixed playback delay time is set for all transmitted events. By using the set playback delay time, each participant calculates a playback time of the received event and executes the corresponding event at the calculated playback time to synchronize the views of all participants. Each participant considers an event received after the playback point as a lost event and stores the event received before the playback point in the bucket until the playback point. By default, all users use the 'global clock' so that all participants in the same group will run the same event at the same time for events that are not lost. We use dead reckoning as a way to compensate for lost events. The dead reckoning is a method of predicting the current position information of the opponent avatar based on the existing position information and the moving direction information.

Next, the positive approach uses the local lag technique, which is similar to MiMaze's bucket synchronization scheme, to provide the same view. Each participant stores the received event until the local lag time and executes the event at the local lag time. The positive approach also uses a wide field of view to ensure that participants run the event at the same time. The positive approach uses a 'timewarp' technique that examines the relationship between the received event and the current view to handle late arrival events and selectively handles late arrival events. To use the time warping technique, every participant maintains a changed history of the view over a period of time.

In this case, the MiMaze and the Optimalistic approach calculate the playback time that all participants commonly use for synchronization of event execution, and the receivers regard the events received after the playback time as lost events and play back. Events received before the time are stored in the system until the time of playback.

However, in the conventional MiMaze and the positive approach, since the playback delay time is set to a fixed value, there is a problem in that the playback delay time cannot be efficiently changed in accordance with the change of the network state. That is, when network traffic is reduced and transmission delay time is shortened so that most events arrive before playback time, the system resource is additionally used to store the events until playback time, and is performed faster than the predetermined playback time. You will miss the opportunity to improve the system's interaction performance. On the contrary, when the traffic delay on the network increases and the transmission delay time increases, it is difficult to provide a matched view to the participants because many events are delivered and not executed after the playback time.

Accordingly, an object of the present invention is to provide a network virtual environment that enables synchronization of event execution in consideration of variable network traffic conditions without compromising the system's interaction performance to provide the same view to participants in the virtual environment. The present invention provides a synchronization method that considers a variable network condition.

The present invention for achieving the above object is a synchronization method that takes into account the variable network conditions in the network virtual environment, (a) the participants in the virtual environment network calculates the loss rate for the received event at regular intervals, Notifying other participants by including the generated event; (b) extracting, by each participant in the network, event loss rate information of a transmitting participant from a piggyback event transmitted from other participants; (c) calculating an average event loss rate using the loss rate information of the other participants; (d) determining each network participant by comparing the average event loss rate with a predetermined reference value for determining a network traffic condition; and (e) adaptively changing and setting a reproduction delay time to which an event transmitted by the user transmits the event according to the network traffic state.

1 is a conceptual diagram of synchronization processing adaptive to a variable network state according to an embodiment of the present invention;

2 is a block diagram of an ATLAS software module to which a synchronization method is applied according to an embodiment of the present invention;

3 is an event processing flowchart between an event manager and a synchronization manager according to an embodiment of the present invention;

4 is an extended ATLAS event message format defined for implementing a synchronization method according to an embodiment of the present invention;

5 is a network structure diagram of 48 nodes to which a synchronization method according to an embodiment of the present invention is applied;

6 is an exemplary graph of an average transmission delay time for determining a change state of the amount of traffic on a network according to an embodiment of the present invention;

7 is a diagram illustrating an event loss rate graph when a variable playback delay time is applied according to an embodiment of the present invention;

8 is a view illustrating a variable playback delay time graph according to an embodiment of the present invention;

9 illustrates an application execution screen to which a synchronization method is applied according to an embodiment of the present invention.

Hereinafter, with reference to the accompanying drawings will be described in detail the operation of the preferred embodiment according to the present invention.

First, the synchronization method of the present invention considers the relationship between interaction performance and view coherence, network traffic state measurement and overhead, and visual synchronization in order to consider variable network conditions.

Real-time interaction systems, such as network games, must be able to provide the same view between participants and at the same time provide a satisfactory interaction performance. However, these two considerations are in conflict with each other. Setting a short playback delay improves interaction performance, but results in an increase in the number of events delivered after the playback time and, conversely, a long playback delay allows view synchronization between most uses. However, it shows relatively low interaction performance with the consumption of additional resources for storing events.

Therefore, the view synchronization method should be able to adjust the playback delay time to match the network traffic conditions without degrading the interaction performance.

The network traffic state can be measured in various ways. The proposed method uses the event loss rate as a criterion for determining the network traffic state because the event loss rate varies in inverse proportion to the network traffic. The event loss rate can be calculated in a sender-driven and receiver-driven manner. In the 'sender-based scheme', the sender requests event loss rate information from all receivers and receives the event loss rate information in response. That is, in order to obtain event loss rate information, a message exchange corresponding to twice the number of participants in a session is additionally required. Therefore, it does not provide scalability in a large virtual environment.

Therefore, the proposed technique uses a 'recipient-based approach' in which participants voluntarily announce their event loss rate periodically without external requests. The system time of all participants must be synchronized to ensure that the event runs at the same time. Otherwise, events having the same playback time will be executed at different times depending on the participant. Large distributed systems use Network Time Protocol (NTP), GPS receiver techniques, NTP-like algorithms using response time, and 32-bit or even 16-bit timestamps to provide time synchronization.

On the other hand, all participants measure network traffic conditions at regular time intervals to adjust the playback delay time according to the network traffic conditions. The sender uses Equation 1 below to calculate the loss rate R (k) for the event received during the k-th time interval and notify the other participants by including it in the event generated by the sender. This event including loss rate information is called a 'piggyback event'.

N _total (k) = N _success (k) + N _late (k) + N _lost (k), with k = 1, 2, 3 _,. . . ego,

R (0) = 0.

In Equation 1, N _success (k), N _lost (k), and N _late (k) are the number of events received before the play time during the kth time interval, the number of events lost on the network, and the play time. It means the number of events received since the past If it is assumed that the transport layer guarantees reliable transmission, most of the upper values of Equation 1 are occupied by events received after the reproduction time. N _total (k) is the sum of N _success (k), N _lost (k) and N _late (k) measured during the kth time interval. Even assuming reliable transmission at the transport layer, two piggyback events are transmitted in succession because the event loss that can occur on the network cannot be completely excluded.

Each participant extracts event loss rate information of the transmitting participant from the piggyback event delivered from other participants. The loss rate information collected is then used to calculate the average event loss rate. The average event loss rate L (k) calculated by individual receivers at the kth time interval is shown in Equation 2 below.

In Equation 2, S represents a set of session participants, and | S | is a number of participants. R _j (k-1) is the event loss rate reported by participant j in the (k-1) th time interval. At this time, if there is no event loss rate reported from participant j, the event loss rate used in the previous time interval is used. Each participant determines the network traffic status of the session participants by comparing the average event loss rate with the reference value L _c determined in the application. Comparing the two values, if the event loss rate is less than L _c , the network state is determined as a 'lightly loaded state'. This is because the network traffic is low, and the transmission delay time of the event is assumed to be short, which means that it arrives before the playback time. In the opposite case, that is, when the event loss rate is greater than or equal to L _c , the network state is determined as a 'heavily loaded state'. The reason for the high event loss rate is that, contrary to the low load state, it is assumed that there is a lot of network traffic, so that the event transmission delay time is long and thus did not arrive before the time of reproduction.

In this case, if the reference value L _c is set to a small value in the application, in most cases, the network state is determined to be a high load state, and thus the playback delay time is kept long, so that the session consistency is improved but the interaction performance is relatively decreased. Conversely, if you set a large L _c value, in most cases, the network state will be judged as a low load state, and the playback delay time will be kept short, so that the interaction performance will be improved but the view consistency of session participants will be reduced.

Each participant determines the network traffic condition and determines the playback delay time to be applied to the event transmitted by the participants. The playback delay time here is the same concept as in MiMaze. If the network traffic is under high load, increase the reproduction delay time, and if the network traffic is under low load, reduce the reproduction delay time. The increase and decrease of the play delay time differs from the decrease and increase of the play delay time similarly to the Additive Increase Multiplicative Decrease (AIMD) method used in TCP. The calculation of the reproduction delay time P (k + 1) to be applied by the sender A in the (k + 1) th time interval is shown in Equation 3 below.

,

Where k = 1,2,3 ...

In this case, the L _c value may vary depending on the characteristics of the application because the L _c value may highlight a different property of consistency and interaction performance that are in conflict with each other. and Is a constant value and is determined to be more effective through experimentation. The playback delay time is limited by the maximum value (P _max ) and minimum value (P _min ) determined by the application. P, if the value of (k + 1) is greater than P _max, P (k + 1), if replaced by P _max and P (k + 1) is less than P _min instead of P (k + 1) using a P _min do.

1 is a diagram illustrating a concept of a synchronization process considering a variable network state in a network according to an exemplary embodiment of the present invention.

Referring to FIG. 1, an example of interaction between participants A, B, and C is shown. Participant A receives a piggyback event that stores the event loss rate from other participants B and C. Participant A calculates his event loss rate, R (k), average event loss rate, L (k), and the playback delay time P (k + 1) to be applied during the next time interval. When participant A generates the first event E (A) at time T ₁ , set the playback delay time of E (A) to P (k + 1) and attach his event loss rate R (k). Participants B and C receive the event generated by Participant A and store it in the buffer until the scheduled playback time of Event E (A), and at the same time (T ₁ + P (k + 1)), Participant A and Event E (A ).

2 illustrates a software module configuration of the network virtual environment framework ATLAS to which the above synchronization method is applied, and FIG. 3 illustrates an internal flowchart of the synchronization method library.

First, referring to FIG. 2, ATLAS is a scalable network framework for a virtual environment, including a session manager 200, a region manager 202, an event manager 204, It consists of a Communication Manager 206 and a Synchronization Manager 208 module. The communication manager 206 creates, deletes, and performs a communication channel between participants, and supports a client-server, peer-peer, or peer-server structure according to the system structure. The event manager 204 receives a network message from the communication manager 206 and converts it into an ATLAS event message and delivers it to a higher level or receives an ATLAS event message from a higher level and converts it into a network message and delivers it to the communication manager 206.

Next, referring to FIG. 3, the event manager init () 300 is a method for initializing the event manager 204, and the synchronization manager init () 302 is a method for initializing the synchronization manager 208. to be. Thread update_playout () 304 is a thread that periodically calculates a play delay time to update the play delay time, and thread schedule_event () 306 is a thread that periodically calls pop_buffer () 308.

The synchronization manager pop_buffer () 308 is called by the schedule_event () 306 and delivers the event, which is the playback time, among the events stored in the event buffer 210 to the application. The synchronization manager compare_time () 310 takes the playback time point and the current time point, compares the two values, returns 0 if the playback point is earlier than the current point of time, and returns 1 if the playback point is later, indicating whether the event was received before the playback point. Method that tells whether or not When the synchronization manager process_event () 312 processes the event received from the synchronization manager 208, the compare_time () 310 is used to process the lost event when the playback time of the corresponding event is earlier than the current time. Invoke insert_buffer () (314).

The synchronization manager insert_buffer () 314 is a method for storing the received event in the event buffer 210, and the synchronization manager find_position () 316 is a method for returning an empty index in the event buffer 210. The event manager receive_event () 318 is a method for receiving events from the network.

In an embodiment of the present invention, a synchronization manager 208 is added to ATLAS to support the proposed scheme. The synchronization manager 208 receives the message from the event manager 204, stores the message in the event buffer 210, and delivers the message to a higher level, that is, the ATLAS application layer, when the playback time is reached.

When the event manager 204 is initialized, it creates a synchronization manager 208, and the generated synchronization manager 208 generates an event stored in the event buffer 210 and a thread (update_playout ()) 304 for updating the playback delay time. A thread (schedule_event ()) 306 to give a to an application is operated. The event manager 204 converts the network message into an ATLAS event message and forwards it to the synchronization manager 208. The synchronization manager 208 checks the extended ATLAS event header to determine whether the corresponding event is a piggyback event, and extracts and stores an event loss rate in the case of a piggyback event. The playback time of the corresponding event is calculated using the playback delay time and the event occurrence time included in the event header. If the current time is after the playback time, the event is discarded. Otherwise, the event is stored in the event buffer 210.

The ATLAS event message is composed of a fixed header part and a variable data part of 81 bytes, and FIG. 4 shows a format of an ATLAS event message. The Bytes of Event field indicates the number of bytes in the ATLAS event message, and the Event Type and Event ID fields are used to identify the ATLAS event included in the message. The Handler field represents an event handler for processing different types of events. RF, Playout Delay, Drop Rate, and Generation Time fields are added for the event synchronization method proposed in the present invention. The RF field is used as a flag to indicate whether the event is a piggyback event or not. For piggyback events, set the RF field to 1 and record the event loss rate as measured by the event sender in the Drop Rate field. The event sender records the play delay time of the event in the Playout Delay field and records the time when the event occurs in the Generation Time field so that the receiver can calculate the scheduled play time of the event when the receiver receives the event. Sender contains the address of the sender, and Destination contains the address of the receiver.

5 illustrates a network topology to which a synchronization scheme according to an embodiment of the present invention is applied.

In the present invention, we tested whether the proposed synchronization scheme adjusts the playback delay time to adapt to network conditions using ns-2, a network simulator. A network topology with 48 nodes was created using GT-ITM, and the participant module implementing the synchronization scheme at each end node was set to operate. Ten sessions lasting 300 seconds were performed 10 times, and alpha_1 was set to 0.2, alpha_2 was set to 0.5, and the reference event loss rate L _c was set to 5 (%). The maximum value of the playback delay time was set to 200 ms and the minimum value to 110 ms. The initial playback delay time was set to 150 ms, which is the same as the fixed playback delay time used by MiMaze. Nodes 0, 1, and 2 intermittently ran UDP sessions to make the network traffic state variable. All participant modules generated events at random time intervals, but maintained an average of 10 events per second. It was assumed that the size of the event buffer was infinite.

Increasing traffic on the network increases the time required to deliver traffic from nodes on the network, increasing the transmission delay of the event, and decreasing the transmission delay of the event when the traffic decreases. Based on this observation, in order to show the change of network traffic generated in this experiment, the transmission delay time of reception events observed in all participants was periodically averaged to obtain the result as shown in FIG. 6. In FIG. 6, the horizontal axis represents the experiment time, and the unit is second, the vertical axis represents the transmission delay time, and the unit is ms. As the traffic on the network increases, the time it takes for other participants to receive the message delivered while the session participants interact with each other increases the average transmission delay time in FIG. 6.

FIG. 7 is a graph showing average values of average event loss rates of all participants for a case of applying a fixed play delay time and a case of applying a variable play delay time. The event loss rate is as defined in Equation 2 above. The playback delay time determined by the participants using the average event loss rate is shown in FIG. 8. In case of using the proposed technique, the number of lost events increases as the transmission delay time increases about 30 seconds, resulting in an event loss rate of about 5% or more. By increasing the time, the event loss rate is kept below 5% after 45 seconds. However, with fixed playback latency, event loss rates of about 5% or more persist between 30 and 75 seconds. Even in the period from 130 seconds to 155 seconds, the traffic suddenly increases, resulting in more than 10% of event loss. However, the proposed technique also reduces the event loss rate after 155 seconds by adjusting the playback delay time to recognize the increase in network traffic. Accordingly, as shown in FIG. 8, the reproduction delay time also changes according to a change pattern in which traffic increases or decreases.

In particular, when compared to the technique using fixed refresh delay, the network uses a play delay longer than the fixed play delay in the 50 to 80 second period when the network is in a high load state, thereby reducing the event loss rate and the network being in a low load state. In the 100 second to 130 second intervals, and the 160 second to 200 second intervals, a playback delay shorter than the fixed playback delay time is used, thereby improving interaction performance.

An example of applying the present invention to CyRun, a three-dimensional cyber marathon game developed by Gaseapea Co., Ltd. in order to evaluate the effectiveness of the present invention is illustrated. CyRun is a 3D cyber marathon system based on client / server architecture. Participants' rankings are important throughout the race in a marathon, so even in a cyber marathon system, synchronization between participants should be done efficiently. The overall structure of the cyber marathon system consists of ATLAS relay server, ATLAS center server and ATLAS treadmill. The relay server and the center server are connected to the ATLAS server and manage the users who participate in the cyber marathon and the participants in each center through the Internet, and the ATLAS-Treadmill program is installed on the treadmill equipment so that each participant can view the 3D cyber marathon competition. To provide. FIG. 9 is an execution screen of CyRun, and shows a result of measuring average playback delay time (left) and event loss rate (right) at the bottom right of the screen in the form of a graph. As shown in the graph on the screen, the experiment was performed on 100Mbps LAN at the time of the experiment, so that no increase in transmission delay time occurred. Due to the low transmission delay, no event loss occurs, and as a result, the playback delay time starts from the initial playback delay and continues to decrease.

Meanwhile, in the above description of the present invention, specific embodiments have been described, but various modifications may be made without departing from the scope of the present invention. Therefore, the scope of the invention should be determined by the claims rather than by the described embodiments.

As described above, the present invention implements a synchronization method for dynamically determining a reproduction delay time by reflecting network traffic conditions. As a result, when the transmission delay is low due to low network traffic, a short playback delay is applied to increase the interaction performance, and when the traffic is heavy, the playback delay can be increased to reduce the event loss rate without harming the interaction performance. There is an advantage to that. As a result, the synchronization method can provide participants with a consistent view as compared to the conventional techniques while maintaining a heavily loaded network, and improve interaction performance in a lightly loaded network. There is an advantage to this.

Claims (7)

Synchronization method that considers variable network status in network virtual environment, (a) a participant in the virtual environment network calculates a loss rate for the received event at regular time intervals, and includes the same in the event generated by the participant to notify other participants; (b) each participant in the network extracting event loss rate information of a transmitting participant from a piggyback event transmitted from other participants; (c) calculating an average event loss rate using the loss rate information of the other participants; (d) determining each network participant by comparing the average event loss rate with a predetermined reference value for determining network traffic condition; (e) adaptively changing and setting a playback delay time to which an event transmitted by the user transmits according to the network traffic state; Synchronization method comprising a. The method of claim 1, In step (a), the loss ratio R (k) is calculated as in the following equation. [Equation] R (k): Loss rate for events received by itself during the kth time interval N _late (k): Number of events received after playback time passed during kth time interval N _lost (k): Number of events lost on network during kth time interval N _total (k): Sum of the number of events received before the playback time during the kth time interval, the number of events lost on the network, and the number of events received after the playback time. The method of claim 1, In the step (b), the piggyback event, characterized in that the transmission in two to prevent the event loss. The method of claim 1, In the step (c), the average event loss rate L (k), it is calculated as in the following equation. [Equation] L (k): Average event loss rate calculated by individual receivers at the end of the kth time interval j: participant S: set of session participants R _j (k-1): Event loss rate reported by participant j in the (k-1) th time interval The method of claim 1, In step (d), (d1) if the average event loss rate is less than a reference value, determining the traffic state of the network as a low load state; (d2) determining the traffic state of the network as a high load state if the average event loss rate is greater than a reference value as a result of the comparison; Synchronization method comprising a. The method of claim 1, In step (e), the reproduction delay time P (k + 1) is calculated as in the following equation. [Equation] P (k + 1): The playback delay time the sender will apply in the (k + 1) th time interval. P (k): The playback delay time applied by the sender in the kth time interval : A parameter that determines the degree of reduction of the playback delay time at low load. : A parameter that determines the degree of increase of the playback delay time under high load conditions. L _C : Permissible event loss rate determined by the application The method of claim 1, In step (e), (e1) increasing the reproduction delay time to which an event is applied when the network traffic state is a low load state; (e2) reducing the play delay time to which an event is applied when the network traffic state is a high load state, Synchronization method comprising a.