Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TR 22.842  Word version:  17.2.0

Top   Top   Up   Prev   Next
1…   5…   5.3…   5.5…   6…

 

5  Use casesp. 11

5.1  Interactive Service Supportingp. 11

5.1.1  Descriptionp. 11

Interactive service is a kind of service that the data is exchanged between users who are interested in the same NCIS session, like interactive gaming, data sharing between variable kinds of terminals, e.g. mobile phone, robots, etc. The NCIS session here means all UEs in the session can share the same background, update the same information of the service, and finish the session at the same time. Those UEs in the same NCIS session are grouped together as one NCIS group. The interactive service here is real-time and requires high throughput and low latency. The users joining the NCIS session can be in local area or far away from each other and can be from either same MNO or different MNOs. This use case describes the scenario where a group of UEs supporting NCIS service can discover each other, start the NCIS session and exchange the data.
Up

5.1.2  Pre-conditionp. 11

An MNO offers communication between UEs by controlling the transmission resource of the UEs and UE A/B/C/D/E supporting NCIS service would like to start a NCIS session together. Here UE A/B/C are in-proximity with each other, while UE D/E are in-proximity with each other; UE A/B/C/D/E can be in proximity with each or in non-proximity with each other, and the scenario is indicated in following figures. UE A/B/C/D/E can belong to the same MNO or belong to different MNO.
Copy of original 3GPP image for 3GPP TS 22.842, Fig. 5.1.2-1: UEs are in proximity with each other
Figure 5.1.2-1: UEs are in proximity with each other
(⇒ copy of original 3GPP image)
Up
Copy of original 3GPP image for 3GPP TS 22.842, Fig. 5.1.2-2: Some UE(s) are in non-proximity with each other
Up

5.1.3  Service Flowsp. 11

UE A/B/C/D/E experiences a situation which triggers UE A/B/C/D/E to initiate NCIS service.
UE A/B/C/D/E join the same NCIS session, no matter if they are in-proximity or in non-proximity.
UE A/B/C/D/E join the same NCIS session, no matter whether they belong to the same MNO or not.
UE A/B/C/D/E could discover the group when they are in-proximity and the NCIS group could be identified by other UEs in the same group when they are in-proximity
UE A/B/C/D/E could be invited by other UE(s) or join the group no matter whether all UEs belong to the same MNO or not.
UE A/B/C/D/E download(s) the required information for the interactive service from network respectively.
UE A/B/C in proximity or UE D/E in proximity can exchange the real-time data information between the UEs within local area with satisfied data rate, no matter whether all UEs belong to the same MNO or not.
UE A/B/C/D/E who are in proximity and belong to the same group can be charged accordingly.
UE A/B/C/D/E who are in proximity and belong to the same group can try to reduce the power consumption with satisfied service requirements.
UE A/B/C/D/E who are in proximity and belong to the same group can be required to execute lawful interception if it is needed.
Up

5.1.4  Post-conditionp. 12

Under network control, NCIS users in the same group are able to exchange real-time data with each other, update their status and be charged accordingly, no matter whether all users belong to the same MNO or not.

5.1.5  Gap analysisp. 12

In the above clause 5.1.1, the basic concept of NCIS service and corresponding NCIS session and NCIS group is described.
In [4], all connections should be fully network control for eMBB services, while for ProSe or V2X service, some pre-configuration could be provided for UEs especially when UEs are out of the coverage of network.
And for NCIS service, the requirement of fully network control e.g. for authentication or resource allocation is needed, therefore, when UE is out of the network coverage, no resource should be available on either the ProSe Communication path (direct) or the 5GC path, however, when UE coming back to the network coverage, it would be possible to re-join the NCIS group and resume the NCIS session as soon as possible. Besides, the control for NCIS service could be from same RAT or different RAT.
In [14], supporting the the ProSe Communication path (direct) by unicast, multicast or broadcast is studied, and a ProSe Group Communications is mentioned generally in [15]. For NCIS service, the broadcast may not be so efficient from UE power consumption or resource utilization perspective, since not all UEs in proximity to each other are interested and need to receive the information from other UEs, therefore, the unicast and multicast need to be supported based on the control from the same RAT or different RAT.
As defined in the previous section for NCIS session and NCIS group, one group of UE will share the same information e.g. background, update, etc. together for the dedicated NCIS session, therefore, the information needs to be communicated between them. The UE could discover the NCIS group, join the NCIS group or be invited to the NCIS group based on their interest, during this procedure, some service related information, e.g. user numbers in the group, QoS requirements, etc, should be known by the network. And during this procedure, the normal service should not be impacted. In [14], the discovery procedure is defined only between ProSe UEs without considering whether they are interested in the same service content or not, and in [16], the addition of UE in the private group and removal of UE from the private group are defined, however, for NCIS service, firstly, the addition and removal is based on UE's interest on the service, for example, at a certain point of time, a UE may want to join NCIS session 1 while at a different point of time, a UE may want to join NCIS session 2; secondly, UE could determine to initiate the discovery, join or invitation on its own based on network configurations.
In [15], the discovery and communication requirements between ProSe UEs from same MNO or different MNOs are defined, however, the discovery of the group based on the group information provided outside of the 3GPP is not defined, and the corresponding group should be able to be identified. Besides, the authorization on resource allocation especially under network control for different MNOs case is not discussed.
The NCIS group server needs to be able to deliver the group communication data using unicast/multicast delivery depending on the support of MBMS in 3GPP network. According to group communication enabler in [18], the group application server determines to trigger the group communication service towards 3GPP network based on the registration information from its group users in the application layer. However, to fulfil the objective of this study to achieve network controlled for the interactive service, it would require service exposure from the 3GPP network. With required assistant information from the 3GPP network, the NCIS group server can provide more real-time and better decision on NCIS group management.
Further, due to inhomogeneous deployment of the MBMS cells, the UE needs to switch communication between unicast and multicast when it moves in/out of the service areas [18]. However, to ensure the service continuity, it would be beneficial to explore efficient mechanism in network-controlled manner.
The existing features:
  • When UEs are moving among cells during Group Communication, service continuity shall be supported [18].
  • When UEs are serving by the 3GPP network, the power consumption shall be minimized with satisfied service requirements [15].
  • When UEs are serving by the 3GPP network, the service continuity shall be guaranteed with at least minimum service requirements [15].
  • When UEs are serving by the 3GPP network, the lawful interception shall be supported [15].
Up

5.1.6  Potential requirementsp. 13

[PR.5.1-001]
The 3GPP network shall be able to have full control about the connection of NCIS session based on the control from either EPC or 5GC;
[PR.5.1-002]
The 3GPP system shall be able to support NCIS services via the ProSe Communication path/the 5GC path by unicast;
[PR.5.1-003]
The 3GPP system shall be able to support NCIS services via the ProSe Communication path/the 5GC path by multicast;
[PR.5.1-004]
The 3GPP system shall support a mechanism to allow NCIS user to discover, join and to be invited to any NCIS group based on user interest in the NCIS session or NCIS service;
[PR.5.1-005]
The 3GPP system shall be able to support UEs belonging to same MNO or different MNOs joining in the same NCIS group after authentication and communicate with each other with allocated resources.
[PR.5.1-006]
The 5G system shall be able to support collection of charging information based on a NCIS group that the UE accesses.
Up

5.2  VR Based Interactive Servicep. 13

5.2.1  Descriptionp. 13

In NR, VR service could be one of the killer applications, and the gaming based on VR would be the most attractive interactive service. The goal of this use case is to provide VR based interactive service between UEs in proximity.
In section 5.11 in [2], the virtual presence has already been described as an interactive service for high data rate zones (e.g. Office Environment). There are three use cases described as follows:
Use Case 1:
One people could communicate with other people from other places with some special devices, e.g. Virtual Presence glasses;
Use Case 2:
One people could communicate with his classmates and teachers via virtual presence glasses when he could not attend the classes because of e.g. surgery.
Use Case 3:
One person could use his lightweight VR headset (where the VR headset is physically lighter and less computationally capable than a full VR headset) to watch the VR videos locally stored in his smartphone, or the VR videos transmitted from cloud through his smartphone.
And the service requirements for the typical interactive service, i.e. VR service, are listed as follows based on [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].
However, in the research report [5], it was mentioned high-mobility automotive content streaming would require strong network uniformity with increased capacity to handle growing bitrate requirements, and this also applies for interactive service. More advanced video formats, like interactive 6 degrees of freedom (6DoF) video, could also be used for interactive service and will be most demanding in terms of bandwidth, with up to 10X the bitrate required for 4K video.
And the usefulness of VR is heavily dependent on three network components: high throughput, low latency and a uniform experience. Within all these requirements, the maximum data rate of VR service would reach at least 1 Gbps; and if the latency based on Motion-to-Photon (MTP) is less than 15ms (including processing delay in device), the latency would be imperceptible to all users.
And further more in [6], the user throughput of VR service was mentioned as 7Gbps with a latency of 10ms, and with advanced compression techniques the network throughput requirement can be approximately 5.2 Gbps [7][8].
Besides, in [9], it was also mentioned that currently stringent latency requirements are of utmost importance for providing a pleasant immersive experience especially for VR based interactive service. The human eye needs to perceive accurate and smooth movements with low motion-to-photon (MTP) latency, which is the lapse between a movement (e.g., head rotation) and a frame's pixels corresponding to the new field of views shown to the eyes. And the E2E latency is about 15ms including the device processing delay. And it was also mentioned that a maximum packet error rate (PER) of 10-5 correlates with the VR tracking message signalling that has to be delivered with ultra-high reliability to ensure smooth VR service.
As mentioned above, different companies have different views on how large data rate should be supported.
And based on the study, improved VR performance could be obtained with the following conditions:
  • Terminal: 120 degree with 16K screen resolution
  • Content: Full view resolution as 23040*11520 with 3D DoF and 120fps
And for the interactive service like interactive gaming, at least 2 UEs will join the interactive game. For the maximum number, different interactive game may have different numbers, e.g. 10 or even 100. Here, to be realistic, we think 10 could be appropriate number to start.
For use case 3, depending on the XR architectures, the data rate of media stream between smartphone and VR headset are around 0.1Gbps ~ 10Gbps based on the SA4 LS (S4-190972). The following three different primary cases are considered:
  1. Around 100 Mbpit/s: Certain amount of processing and decoding is included in the glass.
  2. Around 1 Gbps: In this case, only lightweight and low-latency compression (e.g. intra only) may be used to provide sufficiently high quality (4k or even 8k at sufficiently high frame rates above 60 fps) and sufficiently low latency (immersive limits of less than 20ms for motion to photon) for such applications. It is still expected that some processing is needed in the glass.
  3. Around 10 Gbps or even more: A full "USB-C like" wireless connection, providing functionalities that are only provided by cable, possibly uncompressed formats such as 8k. The processing requirements in the glass may be minimal.
For any of the cases above, latencies should be kept low for each processing step including delivery, to make sure that the cumulative delay for all the processing steps (including tracking, pose delivery, viewport rendering, encoding, delivery, decoding and display) is within the immersive motion-to-photon latency upper limit of 20ms.
Besides, from network perspective, the VR based interactive service can be satisfied by both the ProSe Communication path (direct) and the 5GC path, and network can determine whether the ProSe Communication path (direct) or 5GC path should be used based on the interactive service requirements. For example, when UE is in the coverage and the service requirements e.g. data rate can be satisfied, the network can use the 5GC path; while UE is in the coverage but service requirements e.g. data rate cannot be satisfied, the network can use the ProSe Communication path (direct).
Up

5.2.2  Pre-conditionsp. 15

The UE supporting interactive service i.e. VR service exchange the typical interactive service data, and the quality of service needs to be guaranteed.

5.2.3  Service Flowsp. 15

UE A/B/C/D would like to start an interactive service, e.g. VR gaming;
UE A/B/C/D in proximity could be close to the base station or far away from the gNBs;
UE A/B/C/D download(s) the required information for the interactive service from network;
UE A/B/C/D in proximity can exchange the real-time interactive data with each other with satisfied experienced data rate via the ProSe Communication path (direct) or via gNB based on network decision;
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.
Up

5.2.4  Post-conditionsp. 15

The interactive service data could be exchanged between UEs and the service requirements could be guaranteed with network control.

5.2.5  Gap Analysesp. 15

Firstly, in [4], the maximum experienced data rate for VR is 1Gbps, which may be lower than high definition VR service.
Secondly, there is no definition about the number of users joining the VR based interactive service.
Thirdly, in [4], the 1Gbps can only be satisfied via the 5GC path, while the interactive VR service can also happen when UE is in the coverage but the requirements cannot be satisfied, in this case, the network needs to determine whether to use the ProSe Communication path (direct) to satisfy the requirements.
Up

5.2.6  Potential Requirementsp. 15

[P.R.5.2-001]
The 5G system shall support VR based interactive service with [8K] resolution and 120fps content.
[P.R.5.2-002]
The 5G system shall be able to support interactive service between at least 2 UEs and among at most [10] UEs.
[P.R.5.2-003]
The 5G system shall be able to determine exchanging interactive service data via the ProSe Communication path (direct) or via the 5GC path in order to guarantee the user experienced data rate and latency.
[P.R.5.2-008]
The 5G system shall support packets transmission between UEs with 0.1-[10] Gbps data rates for the ProSe Communication path (direct), and the end-to-end latency plus processing delay should satisfy the upper limit of motion-to-photon latency (including tracking, pose delivery, viewport rendering, encoding, delivery, decoding and display), i.e., 20ms.
Up

Up   Top   ToC