Content for  TR 22.842  Word version:  17.2.0

The use device for mobile gaming can be a normal smart phone or AR/VR devices. When playing the game, the sensors within the devices produce some data which is needed to perform rendering computing. Following the description in S4-190260 (Permanent Document for FS_XR5G as attached to S4-190261), different rendering scenarios exist. Rendering may be done exclusively on the device (see clause 5.9.3.1). This model follows also the architecture of VR Streaming as specified in TS 26.118. In other instantiations, all or part of the rendering is done in the network/cloud. For cloud rending use case (equivalent to S4-190260, clause 5.9.3.2 Network Rendering: Viewport rendering in Edge), the user device doesn't perform rendering computing, instead, it sends the sensor data in uplink direction to the cloud side in a real time manner. When the cloud side receives the sensor data, it performs rendering computing and produces the multimedia data and then sends back to the user devices for display. The following Figure 5.3.1-1 shows the general idea of this use case. Please note that this Figure is only used to illustrate how cloud rendering for mobile games works and the major impacts to 3GPP is whether and how 5GS can be used to transport the uplink sensor information and downlink rendered multimedia data to display.

In order to reduce the latency, edge computing can be enabled for the cloud side. To achieve this purpose, NEF may be enhanced to support network capability exposure to the cloud render server as an AF. VR services are considered as an important application in 5G network. Based on the feasibility study [2] and normative work [4], the service requirements are specified as follows in [4]: To support VR environments with low motion-to-photon capabilities, the 5G system shall support:

• motion-to-photon latency in the range of 7-15ms while maintaining the required user data rate of [1Gbps] and
• motion-to-sound delay of [<20ms].

Regarding to the performance indicators like required data rate and latency, different research institutes and companies have different observations since the assumed parameters are different. In [9], the motivations and technical trends for low latency and ultra-reliable VR services which is quite aligned with this use case. In [5], it demonstrates that for some VR use cases like remote machinery control, the latency needs to be lower than 5ms and depending on the frame rate and DoF (degree of freedom) the required bandwidth can be up to 1Gbps. In [10], one given example shows that the resolution of Oculus Rift CV1 is 1080 × 1200 (1,296,000) per eye driven at 90Hz resulting in an uncompressed data rate of about 5.3 Gbps. In [11], it can be observed that the required data rate is dependent in the resolution, frame rate, DoF (Degree of Freedom) and other factors like the codec and compressing algorithms. Compared with existing gaming services, cloud gaming is extremely delay and bandwidth sensitive because there is no buffer for the video frame and any non-real time delivery or packet loss will cause discontinuous frame or bad gaming experience. For example, current mainstream FPS (First Person Shooter) game requires 60 frames per second, which means frame interval is 16.67ms. Taking out the delay for rendering and encoding/decoding processing, the round-trip time (RTT) delay over 5GS should be less than 5ms. Another example is that for MOBA (Multiplayer Online Battle Arena) game which requires 20ms RTT which is more relaxed than FPS game. For all these games which need rendering in cloud side, guaranteed data rate very critical as there is no buffering or retransmission mechanism for real time rendering which is quite different from streaming games. The means peak or average bandwidth is not sufficient for cloud gaming but guaranteed data rate is needed. In [12], one analysis shows that for streaming services 0.1% packet loss will downgrade MOS by 10%. Considering the short latency and lack of need for buffering, the impact of packet loss is more serious than streaming services. Thus, packet loss rate should be ultra-low which means reliability similar to URLLC with is in general align with the analysis in [9]. In [17], it has illustrated that 1% packet loss would impact user experience and patience for cloud gaming. In [13], the forecast from GSMA and China Academy of Information and Communications Technology (CAICT) show that above 60 FPS and 8K video would be popular for AR/VR. There is another way to specify the requirement without requiring data rate which is from FPS and resolution perspective. For cloud game with VR rendering, to fulfil the foresee user expectations for cloud gaming, the frame rate higher than 60 FPS and 8K resolution should be supported. Given the frame rate and/or resolution, since there are many factors which may affect the required bandwidth, depending on the data rate which can be provided by the 5G system, the 3rd party i.e. cloud server for VR rendering can configure the other parameters like codec algorithms to fit the bandwidth. To address some of the challenges listed above (extremely low-latency requirements, all rendering done in the network), also so-called split rendering architectures are defined in equivalent to S4-190260. Two instantiations of split rendering are copied below   In Figure 5.3.1-2, the viewport is pre-dominantly rendered in the XR edge server, but the device is able to do time-warping to address local correction.

• VR graphics workload split into rendering workload on powerful XR server and TW on device
• Low motion-to-photon latency preserved via on device Asynchronous Time Warping (ATW)

More details are expected to be developed in the context of the FS_XR5G study item.   Figure 5.3.1-3 below shows the 3D-video Streaming approach.

• Split rendering framework based on generating textures and meshes (geometry) for even XR graphics quality
• Seamless support for enhanced XR rendering optimizations (e.g. foveated rendering, asynchronous space warp)

More details are expected to be developed in the context of the FS_XR5G study item.

The following are pre-conditions for this use case:

• The end user device has a subscription for 5GS if it is a cellular capable device.
• If the end user device is not a cellular capable device, it can connect to cloud/edge server via 5GS with a CPE.
• AR/VR cloud/edge server is implemented as edge computing entity.
• 5GS support network capability exposure to the cloud rendering server as an AF (Application Function).

The following describes the sequence of events:

1. The game player turns on the use device and starts to play the game. The app of the mobile game has hand-shake with the server side so that end-to-end transportation path of the game related data are established.
2. The cloud rendering server may request 5GC to steer the traffics towards local cloud rendering server in local data network.
3. The sensor data are produced within the use device and these data are sent to the cloud render server via 5GS in uplink direction.
4. The cloud rendering server perform rendering and produce multimedia or pre-rendered graphics data.
5. Multimedia or pre-rendered graphics data are sent to the use device in downlink direction.
6. The end use device performs multimedia decoding and potentially post-rendering and then displays the audio-visual viewport.
7. Start with step 2 until the games exit.

When game is over, the use device releases the transport connection with the cloud side.

Transportation of uplink sensor data and downlink multimedia/pre-rendered data has stringent requirements on packet delay and bandwidth. When AR/VR devices are more and more powerful, they may produce more and more bandwidth demanding and delay critical traffic.

For cloud gaming, guaranteed data rate is needed and meanwhile the frame rate can be higher than 60 FPS and 8K resolution should be supported. Due to the complex and various factors which may affect the data rate, the requirement can also be defined from FPS and resolution perspective and this means the other parameters like DoF and degree and codec mechanisms can be selected to fit the guaranteed data rate. In addition to the above aspect, round-trip-time (RTT) over 5G system i.e. in two directions between the cloud server and the gaming device which is related to the frame rate, should be less than a certain value so that since the device and cloud side can perform rendering and codec processing within the frame interval. When frame rate increases, the time needed for rendering and codec processing would be less. In addition to the above two KPIs, for this use case, the packet loss rate, as explained above, in order to minimize the impact of user experiences for AR/VR games, the uplink sensor data e.g. VR/AR tracking messages that has to be delivered with ultra-high reliability to ensure smooth VR service [9], therefore, similar performance as URLLC is expected i.e. packet loss rate should be lower than 10E-4 for uplink sensor data. For downlink rendered multimedia data, since packet loss rate 1% would leads to degraded user experience for cloud gaming thus 10E-3 is expected to achieve immersive user experiences. These three KPIs should all be met together for cloud gaming with VR rendering. For cloud gaming, uplink and downlink traffic over 5G system are asymmetric. The bandwidth and latency requirement of uplink traffic needs to be met with URLLC treatment i.e. 5G system may provide redundant resources to achiever the required reliability and low packet loss rate. And for downlink traffic, either URLLC or eMBB treatment may be needed. This means for one cloud gaming service, uplink and downlink traffic may require different treatment i.e. uplink by URLLC treatment and downlink by eMBB or URLLC treatment. Cloud rendering gaming is an on demand interactive service, which would present very different traffics pattern from time to time depending on the progress of the game. Currently, in 5GS, the Cloud Rendering Server as an AF can provision external parameters and steer traffics with required QoS to the 5GC for user plane traffic routings. However, When QoS changes either in core network or radio access network, this may cause congestion in cloud rendering server. Therefore, it is beneficial for the cloud/edge rendering server to have information of QoS predication, so that it can adjust the rendering parameters to the potential QoS changes. The cloud rendering gaming would require heavy computing and resources, there needs load balancing for the computing and resources among cloud rendering servers. For example, different UEs or group of UEs can be served by different cloud/edge rendering servers. In this case, it requires a mechanism in 3GPP system to support the selection of a cluster of serving cloud rendering server for a UE or a group of UEs.

[P.R.5.3-001] [P.R.5.3-002] [P.R.5.3-003] [P.R.5.3-004] [P.R.5.3-005] [P.R.5.3-006]

In [2], the higher UE speed scenarios have been described. In the description, road vehicle, high speed train and aircrafts (e.g. UAV) are specially mentioned as the key use cases, and it was mentioned they will demand enhanced connectivity for in-vehicle/on-board entertainment, accessing the internet, enhanced navigation through instant and real-time information, autonomous driving, safety and vehicle diagnostics, while entertainment is a key driver for the increasing need for mobile broadband capacity. The requirements for VR service and interactive conversation have been defined also in [4] as follows: To support VR environments with low motion-to-photon capabilities, the 5G system shall support:

• motion-to-photon latency in the range of 7-15ms while maintaining the required user data rate of [1Gbps] and
• motion-to-sound delay of [<20ms].

Therefore, it would be beneficial to support interactive service between UEs on-board of the vehicle, high speed train or the aircraft via the ProSe Communication path (direct) when they are in proximity considering the absolute speed is up to 500km/h.

The users exchanging the interactive service data, like VR gaming, are all on-board of the vehicle, high speed train, or the aircraft. The network can be deployed inside the road vehicle, high speed train, or UAVs.

UE A/B/C/D are in a high speed transportation, e.g. vehicles, high speed train or aircraft; UE A/B/C/D would like to start an interactive service, e.g. interactive gaming; UE A/B/C/D discover each other and join the service together; UE A/B/C/D download the required background information for the interactive service from the network; UE A/B/C/D exchange real-time interactive data with each other with satisfied QoS requirements for the services via the ProSe Communication path (direct); UE A/B/C/D could update the status with the network; UE A/B/C/D can stop the interactive service and inform the network.

The interactive service data could be exchanged between UEs when UEs are on-board of the vehicle, high speed train, or the aircraft and the service requirements needs to be guaranteed with network control.

As mentioned in description part, the use case for this section is to support interactive service between UEs on-board of the vehicle, high speed train or even the aircraft via the ProSe Communication path (direct) or the 5GC path when they are in proximity considering the absolute speed is up to 500km/h. In [4], the experienced data rate for high-speed train and high-speed vehicle have been defined respectively as 50Mbps DL and 25Mbps UL. Therefore, there is no data rate requirement defined for interactive service e.g. VR based gaming for high speed scenario. Considering [1Gbps] defined in [4] for VR service, it is quite challenging to support high quality interactive service (e.g. VR based gaming) in high speed scenario. It would be possible to support this interactive service via the ProSe Communication path (direct) or via the 5GC path with the new requirements defined.

[P.R.5.4-001] [P.R.5.4-002]