Content for  TR 22.856  Word version:  19.2.0

The metaverse enables immersive virtual media, 3D avatar and holographic communications for realizing use cases such as interactive gaming, virtualized shared workspaces, and immersive conference rooms for remote collaboration, etc. The goal is to create a virtual world we can work in, interact with, and even escape to. Many mobile metaverse use cases are applicable to indoor and/or localized areas such as home, offices, stadiums, shopping malls, movie theatres, theme parks, hospitals, universities, concert halls, etc. Even though metaverse services go beyond virtual reality media presenting virtual worlds that seem to be distant, the scenarios that this use case focusses on are tied to a single physical location which is mostly indoors and serving a localized area. Such physical locations may prefer non-3GPP (trusted, untrusted or wireline) access. Some mobile metaverse services require more bandwidth and lower latencies which can be challenging to meet. Major improvements to satisfy these requirements of uninterrupted, lag-free, immersive mobile metaverse service experience using non-3GPP access have been made such as:

• incorporation of 1200 MHz of new spectrum in the 6 GHz band with Wi-Fi 6E enabling bigger channel sizes up to 160 MHz
• support up to 1024 QAM with Wi-Fi 6 and 6E and Wi-Fi 7 aiming to support up to 4096 QAM
• doubling maximum channel bandwidth available to each device to 320MHz in the 6GHz band with Wi-Fi 7
• incorporation of High Band Simultaneous (HBS) Multi-Link Operation (MLO) in 802.11be that aggregates two simultaneous 160 MHz channels (four streams) in 5 GHz and 6 GHz bands reducing latency to < 2msec

In case of converged or hybrid network architecture, a single mobile metaverse user can access mobile metaverse services via 5GS using both 3GPP and non-3GPP accesses simultaneously. In such scenario, the metaverse traffic would need to be synchronized as it may be subject to varying latencies when routed over both 3GPP and non-3GPP access. Alternatively, a single mobile metaverse service can be accessed by multiple users across multiple access networks from a network operator.

Two friends and neighbors Mark and Bob want to enjoy their weekend using a Metaverse application for immersive gaming. Mark is using his home residential broadband (non-3GPP) while Bob is using the 3GPP access network from the same network operator. Both the 3GPP and non-3GPP access network are connected to the network operators 5GC.

1. Mark starts the immersive gaming via an authorized 3rd party metaverse application using the network operators broadband access network (non-3GPP access).
2. Bob joins the immersive gaming to play along with Mark via the same authorized 3rd party mobile metaverse services using the same network operator but connecting to the 3GPP access network.
3. Both Mark and Bob experience different network conditions, e.g., bitrate, reliability, latency across the access networks.
4. 5GS exposes varying network condition changes across the two access networks to an authorized 3rd party mobile metaverse service.
5. Based on the real-time network condition information shared by 5GS, the authorized 3rd party mobile metaverse service adjusts the requested QoS for both users for coordinated user experience.
6. Based on the requested QoS from the authorized 3rd party mobile metaverse service, the 5GS performs dynamic policy updates for the users to meet the desired QoS levels for the metaverse traffic and synchronizes the metaverse application data streams for both users using different access networks.

Both Mark and Bob accessing the same mobile metaverse service across different access networks from the same operator can get the same coordinated user experience even when experiencing different network conditions.

The 5G system supports non-3GPP access concurrent with 3GPP access and traffic steering already. The traffic steering aspects are covered in TS 24.193. It is already possible to expose QoS monitoring information to third parties, when using 3GPP access. Dynamic QoS policy updates are also possible in the 5GS in the HPLMN and VPLMN. In clause 6.43.2 of TS 22.261, there are the following requirements: The 5G system shall enable an authorized 3rd party to provide policy(ies) for flows associated with an application. The policy may contain e.g., the set of UEs and data flows, the expected QoS handling and associated triggering events, and other coordination information. The 5G system shall support means to apply 3rd party provided policy(ies) for flows associated with an application. The policy may contain e.g., the set of UEs and data flows, the expected QoS handling and associated triggering events, and other coordination information.

[PR 5.25.6-1] [PR 5.25.6-2]