Digital representation based methods for enabling metaverse application session management

Abstract

Digital representation based methods, and associated apparatuses and systems, for enabling metaverse application session management are described herein. In one aspect, a method can include receiving, from a Metaverse application client or server, a request to create or update a MAS policy comprising multi-modal digital representation information of the MAS; determining one or more network communication flow requirements of the MAS based on MAS digital representations policy information of the request; creating or updating one or more network communication flows for the MAS based on the determined network communication flow requirements of the digital representations; and detecting a MAS synchronization or measurement threshold condition has been met and performing one or more MAS synchronization or measurement actions.

Description

DIGITAL REPRESENTATION BASED METHODS FOR ENABLING META VERSE APPLICATION SESSION MANAGEMENTCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims benefit of U.S. Provisional Application No. 63 / 613,277 titled “Digital Representation Based Methods for Enabling Metaverse Application Session Management" filed December 21, 2023. the contents of which are hereby incorporated by reference in its entirety for any and all purposes.BACKGROUND

[0002] A Metaverse application session (MAS) is an instance of a Metaverse application comprising a complex sy stem of multiple users, devices, servers, and networks all interacting with one another to realize a Metaverse experience. For a MAS to properly function and provide users with a high quality of experience, network traffic flows exchanged between users, devices, and application servers must be properly synchronized. Otherwise, the quality of experience for users participating in a MAS will be non-optimal.

[0003] An example of a MAS is shown in Figure 1 in which two users participate in a virtual interactive boxing match. The users are equipped with VR devices (e.g., VR headsets, headphones, haptics headgear, haptics gloves, and haptics vests) each having individual traffic flows. Using these VR devices, the users are able to throw7and land punches as well as feel the punches from their opponent. The MAS allow s the users to participate in the interactive boxing match even when they are located at remote locations from one another (e.g., different cities, states or even countries). A critical enabler of this MAS is an advanced network capable of providing low latency and synchronized exchange of multi-modal traffic flows between the users, devices, and application servers. This is required to provide the users with an immersive experience in which no observable lag or glitches occur in their interactive boxing match.

[0004] Digital representations play a major role in enabling a Metaverse application session (MAS). Digital representations provide a means for an entity7residing in the real-world (e.g., users, devices, objects, rooms, venues, systems) to be digitized and modeled as software entities in a MAS. For example, in the aforementioned Metaverse boxing use case, digital representations for the different users and VR devices (VR headset, headphones, haptics boxing helmet, gloves and vest) are required. These digital representations may be definedand structured in a hierarchical manner as show n in Figure 2 such that a digital representation may be comprised of one or more other digital representations. For example, a digital representation of the user (i.e.. the boxer's avatar) may be comprised of digital representations of the user's VR devices. Likewise, a digital representation of the boxing match may comprise digital representations of the two boxers and their surrounding environments.

[0005] To date, 3GPP has defined several features to assist in supporting multi-modal traffic flows for use cases such as Metaverse and XR applications. One example is the PDU set feature which enhances a 3GPP core network QoS flow with the capability to group bursts of application traffic together such that they are all sent over the same QoS flow within a given time window; This feature is useful for grouping bursts of multi-modal traffic (e.g., video, audio, and haptics) together with one another such that these bursts arrive at their destinations in a synchronized fashion. This enables a user to see, hear and feel the multimodal application traffic in a coordinated manner w hich translates to a high-fidelity user experience. This feature how ever is limited to traffic exchanges between UEs and the UPF of the 3GPP core network. Hence this feature is not able to provide end-to-end QoS management between Metaverse application clients and Metaverse application servers.

[0006] Another feature recently defined by 3GPP is the SEALDD service [1], The SEALDD service supports a SEALDD flow which complements the QoS flow management capabilities of the 3GPP core network. This SEALDD flow feature addresses the limitation that 3GPP core network QoS flows only provide QoS management between a UE and UPF in the 3GPP core network. A SEALDD flow can provide end-to-end QoS management between an application client and an application server.

[0007] As shown in Figure 3, the SEALDD architecture currently supports managing a single / independent SEALDD flow between a SEALDD client and SEALDD server. Via a SEALDD flow, the SEALDD client and server manage the end-to-end flow of application data between an application client hosted on a UE and an application server hosted on a network server.

[0008] Management of a Metaverse application session (MAS) comprising multiple users, client devices, application servers, and network communication traffic flows (e.g., multimodal SEALDD flows and SEALDD flows and QoS flows) is not a trivial task and can introduce significant cost, complexity and overhead to Metaverse applications.

[0009] For example, an interactive boxing MAS is shown in Figure 5. This MAS requires a complex distributed system comprising multiple users, devices, servers, digital representations, and traffic flows.

[0010] A key contributor to the complexity of deploying a MAS of this nature is managing the traffic flow s which interconnect the digital representations of users and devices participating in the MAS. For example, each user and device will ty pically be modeled using a one or more digital representations. The digital representations serve as the traffic flow endpoints. These digital representation traffic flow endpoints enable the exchange of application media / data between the users and devices participating in the MAS. These traffic flows are dependent on the Metaverse application use case and the relationships and dependencies between the different digital representations of users and devices participating in a MAS. Hence, without awareness of the digital representations participating in the use case and their required traffic flow s, deploying a MAS can be challenging. This can be especially challenging when users and devices do not have a pre-established relationships and levels of trust and aw areness with one another, or when the number of users and devices scales up in the system, or when changes to users or devices participating in a MAS occur.

[0011] A MAS will typically involve client-side digital representations along with corresponding server-side digital representations. These client-side and server-side digital representation pairs require network communication to keep them synchronized via the exchange of application media / data. Each digital representation may have different types of media / data associated with it (e.g., video, audio, haptics) and therefore different application traffic flow' requirements (e g., bandwidth, latency jitter). Likewise, given a MAS typically will involve multiple users interactively communicating with one another via a set of VR type devices, there may be synchronization dependencies across the traffic flows associated with the different digital representations.

[0012] To further compound the complexity, individual digital representations may themselves have multi-modal traffic flow requirements. For example, a VR headset may support multiple types of features (e.g., video, positioning, ambient light sensors, etc ). As a result its digital representation may require multiple elements as shown in Figure 6. These elements may have different QoS requirements due to the different types of media supported by these elements. For example, a video feed element may have different QoS and KPI requirements (e.g., bandwidth, latency, jitter) than an ambient light sensor element with thesame digital representation. Hence when exchanging different elements of the same digital representation between the client-side and server-side, different network communication flows may be required to provide differentiated application traffic handling and prioritization. This requirement of differentiated traffic handling and prioritization at the granularity of individual elements of a digital representation can also increase the complexity of deploying a MAS.

[0013] Currently, there is a lack of awareness within communication networks of the different digital representations participating in a MAS along with the network communication requirements of these digital representations. Today, awareness of digital representations and their communication requirements currently resides in the domain of the Metaverse applications. Providing methods to share information with communication network functions and services regarding the set of digital representations participating in a MAS and their corresponding network communication requirements, can provide a means for allowing communication networks to assist with managing MAS network communication flows more intelligently and efficiently on behalf of Metaverse applications. This can offload Metaverse applications of the burden of having to manage network communication flows themselves in an over-the-top manner. This can in turn enable better performance and more immersive Metaverse applications as well as less complex and costly deployment of Metaverse applications.SUMMARY

[0014] Digital representation based methods, and associated apparatuses and systems, for enabling metaverse application session management are described herein. The disclosure herein can define functionality to assist and offload Metaverse applications from the burden of having to manage the network communication flows associated with a Metaverse application session (MAS). A key aspect of the proposed functionality involves the awareness and use of digital representations in enabling the management of network communication flows associated with a MAS.

[0015] The defined functionality is well-suited for deployment in an application enablement service associated with a communication network. For example, this proposed functionality may be deployed in an application enablement service such as but not limited to the Metaverse Application Enabler (MetaApp) being studied in 3GPP SA6 Rel-19.

[0016] In particular, the disclosure provided herein can define MAS management functionality capable of supporting one or more of the following features: receiving a request from an Metaverse application client or server to create or update a MAS policy. In some cases, the MAS policy comprises a description of each digital representation associated with the MAS. In some cases, the description of each digital representation comprises one or more of: an identifier for the digital representation, and an identifier, data type, sample size, directionality, and QoS info for each individual information element (IE) of the digital representation.

[0017] In some cases, the MAS policy further comprises multi-modal digital representation synchronization policies defining different IES of one or more digital representations having multi-modal synchronization dependencies with one another. In some cases, a multi-modal digital representation synchronization policy comprises one or more of: identifiers of the different digital representation IEs having multi-modal synchronization dependencies with one another, the type of multi-modal synchronization dependencies, multi-modal synchronization actions to perform, and a multi-modal synchronization precision,

[0018] In some cases, the MAS policy further comprises multi-modal MAS synchronization policies defining digital representations associated with the MAS having synchronization dependencies with one another. In some cases, a multi-modal MAS synchronization policy comprises one or more of: identifiers of the digital representations having multi-modal synchronization dependencies with one another, the type of multi-modal synchronization dependencies, multi-modal synchronization actions to perform, and a multimodal synchronization precision.

[0019] The method may further include determining the network communication flow requirements of the MAS based on the MAS policy information in the request. In some cases, the determination is based on parsing the MAS policy information to determine the digital representations associated with the MAS, their individual network communication requirements, the multi-modal communication requirements, and any multi-modal synchronization requirements.

[0020] The method may further include creating or updating one or more network communication flows for the MAS based on the determined network communication flow requirements of the MAS. In some cases, creating or updating one or more network communication flows comprises sending one or more requests to one or more functions orsendees in the system to assist with the creation or update of the network communication flows. In some cases, the one or more requests comprises a network communication flow policy based on IES from the MAS policy or IES derived from the MAS policy lEs. In some cases, creating or updating of the one or more network communication flows considers any multi-modal synchronization requirements based on the MAS policy.

[0021] The method may further include monitoring the network communication flows associated with the MAS to determine if the network communication flow requirements of the MAS continue to be met. In some cases, the monitoring comprises collecting and analyzing MAS measurements based on MAS measurement policies. In some cases, the MAS measurement policies comprise one or more of: a type of MAS measurement to perform, a MAS measurement trigger condition to start or end MAS measurement collection, a MAS measurement schedule defining when to collect MAS measurements, a MAS measurement threshold defining a trigger condition to perform a MAS measurement action, a MAS measurement action to perform if / wdien a MAS measurement threshold is detected. In some cases, the monitoring may comprise interacting w ith one or more functions or services in the system to assist with collecting measurements regarding the network communication flows.

[0022] The method may further include detecting a MAS measurement threshold condition has been met and performing one or more MAS measurement actions based on the detected MAS measurement threshold. In some cases, the one or more MAS measurement actions may comprise one or more of re-configuring one or more network communication flow s associated with the MAS or sending one or more notifications to one or more entities in the system.

[0023] The method may further include receiving a MAS query or discovery request comprising one or more identifiers for MAS policy IEs or MAS state IEs and / or filter criteria comprising conditions for the retrieval or discovery of MAS policy IEs or MAS state IEs.

[0024] The method may further include sending a MAS query or discovery response comprising one or more identifiers for MAS policy IEs or MAS state IEs matching the identifiers and / or filter specified in the query' or discovery request.

[0025] The method may further include receiving a request to tear-down network communication flows associated with a MAS. wherein the request may comprise a MAS ID.

[0026] The method may further include processing the MAS tear-down request by performing one or more MAS tear-do n operations that may involve tearing down one ormore network communication flows associated with the MAS. In some cases, tearing down the one or more netw ork communication flows associated with the MAS may comprise sending one or more requests to a function or service in the system to instruct the function or service to tear down the network communication flows associated with the MAS.

[0027] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to features that solve any or all disadvantages noted in any part of this disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0028] FIG. 1 depicts an interactive boxing Metaverse application session.

[0029] FIG. 2 depicts an interactive boxing digital representation hierarchy example.

[0030] FIG. 3 depicts aa SEALDD flow.

[0031] FIG. 4 depicts a multi-modal SEALDD flow'.

[0032] FIG. 5 depicts an interactive boxing MAS use case.

[0033] FIG. 6 depicts digital twin multi-modal flows.

[0034] FIG. 7 depicts a MAS system architecture.

[0035] FIG. 8 depicts a MAS management procedure.

[0036] FIG. 9 depicts an example GUI.

[0037] FIG. 10A depicts an example communications system in which the methods and apparatuses described and claimed herein may be an aspect of;

[0038] FIG. 10B depicts a block diagram of an example apparatus or device configured for wireless communications;

[0039] FIG. 10C depicts a system diagram of an example radio access netw ork (RAN) and core netw ork;

[0040] FIG. 10D depicts a system diagram of another example RAN and core network;

[0041] FIG. 10E depicts a system diagram of another example RAN and core network;

[0042] FIG. 10F depicts a block diagram of an example computing system; and

[0043] FIG. 10G depicts a block diagram of another example communications sy stem.DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTSMAS System Architecture

[0044] To assist Metaverse applications with the management of network communication flows required by Metaverse application sessions (MAS), this invention defines MAS management functionality. The MAS management functionality assists and offloads Metaverse applications from the burden of having to configure and manage MAS network communication flows (e.g., SEALDD flows and / or QoS flows) in an over-the-top manner. This MAS management functionality may be realized as a feature of a Metaverse Application Enabler (MetaApp) client or server as shown in Figure 7. The MetaApp client or server may interface to Metaverse application clients and servers to receive MAS policies which the MetaApp client or server may use to establish and manage network communication flows required by the MAS. The MetaApp client or server may also interface to other functions and services in the system (e.g., SEALDD and / or functions in a 3GPP core network) to assist with establishing and managing network communication flows (e.g., SEALDD flows and / or 3GPP core network QoS flows) for the MAS.

[0045] Note, although the embodiments defined throughout this invention describe MAS management functionality supported by a MetaApp client and server, this is not meant to limit or exclude other possible embodiments. One skilled in the art will recognize that other embodiments may also be possible. For example, the proposed MAS management functionality7may be realized as a feature of an 3GPP XR application enabler or SEALDD service. Other embodiments of the MAS management functionality may also be possible. For example, the MAS management functionality may be deployed as a capability in a cloud service platform.MAS Policies

[0046] A MetaApp client or server may interface with and receive MAS policies from Metaverse application clients or servers (or other management entities in the system). These policies may comprise information regarding digital representations associated with each user and device participating in the MAS. Based on digital representation information within a MAS policy, the MetaApp client or server may establish and manage coordinated set(s) of network communication flows needed to exchange application traffic between the client-side and server-side of each digital representation pair as shown in Figure 7. These network communication flows may be managed by the MetaApp client or server such that they meet network communication requirements (e.g., required E2E latency jitter, and bandwidth) forindividual digital representations, as well as any network communication requirements of the MAS which span across multiple digital representations. This is important since a MAS will ty pically require multi-modal traffic flows involving multiple users interacting with one another via multiple devices in real-time. Hence multiple traffic flows associated with different digital representations will need to be synchronized with one another such that the update of the different digital representations occurs in a synchronized fashion.

[0047] For example, in the interactive boxing use case shown in Figure 7, traffic flows associated with the digital representations for the different users (i.e.. boxers) and their associated devices (i.e., VR headsets, headphones, haptics gloves, helmet and vest) must be synchronized such that the users can experience an immersive interactive boxing experience. When a user throws a punch or receives a punch to or from their opponent, several application traffic flows from the digital representations of the different users and their respective devices may need to be synchronized such that they are sent across the communication netw ork to / from the Metaverse application clients and servers in a coordinated fashion. This is required to allow each of the client-side and server-side digital representations for each participating user and device to be updated in a synchronized fashion. For example, the video, audio, and haptics content flowing to / from the digital representations of the VR headsets, headphones, haptics gloves, helmet and vest of each boxer must be tightly synchronized on both the client-side and server-side such that the boxers can exchange virtual punches in near real-time w ith one another w ithout any lag or synchronization issues being noticeable.

[0048] MAS policies may comprise information elements (IES) such as but not limited to the IEs defined in Table 1. The MAS policy comprise IEs describing the digital representations applicable to the MAS. These digital representation IEs may provide metadata to a MetaApp client or server describing the communication requirements for the digital representations, e.g., differentiated QoS requirements of different elements defined in a digital representation. Based on this information, a MetaApp client or server may use the MAS policy IEs to determine the network communication requirements for each digital representation. In addition, the MetaApp client or server may also determine any synchronization dependencies spanning across different digital representations and / or different IEs within the same digital representation. Based on this determination, the MetaApp client or server may assist the Metaverse application clients and servers withestablishing and managing network communication flows for the MAS on their behalf. MAS policies may also comprise other ty pes of lEs. For example, MAS measurement policies may be defined comprising lEs used by a MetaApp client or server to collect measurements associated with the MAS.

[0049] MAS policies may be stored and maintained by a single entity7in the system (e.g., on a MetaApp server) or distributed across multiple entities in the system (e.g., MetaApp client(s) and server(s)). If MAS policies are stored and maintained in a distributed manner, the MetaApp client(s) and server(s) may perform synchronization operations to keep the MAS policies synchronized. In addition, if MAS policies are stored and maintained in a distributed manner, then some entities may only require storing a subset of the lEs (e.g., a MetaApp client may only require storing a subset of the MAS policy lEs while the MetaApp server may store the complete set of MAS policy lEs).Table 1- MAS Policy lEsMAS State

[0050] In addition to assisting with the establishment of network communication flows associated with a MAS, a MetaApp client or server may also assist in the management of the flows once they have been established. The MetaApp client or server may monitor the health and performance of network communication flows associated with a MAS. Based on MAS policies (e.g., digital representation, measurement, synchronization, subscription), the MetaApp client or server may collect, generate, and / or store MAS state information (e.g.,measurements related to the network communication flows associated with the MAS). Based on this state information, the MetaApp client or server may perform management operations (e.g., re-configuration of network communication flows associated with the MAS if / when needed).

[0051] To establish network communication flows associated with a MAS and monitor and manage these flows, a MetaApp client or server may also interface with other functions, services, and / or application enablers in the system to assist it with MAS management operations. For example. MetaApp clients or servers may interface to SEALDD clients or servers and / or functions in a 3GPP network (e.g., NEF) to establish and monitor SEALDD and QoS flows associated with a MAS.

[0052] MetaApp clients and serv ers may collect, store, and maintain MAS state information. For example, a MetaApp client or server may store state information for each network communication flow (e.g., SEALDD flow and / or QoS flow) which it establishes for a given MAS digital representation. The MAS state information may comprise information elements (IES) such as but not limited to the IES defined in Table 2. A MetaApp client or server may use the MAS state IEs to monitor and track the state of MAS network communication flows and whether the communication requirements of the MAS are being met. Based on MAS state IEs, a MetaApp client or server may perform MAS management operations such as re-configuring network communication flows if / when needed and interacting with Metaverse applications clients and servers and / or other entities in the system to share MAS state information.

[0053] MAS state IEs may be stored and maintained by a single entity in the system (e.g., on a MetaApp server) or distributed across multiple entities in the system (e.g., MetaApp client(s) and server(s)). If MAS state IEs are stored and maintained in a distributed manner, MetaApp client(s) and server(s) may perform synchronization operations to keep the MAS state IEs synchronized. In addition, if MAS state IEs are stored and maintained in a distributed manner, then some entities may only require storing a subset of MAS state IEs (e.g., a MetaApp client may only require storing a subset of the MAS state IEs while the MetaApp server may store the complete set of MAS state IEs).Table 2 - MAS State Information ElementsMAS Procedure

[0054] Figure 8 shows a proposed MAS management procedure in which Metaverse application clients and servers interact with MetaApp clients and servers. The procedure shows Metaverse application clients and servers configuring MAS policies onto a MetaApp client and server. The MAS policies are then used by the MetaApp client and server to configure network communication flows for the MAS and to perform MAS related measurements and management operations.

[0055] Note, one skilled-in-art will recognize that the steps defined in this procedure may occur in a different order than the order shown, or that some steps may be excluded, or additional steps not shown may be added.

[0056] Step 1: The Metaverse application client(s) and / or Metaverse application server(s) establish a MAS and create associated digital representations required to support the MAS. For example, digital representations for each user and device participating in the MAS are created and hosted by the Metaverse application client and server. This may involve the Metaverse application client(s) and / or Metaverse application server(s) exchanging one or more messages with each other to coordinate the establishment of the MAS and creation of the associated digital representations. For example, a Metaverse application server may be triggered to establish a MAS after receiving request(s) from Metaverse application client(s) which provide the Metaverse application server with information regarding the Metaverse application clients, users, and devices interested in participating in the MAS.

[0057] Step 2: The Metaverse application client(s) and / or server(s) may configure MAS management policies onto the MetaApp client(s) and / or MetaApp server(s). In one embodiment, a Metaverse application client or server may send one or more MAS policy create / update requests to the MetaApp client(s) and / or server(s). The request may comprise MAS policy IES such as but not limited to those defined in Table 1. In another embodiment, the MAS policies may be provisioned onto a MetaApp client or server by other means (not shown in the figure). For example, a management application in the system may send a MAS policy request to a MetaApp client or server. Alternatively, the metaverse application client or server may provide some basic or high-level policies, and the MetaApp client or server may determine or derive additional policies based on that. For example, the metaverse application client or server may provide information of the digital representations of the MAS and requirements, then the MetaApp client / server may determine what measurements are needed to support the MAS and derive the measurement policies.

[0058] Step 3: Upon receiving a MAS policy request, the MetaApp client or server may determine if the request is for creating a new MAS policy or updating an existing MAS policy. This determination may be made by the MetaApp client or server checking if the request comprises a ‘MAS ID’ IE. If present, the MetaApp client or server may query its local storage and / or the other functions or sendees in the system to determine if a MAS policy matching the MAS ID already exists. If found, the MetaApp client or server may process the request by updating existing MAS policy IEs. Otherwise, the MetaApp client or server may create and store a new MAS policy. When creating a new MAS policy, the MetaApp client or server may assign a MAS ID to the policy (if one is not provided in the request). Alternatively, a MAS ID for a new MAS policy may be assigned by another entity in the system (e.g., Metaverse application client or server, SEALDD client or server). If a MAS policy request is received by a MetaApp client, it may forward the request to the MetaApp server and vice versa.

[0059] When creating or updating a MAS policy, the MetaApp server may examine the ‘MAS digital representations’ IE to determine the requirements for network communication flows (e.g.. SEALDD flows or QoS flows) needed to support the MAS digital representations. This examination may involve the MetaApp client or server performing one or more of the following operations for each specified MAS digital representation in the MAS policy.

[0060] The MetaApp server may check if any existing network communication flows have already been established for any of the MAS digital representations specified in the MAS policy. To perform this check, the MetaApp server may check one or more of the identifiers defined in Table 1 such as the following to determine whether any network communication flows associated with these identifiers have already been established and are associated with the MAS:

[0061] ‘MAS ID’

[0062] ‘Metaverse application ID’

[0063] MetaApp server ID(s)’

[0064] ‘MetaApp client ID(s)’

[0065] ‘Digital representations > User ID',

[0066] ‘Digital representations > Server-side endpoint ID’,

[0067] ‘Digital representations > Client-side endpoint ID’,

[0068] ‘Digital representations > Hosting UE ID’,

[0069] ‘Digital representations > IES > IE ID’

[0070] If a network communication flow for the corresponding MAS digital representation has not yet been established, then the MetaApp client or server may perform additional operations to determine the network communication flow requirements and configuration needed to support the MAS digital representation.

[0071] To perform this check, the MetaApp client or server may check one or more of the following IEs within the MAS policy which are defined in Table 1:

[0072] Digital Representations > QoS info > required E2E bandwidth’,

[0073] ‘Digital Representations > QoS info > required E2E latency,

[0074] ‘Digital Representations > QoS info > required E2E jitter,

[0075] ‘Digital Representations > QoS info > required E2E reliability,

[0076] ‘Digital Representations > QoS info > required E2E schedule,

[0077] ‘Digital Representations > IEs > IE data type’,

[0078] ‘Digital Representations > IEs > IE sample size’,

[0079] ‘Digital Representations > IEs > IE directionality',

[0080] ‘Digital Representations > IEs > IE mirroring’,

[0081] ‘Digital Representations > IEs > IE QoS info > required E2E bandwidth’,

[0082] ‘Digital Representations > IEs > IE QoS info > required E2E latency,

[0083] ‘Digital Representations > IES > IE QoS info > required E2E jitter,

[0084] ‘Digital Representations > IEs > IE QoS info > required E2E reliability,

[0085] ‘Digital Representations > IEs > IE QoS info > required E2E schedule,

[0086] The MetaApp client or server may also check if is the MAS policy is configured with synchronization policies which specify any multi-modal synchronization that is required between digital representations of the MAS and / or betw een different IEs of the digital representations. To perform this check, the MetaApp client or server may check one or more of the following IEs within the MAS policy which are defined in Table 1:

[0087] 'Digital Representations > Multi-modal digital representation synchronization policies’,

[0088] ‘Digital Representations > Multi-modal digital representation synchronization policies > Applicable IEs’.

[0089] 'Digital Representations > Multi-modal digital representation synchronization policies > Type of Multi-modal digital representation synchronization’,

[0090] ‘Digital Representations > Multi-modal digital representation synchronization policies > Multi-modal digital representation synchronization actions’,

[0091] 'Digital Representations > Multi-modal digital representation synchronization policies > Multi-modal digital representation synchronization precision’,

[0092] ‘Multi-modal MAS synchronization policies >’,

[0093] ‘Multi-modal MAS synchronization policies > Applicable digital representations’,

[0094] ‘Multi-modal MAS synchronization policies > Type of multi-modal MAS synchronization’,

[0095] ‘ Multi-modal MAS synchronization policies > Multi-modal MAS synchronization actions’,

[0096] ‘Multi-modal MAS synchronization policies > Multi-modal MAS synchronization precision’,

[0097] Step 4: After determining the netw ork communication flow requirements for the MAS, the MetaApp server may create or update one or more netw ork communication flow s required by the MAS. This may involve the MetaApp server sending one or more requests to other functions or services in the system such as a 3GPP defined SEALDD server or 3GPP defined NEF. The request(s) may comprise one or more MAS IEs defined in Table 1. In addition, a MetaApp server may derive additional IEs which it may then include in theserequest(s). For example, a MetaApp server may analyze flow requirements from the MAS digital representations and determine to assign multiple digital representations to use a single network communication flow or multiple network communication flows which have a multimodal relationship (e.g., a multi-modal SEALDD flow, a QoS flow with a PDU set burst configurations). This determination may be based on analyzing the multi-modal synchronization policies pertaining to individual digital representation of the MAS and / or multi-modal synchronization policies pertaining to multiple digital representations of the MAS. . After making this determination, the MetaApp server may configure and include one or more network communication flow policies in the request(s) that it sends to the other functions or services in the system. These network communication flow policies may comprise IES that are used by the other function or service to determine how to configure the network communication flows for the MAS and which digital representations of the MAS get assigned to 1) their own individual network communication flows 2) to the same network communication flow, or 3) to multiple network communication flows having a multi-modal relationship.

[0098] In addition to providing network communication flow policies which comprise IEs used to determine which network communication flows MAS digital representations are assigned to, a MetaApp server may include additional IEs in these network communication flow policies. For example, a MetaApp server may determine message burst requirements for the different digital representations. The message burst requirements may specify a max latency or jitter allowed between consecutive messages associated with the same digital representation. The message burst requirements may also apply to message spanning across different digital representations, and / or elements of a digital representation associated with the MAS. This determination may be based on the information provided to a MetaApp server within a MAS policy such as one or more of the following IEs defined in Table 1 :

[0099] 'Digital Representations > QoS info > required E2E bandwidth’,

[0100] ‘Digital Representations > QoS info > required E2E latency,

[0101] ‘Digital Representations > QoS info > required E2E jitter,

[0102] ‘Digital Representations > QoS info > required E2E reliability,

[0103] ‘Digital Representations > QoS info > required E2E schedule,

[0104] ‘Digital Representations > IEs > IE data type’,

[0105] ‘Digital Representations > IEs > IE sample size’,

[0106] ‘Digital Representations > IES > IE directionality’,

[0107] ‘Digital Representations > IEs > IE mirroring’,

[0108] ‘Digital Representations > IEs > IE QoS info > required E2E bandwidth’,

[0109] ‘Digital Representations > IEs > IE QoS info > required E2E latency,

[0110] ‘Digital Representations > IEs > IE QoS info > required E2E jitter,

[0111] ‘Digital Representations > IEs > IE QoS info > required E2E reliability7,

[0112] ‘Digital Representations > IEs > IE QoS info > required E2E schedule,

[0113] ‘Digital Representations > Multi-modal digital representation synchronization policies’,

[0114] ‘Digital Representations > Multi-modal digital representation synchronization policies > Applicable IEs’.

[0115] ‘Digital Representations > Multi-modal digital representation policies > Type of multi-modal digital representation synchronization’,

[0116] ‘Digital Representations > Multi-modal digital representation policies > Multimodal digital representation synchronization actions’,

[0117] ‘Digital Representations > Multi-modal digital representation policies > Multimodal digital representation synchronization precision’,

[0118] ‘Multi-modal MAS synchronization policies >’,

[0119] ‘Multi-modal MAS synchronization policies > Type of multi-modal MAS synchronization' ’ ,

[0120] ‘Multi-modal MAS synchronization policies > Multi-modal MAS synchronization actions’,

[0121] Multi-modal MAS synchronization policies > Multi-modal MAS synchronization precision’

[0122] Note, if the network communication flows are found to already exist (e.g.. the MAS policies are being updated rather than being created for the first time), then the MetaApp server may re-configure / update existing network communication flows based on the updated information provided in the updated MAS policy(s).

[0123] After finishing the creation or update of the MAS policy and the corresponding MAS management operations such as creating or updating network communication flows for the MAS, the MetaApp client or server may return a response to the Metaverse application client or server. The response may comprise a status indicating whether the MAS policyrequest was successfully processed and the MAS network communication flows for the MAS have been successfully established. The response may also comprise a MAS ID assigned by the MetaApp client or server if applicable.

[0124] Step 5: Once network communication flows have been established for the MAS by the MetaApp client or server, the Metaverse application clients(s) and server(s) may begin using the MAS. For example, the Metaverse application clients(s) and server(s) may begin exchanging application traffic (via the network communication flows associated with the MAS) between the client-side and server-side digital representations as required by the application use case.

[0125] Step 6: For each network communication flow which the MetaApp client or server creates or updates on behalf of a MAS, state information may be maintained by the MetaApp client or server. This MAS state information may be collected while the Metaverse application clients(s) and server(s) interact with one another and exchange application traffic via the established network communication flows. This MAS state information maintained by the MetaApp client or server may comprise IES such as but not limited to those defined in Table 2. This state information may be used to enable subsequent MAS management operations which are performed by the MetaApp client or server. The collected state and corresponding measurements performed by the MetaApp client or server may be based on MAS measurement policies which the MetaApp client(s) and / or server(s) have been configured with. The MAS measurement policies may be configured onto the MetaApp client(s) and / or server(s) via requests received from Metaverse application clients or servers or other entities in the system (e.g., a management application). The MAS measurement policies may comprise IEs such as but not limited to those specified in Table 1.

[0126] MAS state information may be used to enable monitoring the overall health and status of each network communication flow associated with the MAS to ensure the digital representation requirements of the MAS are being met by their associated netw ork communication flow s. In addition, multi-modal flow synchronizations for each digital representation are adapted according to synchronization policies defined for the digital representation. Furthermore, multi-modal MAS synchronization policies may be used to adapt multi-modal flows of different digital representations within the MAS to ensure QoS for the MAS is met. To enable the collection of this MAS state information and to keep it updated and current, the MetaApp client or server may interact with one or more otherfunctions or sendees in the system (e.g., SEALDD client or server, 3GPP NEF). This interaction may involve the MetaApp client or server sending requests(s) such as subscriptions or queries to these other functions or services. These other functions or services may assist the MetaApp client(s) and / or server(s) with collecting state and performing measurements related to the network communication flows associated with the MAS. Based off of the request(s), the MetaApp client or server may receive network communication flow state information updates from these other functions or services via notifications or query’ responses. This network communication flows state information may be used by the MetaApp client or server to trigger analysis of the health and status of the MAS.

[0127] For example, a MetaApp server may subscribe to receive measurements and notifications related to SEALDD flows and / or QoS flows from a SELADD server or 3GPP defined NEF. Based on these notifications, a MetaApp server may determine whether the individual network communication flows associated with the MAS are meeting the digital representation requirements defined within the MAS policy. Based on the monitoring results, the MetaApp client(s) and / or server(s) may determine the network communication flow requirements of the MAS are no longer being met. Based on this determination, the MetaApp client(s) and / or server(s) may initiate reconfiguration of one or more network communication flows such that the network communication requirements of the MAS continue to be met. The MetaApp server may also perform multi-modal synchronization actions, multi-modal measurement actions based on the MAS policies defined in Table 1.

[0128] Step 7: MetaApp client(s) and / or server(s) may generate and send MAS related notifications to Metaverse application server(s) and / or client(s). For example, if MetaApp client(s) and / or server(s) detect that the network communication flow requirements of the MAS can no longer be met by the 3GPP system, or a MAS measurement threshold defined in a MAS measurement policy has been exceeded, then a MAS notification may be sent to Metaverse application server(s) and / or client(s). A MAS notification may comprise MAS state information such as but not limited to the MAS measurement IES specified in Table 2. The MAS notification may also comprise instructions for Metaverse application clients or servers to modify their Metaverse communication behavior (e.g., change / decrease media format / resolution, decrease sensor sampling rate, deactivate certain sensors) until network conditions improve.

[0129] Step 8: A MetaApp client or server may receive a query request from a Metaverse application client or server to discover or retrieve MAS related information. The request may discover or retrieve MAS policy or MAS state IES managed by the MetaApp client or server. The request may include an identifier of one or more MAS policy or MAS state IEs such as but not limited to those defined in Table 1. The request may include filter criteria comprising conditions for the retrieval or discovery7of MAS policy or MAS state IEs. The conditions may comprise identifiers of MAS policy or MAS state IEs and / or Boolean expressions which include MAS policy or MAS state IEs and operators and values of interest. Based on the information provided in the request, the MetaApp client or server may process the request by identifying any matching MAS policy or MAS state IEs and returning these in a response.

[0130] Step 9: A Metaverse application client or server or another entity in the system (e.g., a management application) may initiate the tear-down of a MAS. The tear-down of the MAS may comprise several steps. For example, Metaverse application clients or servers may send one or more requests to MetaApp clients or servers. The requests may comprise an identifier of a MAS to tear-down. Upon receiving the request, the MetaApp clients or servers may perform one or more MAS tear-down related operations. The MAS tear-down related operations may involve the MetaApp client or server tearing down one or more network communication flow s associated with the MAS. To perform the tear-down of these netw ork communication flows, the MetaApp client or server may send one or more requests to other functions or services in the system such as but not limited to a SEALDD client or server or a function within a 3GPP network. The MAS tear-down related operations may also involve the MetaApp clients and servers stopping any MAS related measurements and actions performed for the MAS. The stopping of the MAS related measurements and actions may also involve the MetaApp client or server sending one or more requests to other functions or services in the system such as but not limited to a SEALDD client or server or a function within a 3 GPP network. The MAS tear-down related operations may also involve the MetaApp clients and servers deleting any MAS policies or MAS state associated with the MAS. Upon completion of the MAS tear-down related operations, the MetaApp client or server may send a response back to the Metaverse application client or server or other entity in the system which initiated the MAS tear-down request. The response may compnse a MAS tear-down status and an MAS identifier.

[0131] Note, although it was not specifically mentioned in any of the steps described in the above procedure, interaction may occur between MetaApp clients and MetaApp servers in order to realize the above functionality. This interaction may involve MetaApp clients and servers exchanging requests and responses in order to share and synchronize MAS policy and MAS state information as well as to perform MAS management operations. For example, a MetaApp client may send a request to a MetaApp server to create a MAS policy if / when the MetaApp client receives a request from a Metaverse application client to create a MAS policy. This may enable the MetaApp server to perform the network communication flow configuration and create operations with other functions and services in the system (e.g., SEALDD server and 3GPP NEF).REST MAS Embodiment

[0132] In one embodiment. MetaApp clients and servers may implement MAS lEs using REST APIs and resources. The resources may have unique addresses (e.g., URIs, URNs, etc.) and may also have one or more attributes that contain resource data and / or metadata. These MAS resources may be created, retrieved, discovered, updated, or deleted by application clients and servers, other entities such as other MetaApp clients and servers. The MetaApp clients and servers may support APIs for these resource that are based on RESTful protocols such as HTTP and CoAP. In addition, subscriptions may also be made to MAS resources to receive notifications if / when any modifications are made to the resources.Pub / Sub MAS Embodiment

[0133] In another embodiment. MetaApp clients and servers may implement MAS lEs as topics within the topic space of a message broker (e.g., MQTT broker, AMQP broker, etc ). A MetaApp client and / or server may function as the message broker. Alternatively, the message broker may be hosted external to the MetaApp client and / or server by another node or function in the network which the MetaApp client and / or server communicates with to create, update, retrieve, delete, and subscribe to MAS lEs topics.

[0134] The MAS topics may have unique addresses (e.g., topic names, etc.) and also one or more attributes that contain topic data and / or metadata. These MAS topics may be published to or subscribed to by application clients and servers as well as other MetaApp clients and servers.Graphical User Interface

[0135] Figure 9 shows an example GUI in which a user may configure a MAS policy.Example Communications System

[0136] The 3rd Generation Partnership Project (3 GPP) develops technical standards for cellular telecommunications network technologies, including radio access, the core transport network, and service capabilities - including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred as 3G), LTE (commonly referred as 4G), LTE- Advanced standards, and New Radio (NR), which is also referred to as “5G". 3GPP NR standards development is expected to continue and include the definition of next generation radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 7 GHz, and the provision of new ultra-mobile broadband radio access above 7 GHz. The flexible radio access is expected to consist of a new, non-backwards compatible radio access in new spectrum below 7 GHz, and it is expected to include different operating modes that may be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with diverging requirements. The ultra-mobile broadband is expected to include cmWave and mmWave spectrum that will provide the opportunity for ultra-mobile broadband access for, e.g., indoor applications and hotspots. In particular, the ultra-mobile broadband is expected to share a common design framework with the flexible radio access below 7 GHz, with cmWave and mmWave specific design optimizations.

[0137] 3GPP has identified a variety7of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rate, latency, and mobility. The use cases include the following general categories: enhanced mobile broadband (eMBB) ultrareliable low-latency Communication (URLLC), massive machine type communications (mMTC), network operation (e.g., network slicing, routing, migration and interworking, energy savings), and enhanced vehicle-to-everything (eV2X) communications, which may include any of Vehicle-to-Vehicle Communication (V2V), Vehicle-to-Infrastructure Communication (V2I), Vehicle-to-Network Communication (V2N), Vehicle-to-Pedestrian Communication (V2P), and vehicle communications with other entities. Specific service and applications in these categories include, e.g., monitoring and sensor networks, device remote controlling, bi-directional remote controlling, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, automotive ecall, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality7, tactileinternet, virtual reality, home automation, robotics, and aerial drones to name a few. All of these use cases and others are contemplated herein.

[0138] FIG. 10A illustrates an example communications system 100 in which the methods and apparatuses described and claimed herein may be an aspect of. As shown, the example communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103 / 104 / 105 / 103b / l 04b / l 05b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108. the Internet 110, other networks 1 12, and V2X server (or ProSe function and server) 1 13, though it will be appreciated that the disclosed examples contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c. 102d, 102e, 102f, 102g may be any type of apparatus or device configured to operate and / or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e, 102f, 102g is depicted in FIGs 10A-10E as a hand-held wireless communications apparatus, it is understood that with the wide variety of use cases contemplated for 5G wireless communications, each WTRU may comprise or be embodied in any type of apparatus or device configured to transmit and / or receive wireless signals, including, by way of example only, user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane, and the like.

[0139] The communications system 100 may also include a base station 114a and a base station 114b. Base stations 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication netw orks, such as the core netw ork 106 / 107 / 109, the Internet 110, and / or the other networks 112. Base stations 114b may be any type of device configured to wiredly and / or wirelessly interface with at least one of the RRHs (Remote Radio Heads) 118a, 118b, TRPs (Transmission and Reception Points) 119a, 119b. and / or RSUs (Roadside Units) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the other networks 112, and / or V2X server (or ProSefunction and server) 113. RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRU 102c, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or the other networks 1 12. TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRU 102d, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or the other networks 112. RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRU 102e or 102f, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the other networks 112, and / or V2X server (or ProSe function and server) 113. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS). aNode-B, an eNode B, a Home Node B. a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0140] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114b may be part of the RAN 103b / l 04b / 105b, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a may be configured to transmit and / or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, the base station 114a may include three transceivers, e.g., one for each sector of the cell. In some cases, the base station 114a may employ multiple-input multiple output (MIMO) technology7and, therefore, may utilize multiple transceivers for each sector of the cell.

[0141] The base stations 114a may communicate with one or more of the WTRUs 102a, 102b, 102c over an air interface 115 / 1 16 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microw ave, infrared (IR), ultraviolet (UV),visible light, cmWave, mmWave, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0142] The base stations 114b may communicate with one or more of the RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a and 120b, over a wired or air interface115b / l 16b / l 17b, which may be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115b / l 16b / l 17b may be established using any suitable radio access technology (RAT).

[0143] The RRHs 118a, 118b, TRPs 119a, 1 19b and / or RSUs 120a, 120b, may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over an air interface 115c / l 16c / l 17c, which may be any suitable wireless communication link (e.g.. radio frequency (RF), microwave, infrared (IR). ultraviolet (UV). visible light, cmWave. mmWave, etc.). The air interface 115c / l 16c / l 17c may be established using any suitable radio access technology (RAT).

[0144] The WTRUs 102a, 102b, 102c,102d, 102e, 102f, and / or 102g may communicate with one another over an air interface 115d / l 16d / l 17d (not shown in the figures), which maybe any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface115d / l 16d / l 17d may be established using any suitable radio access technology- (RAT).

[0145] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b and RSUs 120a, 120b, in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d, 102e. 102f. may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 or 115c / l 16c / l 17c respectively using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

[0146] In some cases, the base station 114a and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a, 120b, in the RAN 103b / 104b / 105b and theWTRUs 102c, 102d, may implement a radio technology' such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115 / 116 / 117 or 115c / l 16c / l 17c respectively using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A). In the future, the air interface 115 / 116 / 1 17 may implement 3GPP NR technology. The LTE and LTE-A technology includes LTE D2D and V2X technologies and interface (such as Sidelink communications, etc.) The 3GPP NR technology7includes NR V2X technologies and interface (such as Sidelink communications, etc.)

[0147] In some cases, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b, in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d, 102e, 102f may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability7for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO. Interim Standard 2000 (IS- 2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0148] The base station 114c in FIG. 10A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity7in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In some cases, the base station 114c and the WTRUs 102e, may implement a radio technology such as IEEE 802. 11 to establish a wireless local area network (WLAN). In some cases, the base station 114c and the WTRUs 102d, may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In some cases, the base station 114c and the WTRUs 102e, may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM. LTE. LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 10A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 1 14c may not be required to access the Internet 110 via the core network 106 / 107 / 109.

[0149] The RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b may be in communication with the core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core netw ork 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling,Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication.

[0150] Although not shown in FIG. 10A, it will be appreciated that the RAN 103 / 104 / 105 and / or RAN 103b / l 04b / l 05b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or RAN 103b / 104b / l 05b, which may be utilizing an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0151] The core network 106 / 107 / 109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110. and / or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT.

[0152] Some or all of the WTRUs 102a, 102b. 102c. 102d in the communications system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102e shown in FIG. 10A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.

[0153] FIG. 10B is a block diagram of an example apparatus or device configured for wireless communications in accordance with the aspects illustrated herein, such as for example, a WTRU 102. As shown in FIG. 10B. the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 113, a display / touchpad / indicators 128, non-removable memory 130, removablememory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an example. Also, in some cases the base stations 114a and 114b, and / or the nodes that base stations 1 14a and 114b may represent, such as but not limited to transceiver station (BTS), aNode-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. 10B and described herein.

[0154] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other ty pe of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120. which may be coupled to the transmit / receive element 122. While FIG. 10B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0155] The transmit / receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 115 / 116 / 117. For example, in some cases, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In some cases, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In some cases, the transmit / receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0156] In addition, although the transmit / receive element 122 is depicted in FIG. 10B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in some cases, theWTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0157] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802. 11. for example.

[0158] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / mi crophone 124, the keypad 126, and / or the display / touchpad / indicators 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicators 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other t pe of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory' card, and the like. In some cases, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0159] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, and the like.

[0160] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to. or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115 / 116 / 117 from a base station (e g., base stations 114a, 1 14b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will beappreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an aspect.

[0161] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as an accelerometer, biometrics (e.g., finger print) sensors, an e- compass. a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0162] The WTRU 102 may be embodied in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane. The WTRU 102 may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 138.

[0163] FIG. 10C is a system diagram of the RAN 103 and the core network 106. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 10C, the RAN 103 may include Node-Bs 140a. 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an aspect of the disclosure.

[0164] As shown in FIG. 10C, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an lub interface. The RNCs 142a, 142b may be in communication with one another via an lur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may beconfigured to carry' out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro-diversity, security functions, data encryption, and the like.

[0165] The core network 106 shown in FIG. 10C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0166] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an luCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108. to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0167] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core netw ork 106 via an luPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b. 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0168] As noted above, the core netw ork 106 may also be connected to the netw orks 112, which may include other w ired or wireless networks that are owned and / or operated by other service providers.

[0169] FIG. 10D is a system diagram of the RAN 104 and the core netw ork 107. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0170] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs w hile remaining consistent with an aspect of the disclosure. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In some cases, the eNode-Bs 160a, 160b. 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0171] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and / or downlink, and the like. As shown in FIG. 10D, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0172] The core network 107 shown in FIG. 10D may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107. it will be appreciated that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0173] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an SI interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0174] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via the SI interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0175] The serving gateway 164 may also be connected to the PDN gatew ay 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP- enabled devices.

[0176] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108. to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core netw ork 107 may include, or may communicate with, an IP gateway (e.g., an IPmultimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0177] FIG. 10E is a system diagram of the RAN 105 and the core network 109. The RAN 105 may be an access service network (ASN) that employ s IEEE 802.16 radio technology7to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0178] As shown in FIG. 10E, the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an aspect of the disclosure. The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In some cases, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility7management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0179] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core netw ork 109. The logical interface betw een the WTRUs 102a, 102b, 102c and the core netw ork 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0180] The communication link betw een each of the base stations 180a, 180b, and 180c may be defined as an R8 reference point that includes protocols for facilitating WTRUhandovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0181] As shown in FIG. 10E, the RAN 105 may be connected to the core netw ork 109. The communication link between the RAN 105 and the core netw ork 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gatew ay 188. While each of the foregoing elements are depicted as part of the core netw ork 109, it will be appreciated that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0182] The MIP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b, and 102c to roam betw een different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other netw orks. For example, the gateway 188 may provide the WTRUs 102a. 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a. 102b, 102c and traditional land-line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other senice providers.

[0183] Although not shown in FIG. 10E. it will be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a. 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core netw orks may be defined as an R5 reference, which may include protocols for facilitating interw orking betw een home core networks and visited core netw orks.

[0184] The core network entities described herein and illustrated in FIGs 10A, IOC, 10D, and 10E are identified by the names given to those entities in certain existing 3GPP specifications, but it is understood that in the future those entities and functionalities may be identified by other names and certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Thus, the particular network entities and functionalities described and illustrated in FIGs 10A, 10B, IOC, 10D, and 10E are provided by way of example only, and it is understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether presently defined or defined in the future.

[0185] FIG. 1 OF is a block diagram of an exemplary7computing system 90 in which one or more apparatuses of the communications networks illustrated in FIGs 10A, IOC, 10D and 10E may be embodied, such as certain nodes or functional entities in the RAN 103 / 104 / 105, Core Network 106 / 107 / 109, PSTN 108, Internet 110, or Other Networks 112. Computing system 90 may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever, or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within a processor 91, to cause computing system 90 to do work. The processor 91 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality7of microprocessors, one or more microprocessors in association w ith a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array7(FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 91 may perform signal coding, data processing, powder control, input / output processing, and / or any other functionality that enables the computing system 90 to operate in a communications network. Coprocessor 81 is an optional processor, distinct from main processor 91, that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatuses disclosed herein.

[0186] In operation, processor 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computing system’s main data- transfer path, system bus 80. Such a sy stem bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sendinginterrupts and for operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0187] Memories coupled to system bus 80 include random access memory (RAM) 82 and read only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally contain stored data that cannot easily be modified. Data stored in RAM 82 may be read or changed by processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 may be controlled by memory controller 92. Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory' protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode may access only memory mapped by its own process virtual address space; it cannot access memory within another process’s virtual address space unless memory sharing between the processes has been set up.

[0188] In addition, computing system 90 may contain peripherals controller 83 responsible for communicating instructions from processor 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.

[0189] Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). Display 86 may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86.

[0190] Further, computing system 90 may contain communication circuitry, such as for example a network adapter 97, that may be used to connect computing system 90 to an external communications network, such as the RAN 103 / 104 / 105, Core Network 106 / 107 / 109, PSTN 108, Internet 110, or Other Networks 112 ofFIGs 10A, 10B, 10C, 10D, and 10E, to enable the computing system 90 to communicate with other nodes or functional entities of those networks. The communication circuitry, alone or in combination with the processor 91, may be used to perform the transmitting and receiving steps of certain apparatuses, nodes, or functional entities described herein.

[0191] FIG. 10G illustrates an example communications system 111 in which the methods and apparatuses described and claimed herein may be an aspect of. As shown, the example communications system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, a base station, a V2X server, and a RSUs A and B, though it will be appreciated that the disclosure contemplates any number of WTRUs, base stations, networks, and / or network elements. One or several or all WTRUs A, B, C, D, E can be out of range of the network (for example, in the figure out of the cell coverage boundary shown as the dash line). WTRUs A. B, C form a V2X group, among which WTRU A is the group lead and WTRUs B and C are group members. WTRUs A, B, C, D, E, F may communicate over Uu interface or Sidelink (PC 5) interface.

[0192] It is understood that any or all of the apparatuses, systems, methods and processes described herein may be embodied in the form of computer executable instructions (e.g.. program code) stored on a computer-readable storage medium which instructions, when executed by a processor, such as processors 118 or 91, cause the processor to perform and / or implement the systems, methods and processes described herein. Specifically, any of the steps, operations or functions described herein may be implemented in the form of such computer executable instructions, executing on the processor of an apparatus or computing system configured for wireless and / or wired network communications. Computer readable storage media include volatile and nonvolatile, removable and non-removable media implemented in any non-transitory (e.g.. tangible or physical) method or technology for storage of information, but such computer readable storage media do not include signals. Computer readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory- or other memory technology7, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium which may be used to store the desired information and which may be accessed by a computing system.Definitions

[0193] Provided below are definitions for abbreviations found within the body of the disclosure.101859.002097 / 2023P01067WQ

[0194] Provided below are definitions for terms found within the body of the disclosure.

Claims

CLAIMSWhat is claimed:

1. An apparatus comprising: one or more processors; memory; and a set of computer-executable instructions stored in the memory that, when executed by the one or more processors, cause: receiving, by a Metaverse application enabler, a request to create or update a Metaverse application session (MAS) policy comprising a description of one or more digital representation associated with the MAS; determining one or more network communication flow requirements of the MAS based on MAS policy information of the request; creating or updating one or more network communication flows for the MAS based on the determined network communication flow requirements of the MAS; monitoring the network communication flows associated with the MAS to determine if the network communication flow requirements of the MAS continue to be met; and detecting a MAS measurement threshold condition has been met and performing one or more MAS measurement actions based on the detected MAS measurement threshold.

2. The apparatus of claim 1, wherein the set of computer-executable instructions, when executed by the one or more processors, further cause: receiving a MAS query or discovery request comprising one or more identifiers for MAS policy lEs or MAS state lEs or filter criteria comprising conditions for retrieval or discovery of MAS policy lEs or MAS state lEs; and sending a MAS query or discovery response comprising one or more identifiers for MAS policy lEs or MAS state lEs matching the identifiers or filter criteria specified in the query or discovery request.

3. The apparatus of claim 1, wherein the set of computer-executable instructions, when executed by the one or more processors, further cause: receiving a request to tear-down network communication flows associated with a MAS, wherein the request may comprise a MAS ID; and processing the teardown request by performing one or more MAS tear-down operations that may involve tearing down one or more network communication flows associated with the MAS.

4. The apparatus of claim 1, wherein the description of each digital representation comprises one or more of: an identifier for the digital representation, and an identifier, data type, sample size, directionality, and QoS info for each individual information element (IE) of the digital representation.

5. The apparatus of claim 1, wherein the MAS policy further comprises multi-modal MAS synchronization policies defining synchronization dependencies between digital representations associated with the MAS.

6. The apparatus of claim 5, wherein the multi-modal digital representation synchronization policies further define different lEs of one or more digital representations having multi-modal synchronization dependencies with one another.

7. The apparatus of claim 1, wherein the creating or updating of the one or more network communication flows is based on multi-modal synchronization requirements defined in the MAS policy.

8. The apparatus of claim 1, wherein the MAS measurement threshold condition in claim 1 comprises a maximum amount of latency offset between associated messages arriving at different digital representations of the MAS.

9. The apparatus of claim 1, wherein the MAS measurement actions in claim 1 comprise reconfiguring one or more network communication flows.

10. The apparatus of claim 1, wherein the MAS measurement actions in claim 1 comprise synchronizing message arrival times between messages associated with the different digital representations of the MAS.

11. The apparatus of claim 10, wherein the synchronizing message arrival times comprises store-and-forwarding of messages to compensate for detected deltas in message arrival times between the different digital representations.

12. A method comprising: receiving, by a Metaverse application enabler, a request to create or update a Metaverse application session (MAS) policy comprising a description of one or more digital representation associated with the MAS; determining one or more network communication flow requirements of the MAS based on MAS policy information of the request; creating or updating one or more network communication flows for the MAS based on the determined network communication flow requirements of the MAS; monitoring the network communication flows associated with the MAS to determine if the network communication flow requirements of the MAS continue to be met; and detecting a MAS measurement threshold condition has been met and performing one or more MAS measurement actions based on the detected MAS measurement threshold.

13. The method of claim 12, further comprising: receiving a MAS query or discovery request comprising one or more identifiers for MAS policy IES or MAS state IES or filter criteria comprising conditions for retrieval or discovery of MAS policy IEs or MAS state IEs; and sending a MAS query or discovery response comprising one or more identifiers for MAS policy IEs or MAS state IEs matching the identifiers or filter criteria specified in the query or discovery request.

14. The method of claim 12, further comprising:receiving a request to tear-down network communication flows associated with a MAS, wherein the request may comprise a MAS ID; and processing the teardown request by performing one or more MAS tear-down operations that may involve tearing down one or more network communication flows associated with the MAS.

15. The method of claim 12, wherein the description of each digital representation comprises one or more of: an identifier for the digital representation, and an identifier, data type, sample size, directionality, and QoS info for each individual information element (IE) of the digital representation.

16. The method of claim 12. wherein the MAS policy further comprises multi-modal MAS synchronization policies defining synchronization dependencies between digital representations associated with the MAS.

17. The method of claim 16, wherein the multi-modal digital representation synchronization policies further define different IES of one or more digital representations having multi-modal synchronization dependencies with one another.

18. The method of claim 12. wherein the creating or updating of the one or more network communication flows is based on multi-modal synchronization requirements defined in the MAS policy.

19. The method of claim 12, wherein the MAS measurement threshold condition in claim 1 comprises a maximum amount of latency offset between associated messages arriving at different digital representations of the MAS.

20. The method of claim 12, wherein the MAS measurement actions in claim 1 comprise reconfiguring one or more network communication flows.

Images