Content for TR 22.847 Word version: 18.2.0
5.3 Immersive VR games
5.3.1 Description
5.3.2 Pre-conditions
5.3.3 Service Flows
5.3.4 Post-conditions
5.3.5 Existing features partly or fully covering the use case functionality
5.3.6 Potential New Requirements needed to support the use case
...
...
5.3 Immersive VR games p. 15
5.3.1 Description p. 15
This use case is about supporting immersive VR games with tactile and multi-modal communication services. VR games have provided a better experience comparing to traditional games. As customers ask for more immersive game experience, haptic information has been taken into account including force and DOF. Traditional VR games provide video and audio information for players to create the real game scenarios. For better immersive VR games, haptic feedback is introduced and which provides the reality of touching things in games as well as the interaction of team players.
To play the VR game, players buy VR games and related equipment like VR glasses, hand shank, analogue steering wheel and haptic gloves, which may be produced by different manufactures. In multi-player VR games, they act as different UEs and need to corporate to complete the mission. On application level, the VR gaming application will be able to distinguish these UEs and share the information with network that these UEs and data flows are grouping under this VR gaming service, and network need to provide corresponding QoS accordingly.
For smooth experience in VR, the motion-to-photon latency should be less than 20ms [7], which indicates that the latency between player do one movement and the corresponding new pixels show in VR sights should be less than 20ms. The uplink dataflow in this loop is motion or haptic information, while the downlink in this loop is the video data. The QoS requirements for these two types of data flows are different, which includes latency requirements. But for the service level, it requires the joint latency consist both uplink and downlink. [5]
5.3.2 Pre-conditions p. 16
Alice and Bob are playing a VR game together. They need to cover each other's back, find weapons and fight with zombies. The VR gaming equipment they wear are all connected to 5G network. The VR game application interacted with 5G network about the UE and dataflow information, and network provides the pre-agreed policy between application and operator on QoS requirements of each kind of modal data flow.
5.3.3 Service Flows p. 16
- Alice and Bob both joined this VR games, and they can see each other's character in the view.
- Alice found two stones on the ground, she picks up both the stones. The delay between the real pick-up action and the virtual hand pick-up video is ignorable.
- Bob has nothing to arm himself. So he asks Alice to throw him a stone.
- Alice heard Bob and throws one of the stone to Bob.
- Bob catches the stone can feel the weight of the stone.
5.3.4 Post-conditions p. 16
Alice and Bob can feel the things in the game as they are in the real world. The experience of this VR games is very realistic and smooth.
5.3.5 Existing features partly or fully covering the use case functionality p. 16
In TS 22.261, there are performance requirements for supporting VR services.
5.3.6 Potential New Requirements needed to support the use case p. 16
[PR 5.3.6-1]
The 5G system shall be able to support tactile and multi-modal communication service with following KPIs.
| Use Cases | Characteristic parameter (KPI) | Influence quantity | Remarks | |||||
|---|---|---|---|---|---|---|---|---|
| Max allowed end-to-end latency | Service bit rate: user-experienced data rate | Reliability | Message size (byte) | # of UEs | UE Speed | Service Area | ||
| Immersive multi-modal VR | [10-20 ms] | 16 kbit/s - 2 Mbit/s
(without haptic compression encoding); 0.8 - 200 kbit/s (with haptic compression encoding) | [99.99%] | 2-8/DoF | - | Stationary or Pedestrian | typically
< 100 km² | Haptic feedback |
| 1-100 Mbit/s | [99.999%] | [1-10000] | - | Stationary or Pedestrian | typically
< 100 km² | Video | ||
| 5-512 kbit/s | [99.9%] | [50-100] | - | Stationary or Pedestrian | typically
< 100 km² | Audio | ||
[PR 5.3.6-2]
The 5G system shall support a mechanism to allow an authorized 3rd party to provide QoS policy for coordination between flows of multiple UEs associated with an application. The policy may contain e.g. the set of UEs and data flows, the expected 5GS QoS handling(s) and associated triggering events, expected coordination assistance provided by 5G system between those multiple flows for different traffic types (e.g., haptic, audio and video).
[PR 5.3.6-3]
The 5G system shall enable means to meet a synchronization threshold for flows of multiple UEs associated with an application based on input received from an authorized 3rd party.
[PR 5.3.6-4]
Due to the separate handling of the multiple media components, synchronization between different media components is critical in order to avoid having a negative impact on the user experience (i.e. viewers detecting lack of synchronization). Applying synchronization thresholds in the 5G system may be helpful in support of immersive multi-modal VR applications when the synchronization threshold between two or more modalities is less than the latency KPI for the application. Typical synchronization thresholds (see [22], [23], [24] and [25]) are summarised in Table 5.3.6-2.
| synchronization threshold (note 1) | ||
|---|---|---|
| audio-tactile | audio delay:
50 ms | tactile delay:
25 ms |
| visual-tactile | visual delay:
15 ms | tactile delay:
50 ms |
|
NOTE 1:
For each media component, "delay" refers to the case where that media component is delayed compared to the other.
|
||
