SA1 in TS 22.156 defines spatial anchors as "an association between a location in space (three dimensions) and service information that can be used to identify and access services, e.g. information to access AR media content". Application providers can use spatial anchors to associate application content and services with location information which can be managed by the 3GPP system. In turn, spatial anchors can be used by application clients to discover and access application content and services in a location aware fashion. Clause 5.4 "Use Case on Spatial Anchor Enabler" of TR 22.856 provides detailed use case for spatial anchor enabler. The use case defines mainly two entities:

1. Spatial anchor producer: It creates the spatial anchor along with its place/location in the 3D space. It determines what to share and its location, and any constraints (e.g. who to share the spatial anchor with) and additional information.
2. Spatial anchor consumer: It recognizes anchors associated with locations in 3D space, and use the spatial anchor to obtain the associated information.

In order to create spatial anchor, the producer captures the location of the product and assocates a new spatial anchor with this location and product information. The producer can adjust/update the spatial anchors for its location or service information or removes it completely. The consumer can retrieve information about spatial anchors. SA6 already supports SEAL layer. SA6 can enhance the existing SEAL capability (like location management) to enable support for spatial anchor.

SA6 defined enablers as of now do not support operations required for managing spatial anchors. The open issues are:

1. How to enhance existing appliction enabler (either adding new capability in existing server or defining new capability server) to support CRUD operations for spatial anchors (association between location and service information on customer premises)?
2. How to discover spatial anchors by the consumer (e.g. UE, VAL server)?
3. How can UE(s) within a certain range of spatial anchor be detected?

Ensuring appropriate user consent has been obtained is a critical aspect when handling sensitive information relating to or collected from a user, their devices or the applications installed at their devices. This is highlighted at stage 1 where many of the requirements captured in TS 22.156 are subject to operator policy, regulatory requirements and user consent, the latter being of particular importance to this key issue. For instance, with the expected capability to access, manage and expose user specific avatar related information through the enabler layer it is of utmost importance to capture the consent of the user. Aspects of such information might also be obtained through core network capability exposure, e.g., relating to user identity, body movement or location, and re-exposed by the enabler layer but not without the consent of the user. Another example are, digital assets, where ownership rights are considered to be classified as sensitive information and the owner's consent must be obtained before other users or third party(service provider) can use them. An example of a digital asset is a user designed and produced digital human image. When another user likes that digital human image and wants to use it, they need to request and obtain the owner's consent before doing so. Each user needs to be in full control of which network and device entities are allowed to access, manage and expose information pertaining to themselves and their devices. Such end user approvals ensure that only legitimate, user trusted, entitles can obtain and utilise information and services involving that user's sensitive information.

SA6 defined enablers as of now do not consider usage of user consent in the context of supporting localized mobile metaverse services. The open issues are:

• How to ensure appropriate usage of user consent at the enabler layer to support localized mobile metaverse services in 3GPP specified networks? Appropriate usage of user consent includes ensuring only the legitimate use by non-owners of user sensitive information such as digital assets.

In addition to new 5GS performance requirements, support for Metaverse services have introduced new use cases and requirements related to optimal support for multi-user, highly performant applications. These use cases led to new CN functionality supporting richer digital representations of physical entities (e.g. user profiles in SA2, XR scene in SA4) As defined in TS 22.156, avatars are digital representations of users interacting with the metaverse and with other users. The application enabler layer can enable creation, discovery, and management of avatar profiles for users to offload applications and enable Core Network functionality across services and verticals. The application layer can enable such functionality in a similar manner for avatars as well as for other digital assets. Considering different application-level profiles of the user, some digital assets can be access/used together. The application enabler layer can support managing such multiple digital assets together. Therefore, solutions addressing this key issue may also leverage work from SA2 and SA4 on user profiles and digital assets. The following use cases can be considered for study of value-added features:

• A user provides configuration (or preferences) indicating which metaverse application services can access the avatar information when the user performs transition between metaverse services, to make sure that consistency and continuity of their digital representation is maintained.
  • SA6 can maintain a list of applications allowed to use the avatar (similar to allowed MNO list for federation in EDGEAPP)
  • SA6 can maintain the associations between Avatar profile and user information (e.g. non-3GPP or VAL-layer user information, 5GC exposed information, etc.)
• A User creates multiple avatars and indicates his/her preferences such as: use of specific avatars based on location, use of audio-only service only when experiencing low bandwidth.
  • SA6 can maintain user's choices and: provide avatar information to different application servers based on the location of the user, reject requests for avatar-based communication in poor network conditions, etc.
• A user creates over time multiple digital assets. In addition to configuring individual parameters and preferences for each asset or asset type separately, he/she also provides configuration/ preferences for managing the digital assets to be accessed together for specific applications, which requires identifying common information and/or metadata for multiple digital assets.

This key issue will study:

• What SA6-defined information is required to expose the SA2-defined, SA4-defined and SA3-defined avatar information to support allowed application configuration, location-based avatar contextual information?
• Whether and how application enablement layer manages and exposes information about digital avatars to the consumers (i.e. application clients and servers) or across verticals?

In clause 5.2.1 "Localized mobile metaverse service" of TS 22.156, Localized mobile metaverse services are immersive and integrated into a user's ordinary experiences. Such service experiences are location-related and can include presentation of AR, MR media. Users' localization is important in order to discover spatial anchors. The 5G system offers a spatial localization service to determine this information. [R-5.2.1-003] [R-5.2.1-004] SA6 already supports SEAL layer. SA6 can enhance the existing SEAL capability (like location management) to enable support for spatial mapping.

SA6 defined enablers as of now do not support operations required for spatial mapping. The open issues are:

1. How to produce or modify a spatial map by the consumer (e.g. UE, VAL server)?
2. How to expose a spatial map to authorized third parties?

Mobile Metaverse brings a new dimension to XR/VR services (since meta is about a persistent large-scale virtual interactive experience, where the digital assets are owned or deployed by the end users); and requires enhancements to 3GPP systems to ensure connectivity /performance and provide support. Two relevant use case as described in TS 22.156 are about the 1) Mobile Metaverse Based Selective Multi-modal Feedback Service and 2) Mobile Metaverse for 5G-enabled Traffic Flow Simulation and Situational Awareness. For instance, for the latter use case, to support traffic flow simulation and situational awareness service, the 5G network need to provide low latency, high data rate and high reliability transmission, and in addition, the 5G network may also need to be further enhanced to meet the service requirements for 5G-enabled traffic flow simulation and situation awareness. Meanwhile, in addition to the real objects which may host the UE, their corresponding virtual objects are also capable of interacting with each other and interact with physical objects via 5GS. For such scenarios, there are some issues related to how the digital devices are instantiated and onboarded to edge/cloud platforms (supporting mobile metaverse services) and how a digital device discovers other digital devices within the mobile metaverse service. Furthermore, in mobile metaverse scenarios there can be multiple sessions involved. The figure below shows an example of possible sessions for a mobile metaverse service.

There can be multiple multimodal sessions considering:

1. the interaction between the UE in the physical world and the digital UE at the metaverse (for providing sensor data/measurements and getting multimodal feedback) (green and blue links).
2. interaction between digital UEs (or avatar UE) interacting at the metaverse world. Such avatars can be hosted in the same or different edge/cloud platforms or at the ASP domain.
3. interaction between UE1 and UE2 via the network (which are in vicinity in metaverse but can be far away and served by different RATs/networks) for transactions between the UEs within the metaverse session.
4. interaction of metaverse server with the UE1 and UE2 avatars to configure the interactions for the metaverse service and provide the digital environment as well as to provide ASP policies for the interactions.

Such multitude of sessions (with different traffic requirements) within the same service poses some issues related to how QoS is being monitored and coordinated considering the end-to-end mobile metaverse service requirements.

This Key Issue aims to study:

• How to support the discovery and grouping of digital/avatar and physical UEs so as to interact via the mobile network?
• How to monitor and configure the application QoS parameters for the multimodal sessions within meta service?

SA1 studied use cases to support metaverse services in TR 22.856. However, many of the devices may not be equiped with sufficient capacity to process the data. And so, they need support from other devices to process data as much near as possible. In order to provide immersive interactive location agnostic service experience to mobile metaverse service customers, large amount of computing resouces is needed to perform real-time processing for audio, video, and interactive data, etc. It is possible that some of the devices (e.g. glasses) will not have enough computing resources to perform the real-time rendering, and may need to offload the computing to the nearby devices. For example, SA6 has defined architecture for Application layer support for Personal IoT Network in TS 23.542. To support above use case, a PINE element (i.e. glasses with limited computing capability) need to discover another nearby PINE element (i.e. a UE with sufficient computing capability) to offload the computational task. Current PINAPP architecture supports subscribe-notify mechanism where a PINE element gets notification when a new PINE element joins the PIN. However, not all devices may subscribe for such event. It is required to study how a PINE element (i.e. glasses with limited computing capability) discovers another nearby PINE elements.

In this key issue, SA6 will study following open issues:

1. Whether and how the existing SA6 defined enabler (e.g. PINAPP) is sufficient to support metaverse applications or any enhancements are required (e.g. to discover device from anothter device to offload task)?

SA1 studied use cases to support metaverse services in TR 22.856. In many of the use case, metaverse applications are defined at edge to provide law latency, and further, a user needs multiple devices inorder to work with metaverse services. For example, consider a scenario where a metaverse service (e.g. a game service) requires haptic device associated with the UE/user in order for user to consume the service (e.g. to play the game). Current discovery mechanism (e.g. EAS discovery mechanism) do not support such application server requirements to be considered in the discovery procedure. The possible gap is to consider required capabilities of supported devices (like having joystic or haptic device) to run specific metaverse service. The existing SA6 defined enabler layer procedures are generic for all applications (e,g, EDGEAPP architecture). It is required to study

• How the interaction among multiple devices and AS can be supported in order to provide or to consume metaverse service;

In this key issue, open issues are:

1. To study whether and how to enhance architecture and procedures (e.g. EDGEAPP) to support metaverse service requiring multiple devices?

SA1 in TS 22.156 defines spatial anchors as "an association between a location in space (three dimensions) and service information that can be used to identify and access services, e.g. information to access AR media content". Application providers can use spatial anchors to associate application content and services with location information which can be managed by the 3GPP system. In turn, spatial anchors can be used by application clients to discover and access application content and services in a location aware fashion. Clause 5.1 "Use Case on Localized mobile Metaverse serivce" of TR 22.856 provides a detailed use case for spatial anchor enabled services. It describes the use case where multiple spatial anchors and their services are linked to the space that the user is in. In the usecase, it is mentioned that one or more mobile metaverse services associated with a single location, to be combined to form a single location related service experience. The clause 5.1 use case describes the example of recommending a spatial anchor of a restaurant to the user in the evening time in order to provide an enhanced service experience to the user based on the previous search history spatial anchor. This creates the need for the enabler to provide some intelligent spatial anchor service recommendations which could help the user and improve the service experience. The consumers created spatial anchors may want to understand the analytics of the spatial anchors like users density per spatial anchor, spatial anchor density in a given location, number of times the spatial anchor is accessed to improve their services, spatial anchor improvements like spatial anchor placement planning, user engagement, etc.

The open issues are:

1. How to combine one or more mobile metaverse services associated with spatial anchors?
2. How to provide the exposure of the spatial anchor analytics to the consumers?

Digital asset is defined in TS 22.156 as "digitally stored information that is uniquely identifiable and can be used to realize value according to their licensing conditions and applicable regulations. Examples of digital assets include digital representation (avatar), software licenses, gift certificates, tokens and files (e.g. music files) that have been purchased. This is not an exhaustive list of examples." With the use scenarios of digital assets is getting richer in the mobile metaverse, the demands for the use of digital assets is growing. When digital assets are used by multiple users or used on multiple metaverse application platforms, the service provider needs to provide a permission control mechanism, i.e. whether the operation to the digital asset by the specific user or a group of users is allowed. The use case can be considered for study as follows:

• In the same metaverse service, an owner upload his/her digital asset to trusty public digital asset container (e.g. DACM). When owner wants to share his/her own digital assets (e.g. picture) and the owner only wants to share the digital asset to some specific user(s) in the mobile metaverse. Meanwhile a consumer wants to access the digital asset, the service provider supports for checking whether the consumer has the permission and provides access service to the consumer.
• In multiple metaverse services, when a owner wants to operate his digital asset among multiple metaverse applications. The service provider supports for access/download/modification/delete digital assets by the user or a group of users in multiple metaverses to ensure the consistency of the digital assets.

In KI#2, appropriate usage of user consent includes ensuring only the legitimate use by non-owners of user sensitive information such as digital assets are covered. However the focus of this KI is how to manage the permission of specific operation of a digital asset (e.g. assign the access right, revoke the deletion right, etc), including across multiple metaverses. CAPIF specified in TS 23.222 provides Resource owner-aware Northbound API Access (RNAA) to control access to the owner's resource. The Enhancement of RNAA is also studying by SA6 in Rel-19 FS_CAPIF_Ph3. Currently CAPIF focuses on the management of service API and cannot fulfill the requirements permission control of digital asset in the two use cases above.

This key issue is going to study: