Methods for enabling spatial anchor management in a wireless system

Abstract

NOT VISIBLE DUE TO STATUS OF PATENT

Description

METHODS FOR ENABLING SPATIAL ANCHOR MANAGEMENT IN A WIRELESS SYSTEMCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 554,018, filed February 15, 2024, the contents of which are incorporated herein by reference.BACKGROUND

[0002] The term "metaverse" is often related to virtual technologies such as AR, MR and VR (e.g., termed XR technologies). The metaverse is a loosely defined term referring to persistent, shared, perceived set of interactive spaces. The term may also evoke possible new experiences, products and services that may emerge once XR technologies become commonly available; the metaverse applications are diverse and may eventually provide new experiences in our work, leisure, and other activities. The Third Generation Partnership Project (3GPP), in release 19, is attempting to define metaverse services that may foster the adoption of metaverse technologies and provide new mobile user experiences.

[0003] Localized user experiences happen in the user’s local environment. Such experiences may require that the metaverse media provided to a given user is both adapted and integrated with the local physical world surrounding the user. A localized mobile metaverse service may be associated with specific places (e.g., 3D locations in the physical world). The association between a physical place and service information (e.g., an associated service) may be termed as a ‘‘localized spatial anchor”.SUMMARY

[0004] In principle, a localized mobile metaverse service may allow 3rd parties to provision localized spatial anchors and may allow mobile users to discover the provisioned localized spatial anchors for the purpose of displaying the media associated to the localized spatial anchor. In order to achieve localized spatial anchors spatial anchors management is described. Spatial anchor policies may be required to allow a WTRU to determine the validity of pre-configured or discovered SA instances. Spatial anchor usage reporting is required to provide WTRU assistance information to valid SA instances associated services.

[0005] A spatial anchor (SA) management method is described from the WTRU perspective. The WTRU may be configured with information about one or more SA instances and configured with one or more SA policy rules. The information about the SA instances and SA policy rules may be pre-provisioned on the WTRU. The information about the SA instances and SA policy rules may be received by the WTRU in a message. The WTRU may determine one or more valid SA instances from the configured SA instances. The validity determination may be based on the policy rules and WTRU sensor readings. The WTRU may configure connectivity to a server that provides SA media content according to the determined valid SA instances. The information about one or more SA instances may be used to configure the connectivity to the server thatprovides SA media content. Configuring the connectivity may include establishing a PDU session, requesting a slice, and configuring the QoS, for example. Configuring the connectivity may include blocking traffic associated with invalid SA instances, for example.

[0006] The WTRU may send a SA report to a spatial anchor management function (SAMF). The report may include the determined one or more valid SA instances. The report may include spatial or connectivity information about the WTRU. The SAMF may relay the report information to the one or more valid SA instance associated service. The WTRU may access the one or more valid SA instances associated service to obtain SA media content. The access by the WTRU may be based on SA instance information. The WTRU may render the obtained SA media content.

[0007] A system, device and method are disclosed. The wireless transmit and receive unit (WTRU) includes a processor and a transceiver operably coupled to the processor. The transceiver and processor are configured to transmit a first message to a network function to obtain information about at least one spatial anchor (SA), receive a second message indicating information about the at least one SA, determine a validity status of the at least one SA based on the information received in the second message, communicate with at least one service associated with a valid one of the at least one SA, and consume content provided by the at least one service. The transceiver and processor may be further configured to report valid SA information to the network function. The SA may include an association between a three-dimensional (3D) location and service information. Consuming content may include obtaining virtual media from the at least one service to be displayed at the 3D location. The first message may include SA discovery information. The SA discovery information may include at least one of a SA identifier (SAID), a SA consumer location and orientation, a SA service identifier (SASID) and a SA service characteristics (SASC). The second message may indicate information about the at least one SA includes SA instance information. The SA instance information may include SA service connection information (SASCI). The communication with at least one service may be based on connectivity to a SA service. The SA service connectivity may use a SA service connection information (SASCI) provided in the received second message.

[0008] The method may be performed in a wireless transmit and receive unit (WTRU) for managing spatial anchors (SA). The method includes transmitting a first message to a network function to obtain information about at least one spatial anchor (SA), receiving a second message indicating information about the at least one SA, determining a validity status of the at least one SA based on the information received in the second message, communicating with at least one service associated with a valid one of the at least one SA, and consuming content provided by the at least one service. The method may include reporting valid SA information to the network function. The SA may include an association between a three-dimensional (3D) location and service information. Consuming content may include obtaining virtual media from the at least one service to be displayed at the 3D location. The first message may include SA discovery information. The SA discovery information may include at least one of a SA identifier (SAID), a SA consumer location and orientation, a SA service identifier (SASID) and a SA service characteristics (SASC). The second message may indicateinformation about the at least one SA includes SA instance information. The SA instance information may include SA service connection information (SASCI). The communication with at least one service may be based on connectivity to a SA service. The SA service connectivity may use a SA service connection information (SASCI) provided in the received second message.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, wherein like reference numerals in the figures indicate like elements, and wherein:

[0010] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented;

[0011] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0012] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0013] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0014] FIG. 2 illustrates a high-level overview of the SA lifecycle for the SA producer and for the SA consumer;

[0015] FIG. 3 illustrates a system architecture for management of spatial anchors in a mobile network;

[0016] FIG. 4 (including FIGs. 4A and 4B, collectively referred to as FIG. 4) illustrates several SA management methods that may be performed with the architecture introduced above;

[0017] FIG. 5 illustrates a method for a WTRU to determine validity of SA instances; and

[0018] FIG. 6 illustrates a method for a WTRU to report usage of spatial anchors and provide assistance information to the SA instance associated service.DETAILED DESCRIPTION

[0019] Spatial Anchor (SA) management may be performed in the wireless network. A localized SA is an association between a three-dimensional (3D) spatial location and service information where the service information may be used to identify and access services that may deliver AR media content. The support for localized spatial anchors in the wireless network may enable new use cases and applications that rely on advanced location information to deliver new user experiences, such as experiences that are not possible using traditional location information, for example.

[0020] Supporting spatial anchors presents challenges related to provisioning, discovery, and lifecycle of spatial anchors. There exists a challenge related to the lifecycle management of a spatial anchors on a WTRU. Specifically, after spatial anchor information is discovered or the spatial anchor information is statically preprovisioned on a WTRU, it may not be possible for a WTRU (e.g., SA consumer) to determine if SA instances are valid (e.g., if a SA instance can be used), and to manage valid versus invalid SA instances. Enabling a determination of SA instance validity by a WTRU without relying on spatial modeling techniques is provided.

[0021] SA producers may provision spatial anchor information for delivering a localized service to SA consumers (e.g., WTRU). The SA producer and / or the SA instance associated service, which may be different AF or the same, may need to know the identity of the SA consumer and may need to obtain advanced location information about the SA consumer to assist in generating the SA instance localized content (e.g., AR content). The information and providing that information to a SA producer and / or a SA instance associated service to assist in generating the media content associated with a SA instance is provided.

[0022] This description defines a flexible architecture to manage localized spatial anchors and to solve issues related to determining SA instance validity and providing assistance information to SA instance associated services to deliver a feature rich new user experience.

[0023] Localized spatial anchor management is a capability of a wireless network to allow provisioning, discovering, and managing the lifecycle of localized spatial anchors in the network and on mobile devices (e.g., WTRU). Due to changing environments, envisioned high density of spatial anchors and limited memory available on mobile devices. It may be appreciated that pre-provisioning information related to every spatial anchor on a mobile device would be impractical and unrealistic. Thus, a spatial anchor management function (SAMF) may be provided as a service by the wireless network. Due to the localized nature of spatial anchors, it can also be appreciated that the SAMF may complement or rely on an Edge Computing (EC) architecture to deliver localized user experiences.

[0024] As described, the examples herein use EC network capability, but are not only limited to EC. Examples define the SAMF capability and exemplify that SAMF capability is offered as a service. As would be understood, SAMF functionality may be implemented as a standalone service (e.g., an application function or network function), that the SAMF may be a standalone service, and that SAMF may be implemented as an extension to an existing service.

[0025] Described herein is a spatial anchor management function architecture that is motivated by the identified needs for localized spatial anchors to provide new Augmented Reality (AR) user experiences. As would be understood, spatial anchors may be associated with a metaverse instance (e.g., a digital parallel universe) or several distinct metaverse instances. Further, the described examples, while being motivated by AR scenarios, may also be used in other scenarios that may not be characterized as being exclusively for AR applications.

[0026] SAMF allows a WTRU or an Application Function (AF) to configure, manage, discover, and use spatial anchors within the mobile network. Definition of the SAMF functional entity, procedures and information flows are hereby provided.

[0027] The SAMF may offer a service to manage localized SA, the service may be offered to SA users via an Application Programming Interface (API). The SAMF functionality may be implemented as a standalone Application Function (AF) or as a Network Function (NF). The SAMF functionality may be combined with an existing AF or NF, and the API may be offered as an extension of an existing API. The SAMF service may be offered using a communication protocol, for example the Hyper Text Transfer Protocol (HTTP) or the Non- Access Stratum (NAS) protocol for 5G systems may provide the capabilities for offering the SAMF service. The SAMF may create SA resources and may offer capabilities to manage SA resources. The SA resource may be any information related to a SA instance, memory or storage used to store information related to a SA instance, network capabilities reserved for a SA instance, or processing associated with a SA instance. The SA resource may be created, discovered, enabled, disabled, modified, or deleted by the SAMF. The SAMF may enable concurrent management of multiple SA resources and may offer the SAMF service to multiple concurrent SA consumers.

[0028] Spatial Anchor (SA) management for terminal devices is described. Specifically, presented are spatial anchor policy and spatial anchor reporting. The spatial anchor policy and spatial anchor reporting provides spatial anchor management and includes functionality. An architecture for supporting SA management that supports these concepts is included.

[0029] A spatial anchor management method is described from the WTRU perspective. The WTRU may be configured with information about one or more SA instances and configured with one or more SA policy rules. The information about the one or more SA instances and one or more SA policy rules may be preprovisioned. The information about the known SA instances and SA policy rules may be received in a message. The WTRU may determine one or more valid SA instances from the configured one or more SA instances. The validity determination of the one or more valid SA instances may be based on the policy rules and WTRU sensor readings. The WTRU may configure connectivity to a server that provides SA media content according to the determined one or more valid SA instances. The information about the one or more SA instances may be used to configure the connectivity. Configuring the connectivity may include establishing a PDU session, requesting a slice, and configuring the QoS, for example. Configuring the connectivity may include blocking traffic associated with invalid SA instances.

[0030] The WTRU may send a SA report to the spatial anchor management function (SAMF). The report may include the determined one or more valid SA instances. The report may include spatial or connectivity information about the WTRU. The SAMF may relay the report information to the valid SA instance associated service. The WTRU may access the one or more valid SA instances associated service to obtain SA mediacontent. The access may be based on one or more SA instance information. The WTRU may render the obtained SA media content.

[0031] A system, device and method are disclosed. The wireless transmit and receive unit (WTRU) includes a processor and a transceiver operably coupled to the processor. The transceiver and processor are configured to transmit a first message to a network function to obtain information about at least one spatial anchor (SA), receive a second message indicating information about the at least one SA, determine a validity status of the at least one SA based on the information received in the second message, communicate with at least one service associated with a valid one of the at least one SA, and consume content provided by the at least one service. The transceiver and processor may be further configured to report valid SA information to the network function. The SA may include an association between a three-dimensional (3D) location and service information. Consuming content may include obtaining virtual media from the at least one service to be displayed at the 3D location. The first message may include SA discovery information. The SA discovery information may include at least one of a SA identifier (SAID), a SA consumer location and orientation, a SA service identifier (SASID) and a SA service characteristics (SASC). The second message may indicate information about the at least one SA includes SA instance information. The SA instance information may include SA service connection information (SASCI). The communication with at least one service may be based on connectivity to a SA service. The SA service connectivity may use a SA service connection information (SASCI) provided in the received second message.

[0032] The method may be performed in a wireless transmit and receive unit (WTRU) for managing spatial anchors (SA). The method includes transmitting a first message to a network function to obtain information about at least one spatial anchor (SA), receiving a second message indicating information about the at least one SA, determining a validity status of the at least one SA based on the information received in the second message, communicating with at least one service associated with a valid one of the at least one SA, and consuming content provided by the at least one service. The method may include reporting valid SA information to the network function. The SA may include an association between a three-dimensional (3D) location and service information. Consuming content may include obtaining virtual media from the at least one service to be displayed at the 3D location. The first message may include SA discovery information. The SA discovery information may include at least one of a SA identifier (SAID), a SA consumer location and orientation, a SA service identifier (SASID) and a SA service characteristics (SASC). The second message may indicate information about the at least one SA includes SA instance information. The SA instance information may include SA service connection information (SASCI). The communication with at least one service may be based on connectivity to a SA service. The SA service connectivity may use a SA service connection information (SASCI) provided in the received second message.

[0033] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users.The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), singlecarrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S- OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0034] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (ON) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fl device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0035] The com munications systems 100 may also incl ude a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, 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.

[0036] The base station 114a may be part of the RAN 104, 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, and the like. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensedand unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. 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, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0037] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0038] 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 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 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 (DL) Packet Access (HSDPA) and / or High-Speed Uplink (UL) Packet Access (HSUPA).

[0039] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0040] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using NR.

[0041] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

[0042] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, 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.

[0043] The base station 114b in FIG. 1A 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 connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106.

[0044] The RAN 104 may be in communication with the CN 106, 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. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 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. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing a NR radio technology, the CN 106 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0045] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the 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 / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0046] 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 may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellularbased radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0047] FIG. 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0048] 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 Arrays (FPGAs), any other type 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. 1 B 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.

[0049] 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 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, 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 yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or 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.

[0050] Although the transmit / receive element 122 is depicted in FIG. 1 B 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 one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0051] 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 NR and IEEE 802.11 , for example.

[0052] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 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 datato the speaker / microphone 124, the keypad 126, and / or the display / touchpad 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 type 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 other embodiments, 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).

[0053] 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 (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li- ion), etc.), solar cells, fuel cells, and the like.

[0054] 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 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0055] 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 an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, 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, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor and the like.

[0056] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and DL (e.g., for reception) may be concurrent and / or simultaneous. The full duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke)or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the DL (e.g., for reception)).

[0057] FIG. 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0058] 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 while remaining consistent with an embodiment. 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 one embodiment, 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 / or receive wireless signals from, the WTRU 102a.

[0059] Each of the eNode-Bs 160a, 160b, 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 UL and / or DL, and the like. As shown in FIG. 10, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0060] The CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0061] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 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 provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

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

[0063] The SGW 164 may be connected to the PGW 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.

[0064] The CN 106 may facilitate communications with other networks. For example, the CN 106 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 CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0065] Although the WTRU is described in FIGS. 1A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0066] In representative embodiments, the other network 112 may be a WLAN.

[0067] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. The peer-to- peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication.

[0068] When using the 802.11ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0069] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0070] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz, and / or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two noncontiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0071] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11ah. The channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11ah relative to those used in 802.11n, and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support Meter Type Control / Machine- Type Communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0072] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11ac, 802.11af, and 802.11ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy even though a majority of the available frequency bands remains idle.

[0073] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, theavailable frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

[0074] FIG. 1D is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0075] The RAN 104 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0076] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a varying number of OFDM symbols and / or lasting varying lengths of absolute time).

[0077] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non- standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b,102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0078] Each of the gNBs 180a, 180b, 180c 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 UL and / or DL, support of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0079] The CN 106 shown in FIG. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0080] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0081] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

[0082] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, 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. The UPF 184, 184b may perform other functions, such as routing and forwarding packets,enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

[0083] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0084] In view of FIGs. 1A-1 D, and the corresponding description of FIGs. 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0085] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and / or performing testing using over-the-air wireless communications.

[0086] The one or more emulation devices may perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0087] FIG. 2 illustrates a high-level overview 200 of the SA lifecycle for a SA producer 210 and for a SA consumer 250. SA producer 210 may be a WTRU or an AF, for example. The SA lifecycle for SA producer 210 may include the three high-level phases of SA provisioning 220, SA management 230 and SA deletion 240. SA consumer 250 may be a WTRU (e.g., a WTRU application or enabler) or an AF, for example. TheSA lifecycle for SA consumer 250 may include three high level phases of SA discovery 260 (i.e., ''discovered1'), SA usage 270 (i.e., "in use") and SA invalidation 280 (i.e., "invalidated").

[0088] In SA provisioning 220, SA producer 210 may request the SAMF to create one or more SA instances. The SAMF may create one or more SA resources associated with the requested one or more SA instances based on SA information provided by SA producer 210. The one or more SA resources may include information that uniquely identifies the one or more SA instances, information describing the spatial locations of the one or more SA instances, and services associated with the one or more SA instances. Further details on SA instance information are described herein and details on SA provisioning 220 and associated method are described herein.

[0089] In SA management 230, SA producer 210 may request the SAMF to perform management operations on one or more SA instances. The SAMF may provide SA producer 210 or consumers with SA information resulting from SA management 230 operation. SA management 230 operations may include configuring, enabling, disabling, or modifying the SA. The results of SA management 230 operation may be sent (e.g., responded or notified) to SA producer 210 or consumers and may include updated SA information. Further details on SA instance information are described herein and details on SA management 230 are described herein .

[0090] In SA deletion 240, SA producer 210 may request the SAMF to delete the SA. Upon receipt of the request, the SAMF may release resources associated with the SA. Alternatively, a SA instance may be scheduled to expire and the SAMF may delete the SA instance upon expiration and notify SA producer 210 upon expiration. Further, details on SA deletion 240 and associated notification are described herein.

[0091] In SA discovery 260, SA consumer 250 may request the SAMF to discover one or more SA instances. The SAMF may determine one or more SA instances based on information provided by SA consumer 250. The SA information may include information that uniquely identifies the one or more SA instances. The SA information may include information describing the location or service associated with the one or more SA instances and may include policy information indicating usability of the one or more SA instances in the SA discovery 260. Further, details on SA instance information are described herein and details on SA discovery 260 are described herein.

[0092] In SA usage 270, SA consumer 250 may use the one or more SA instances from SA discovery 260 according to a SA policy. SA instance usage may require that SA consumer 250 first determines if the discovered one or more SA instances can be used (e.g., according to the SA consumer location, position, orientation, etc.) according to a SA policy. The results of determining if a SA instance can be accessed may be SA consumer 250 accessing a service associated with the one or more SA instances. Further, details on SA usage 270 according to SA policy is provided herein.

[0093] In SA invalidation 280, SA consumer 250 may invalidate one or more discovered SA instances. SA instance invalidation may occur in agreement with the SA policy or may result from messaging received fromthe network. Once one or more SA instances are invalidated via SA invalidation 280, the invalidated one or more SA instances may be indicated as being invalid. Further, details of SA invalidation 280 is provided herein.

[0094] SA information may be configured as follows. A SA instance may be described, briefly, as information associating a spatial location with a service. SA instance description may additionally include policy information describing spatial conditions (e.g., location, orientation, viewport size, etc.) for using a SA instance, spatial accuracy information indicating the minimum spatial accuracy capabilities needed by the SA consumer (e.g., WTRU) to use the SA instance, or validity conditions based on time, duration, WTRU context, etc.

[0095] The following information elements (lEs) may describe a SA instance. SA instance information may be one or more IE that describe a SA instance.

[0096] The SA type (SAT) uniquely identifies a type of SA. The SA type may indicate that the SA is a single point in space, or if the SA is composed of multiple points in space (e.g., a group of spatial anchors). SAT may also refer to the type of content or service that is associated with a SA instance. For example, certain SA may provide rendered media content that may be displayed in AR glasses, while other SAT may indicate that the SA instance provides information that may be displayed or used by the SA consumer as needed.

[0097] The SA identifier (SAID) uniquely identifies a SA instance. The SAID may be provided by the SA producer or may be assigned by the SAMF when the SA instance is created. The SAID may include both an external SAID assigned by the SA producer and an internal SAID assigned by the SAMF. The SAID may be used by the SA consumer, SA producer or SAMF to uniquely identify a SA instance.

[0098] The SA service identifier (SASID) identifies the application or service performed by the service associated with the SA instance. For example, the SASID may indicate a fully qualified domain name (FQDN), a unified resource identifier (URI), an IP address, an edge application server (EAS) identifier or a cloud application server (CAS) identifier. Additionally, the SASID may include information required to retrieve the service information, such as an edge enabler server (EES) identifier, an edge configuration server (ECS) identifier, or an edge application server discovery function (EASDF) identifier.

[0099] The SA service connection information (SASCI) indicates the information required by a WTRU to establish a connection to the service associated with the SA instance. For example, the SASCI may indicate the data network name (DNN), access point name (APN), and single-network slice selection assistance information (S-NSSAI).

[0100] The SA service characteristics (SASC) identifies the characteristics of the application or service performed by the service associated with the SA instance. For example, SASC may indicate the application type (e.g., information service, rendering service, etc.), the application version information (e.g., application version, API version, etc.), the application size, and the media content type delivered by the application.

[0101] The SA traffic descriptor (SATD) identifies the traffic that can be provided by a SA instance associated service. The SAMF or SA consumer may use the SATD to enable QoS policies for the media contenttraffic that will be sent from the service to the SA consumer. For example, the SATD may include a QoS Reference which can be used by the 5G system to determine QoS Parameters.

[0102] The SA producer identifier (SAPID) indicates the identity of the SA producer. The SA producer may be used for filtering the SA instances that belong to the same SA producer. When a SA producer is a specific application, it may be used to filter all the SA instances provided for a given application. It can be appreciated that when the SA producer is a WTRU, the SAPID may be used to identify the SA instances created by a WTRU or a user.

[0103] The SA consumer identifier (SACID) indicates the identity of the SA consumers. In certain deployments, SACID may be static and represent the SA consumer allowed to use a SA instance. In other deployments, the SACID may be a dynamic list of SA consumers that have been provided with the SA instance information. The SACID may be used for filtering SA instances or authorize access to SA instances.

[0104] The SA state indicates if the SA instance is enabled or disabled. An enabled SA instance indicates if the associated service is allowed to provide media content. A disabled SA instance indicates that the SA is not allowed to provide media content. A disabled SA instance may still be discovered (e.g., indicating that there is a SA at a specific location) but indicating that the associated media content is not available. The SA state may be changed by the SAMF based on request from the SA producer or other environmental factors (e.g., time, location, etc.). The SA state may additionally indicate whether the SA is valid or invalid according to a SA policy. For example, the SA state of a multiplicity of SA instances may indicate that certain SA instances are disabled and certain SA instances are enabled; further, the disabled SA instances may be considered invalid since the associated service cannot be accessed; further, the enabled SA instances may be evaluated against a SA policy, and the evaluation may allow to determine that some SA instances are enabled and invalid (e.g., according to the SA policy) and some SA instances are enabled and valid. It may be appreciated based on the example, that the state of a SA instance may be enabled or disabled, and further valid or invalid, and that disabled SA instances may be considered invalid.

[0105] A SA instance associated service is a service that is associated with a spatial anchor and that may provide media content.

[0106] FIG. 3 illustrates a system architecture 300 for management of spatial anchors in a mobile network. A spatial anchor management function (SAMF) 390 is provided in the system architecture 300. SAMF 390 may provide APIs for communication with both SA producers 310 and SA consumers 350. Communication between a WTRU and SAMF 390 may be possible on the user plane, for example when SAMF 390 is offered as a service or may be possible via NAS communication.

[0107] As is understood and described herein, at 305, SA producer 310, such as an AF, for example, may register, provision, and manage SA instances and subscribe for SA analytics with SAMF 390. At 325 (referring collectively to register 325i, subscribe 3252 and discover 3253), SA consumer 350, such as a WTRU, for example, may register, subscribe and discover SA instances with SAMF 390. At 335, SAMF 390 may notifythe SA consumer 350 when a new SA becomes available or when a SA becomes invalid, such as via SA deletion and WTRU mobility, for example. At 345 (referring collectively to report 345i and notify 3452), SA consumer 350 may notify SA producer 310 of SA usage based on SA discovery and SA reporting, At 365, SA consumer 350 nay establish connectivity with the media service associated with valid SAs.

[0108] At 305, SAMF 390 may offer an API to SA producers 310 (e.g., AF, WTRU) that may allow SA producer 310 to register to SAMF 390 service, subscribe for SA events, provision SA instances, or manage SA instances.

[0109] Registration may enable SA producer 310 to provide information about the identity and characteristics of the SA producer 310. For example, characteristics may include type of producer (e.g., WTRU, trusted AF, untrusted AF, EAS, CAS, etc.), capabilities or IP address, for example. Based on the registration information, SAMF 390 may adopt different behavior towards SA producer 310, for example if SA producer 310 is a WTRU, SAMF 390 may request the 5GC for the WTRU position. Registration may be required by SAMF 390 prior to performing other operations.

[0110] Subscription may allow SA producer 310 to receive notifications from SAMF 390 about events impacting SA instances or SAMF 390. The subscription may include a subscription filter that indicates to SAMF 390 events to be notified, for example the subscription filter may indicate to SAMF 390 that SA producer 310 requests or wants to be informed about WTRU information when a SA instance belonging to SA producer 310 is discovered by a WTRU.

[0111] SA provisioning may allow SA producer 310 to create new one or more SA instances at SAMF 390. For example, provisioning may include information about SA producer310 and a SA instance. SAMF 390 may create a SA instance resource based on the provided information and store the SA instance resource in a SA instance repository for management purposes.

[0112] SA management may allow SA producer 310 to exercise control over the SA instances resources created at SAMF 390. For example, management may include obtaining, enabling, disabling, modifying, deleting SA instance information.

[0113] At 315, SAMF 390 may be a service that can be consumed by SA producers 310 and SA consumers 350. SAMF 390 service may have a SA instance repository capability such that SA instance information may be maintained or consumed. For example, the SA instance repository may be a database with spatial modeling capabilities (e.g., with geographic information system (GIS) capabilities) that may allow specialized queries for SA instances based on a position or orientation in space (e.g., the position / orientation of SA consumer 350).

[0114] SAMF 390 may offer an API to SA consumers 350 (e.g., WTRU, AF) that may allow SA consumers 350 to register, at 325i, to SAMF 390, subscribe, at 3252, for SA events, report, at 345i, on SA usage, or discover, at 3253, SA instances.

[0115] Registration at 325i may allow SA consumer 350 to provide information about its identity and characteristics. For example, characteristics may include type of consumer (e.g., WTRU, trusted AF, untrustedAF, EAS, CAS, etc.), capabilities or IP address. Based on the registration information, SAMF 390 may adopt different behavior towards SA consumer 350, for example if SA consumer 350 is a WTRU, SAMF 390 may request the 5GC for the WTRU position. In an example, registration may be required by SAMF 390 prior to performing other operations.

[0116] Subscription at 3252 may allow SA consumer 350 to receive notifications, at 335, from SAMF 390 about events impacting SA instances or SAMF 390. The subscription may include a subscription filter that indicates to SAMF 390 events to be notified, for example the subscription filter may indicate to SAMF 390 that SA consumer 350 requests or wants to be informed about new SA instances that become available in proximity or SA instances that may be modified or deleted.

[0117] SA reporting at 345i may allow SA consumer 350 to inform the network about SA usage. For example, SA consumer 350 may determine that a subset of discovered SA instances may be used, based on the SA policy and SA consumer 350 location, position, or orientation (e.g., based on sensor information). For example, SA consumer 350 may report to SAMF 390 the subset of SA instances that are currently used by SA consumer 350, and the applications consuming the SA instances. SAMF 390 may use the SA reporting information for maintaining metrics about SA instance usage, but also may use the reporting information to notify the associated SA producers 310 or SA instance associated services with information about SA consumer 350 (e.g., WTRU) using the SA instances.

[0118] SA discovery at 3253 may allow SA consumer 350 to discover SA instance information. For example, discovery may include providing information about SA consumer 350 identity and discover filters such as SAID, SA type, SA consumer 350 location and orientation, or SA consumer 350 capabilities. Based on the provided identity and discovery filters, SAMF 390 may identify SA instances and provide information to SA consumer 350 on how to use the SA instances, for example the SA instance information may include the SA spatial location, and rules (e.g., location, connectivity, or spatial positioning rules) that SA consumer 350 may need to use the SA instance.

[0119] At 355, SA consumer 350 may be a WTRU and may have SA usage capabilities. The SA usage capabilities may be provided by an application or by an application enablement service present on the WTRU. The SA usage capabilities may for example be a capability for discovering SA instance(s) information, a capability for maintaining SA instance information during mobility, a capability for interpreting SA rules and determining if a SA instance can be used by an application (e.g., based on the SA consumer 350 location, position, orientation, or any other sensor information), a capability for communicating usable SA instance information to an application, or a capability for reporting about SA instance usage by the WTRU.

[0120] Additionally, as would be understood by those possessing an ordinary skill in the art based on the present description, SA consumer 350 may change location, position or orientation, and SA consumer 350 may re-evaluate SA rules to determine if one or more SA instances have become unusable. The WTRU may needto enforce this determination by informing an application that discovered SA instance may not be used anymore or by preventing the application from communicating with the SA instance associated service.

[0121] At 3452, SAMF 390 may notify SA producers 310 or service(s) associated with one or more SA instances about changes related to SA instances, changes in SAMF 390 or SA instance reporting information received from SA consumers 350. Reporting information may be needed by or useful to SA producer 310 or SA instance associated service(s) to obtain information about SA consumer 350. For example, the SA instance associated service may need to obtain the location information of SA consumer 350 or one or more nearby SA consumers.

[0122] At 365, SA consumer 350 may access the SA instance associated service. In an example, access may be provided on certain criteria such as SA consumer 350 at 355 has determined that the SA can be used, and provided, optionally, that SA consumer 350 has performed related service discovery tasks such as the EAS discovery method if needed. It can be appreciated that the communication with the associated SA instance service may be configured by the WTRU, based on evaluating SA policy rules and determining valid SA instances. For example, the WTRU may request the creation of a PDU session or request a network slice that is required to communicate with the SA instance associated service.

[0123] FIG. 4 illustrates a signaling diagram 400 of several SA management methods that may be performed with system architecture 300 of FIG. 3. Diagram 400 includes a SA producer410, such as a WTRU or AF, for example, communicatively coupled to a SAMF 490 and a SA consumer 450, such as a WTRU or AF, for example.

[0124] At 405, the requestor (e.g., SA consumer 450) may discover information about existing SA instances. SA consumer 450 may send a SA discover request (1a) to SAMF 490. The SA discover request may include SA discovery information as described herein. For example, the SA type may be included in the discovery request to discover SA instances of that type, and other lEs of the SA instances that present the corresponding characteristics. The SA discovery information may be used by SAMF 490 to filter existing SA instances for the purpose of discovery. For example, the SA discover request may include SAID(s) used by SAMF 490 to identify SA instances matching the SAIDs. For example, the SA discover request may include SASID(s) and SASC(s) used by SAMF 490 to identify SA instances providing the corresponding service.

[0125] Upon receiving the SA discover request, SAMF 490 may identify SA instances matching the parameters of the discovery filters included in the request. SAMF 490 may send a successful SA discover response (1b) to SA consumer 450. The SA discover response may include the SA instance information corresponding to the discovery filters. If SAMF 490 has not discovered any SA instances, the SA discover response may indicate failure and may include a failure reason.

[0126] As would be understood, the SA discovery method described herein may happen between SA producer410 and SAMF 490 (not shown in the figure) for the purpose of discovering SA instances.

[0127] At 415, the requestor (e.g., SA consumer 450) may subscribe to receive notifications from SAMF 490. The SA consumer 450 may send a SA subscribe request (2a) to SAMF 490. The SA subscribe request may include information indicating the event types that the requestor registers for. For example, SA consumer 450 may subscribe to be notified of new SA instances available in close location of SA consumer 450. In another example, SA consumer 450 may subscribe to be notified of changes to the SA instances that are used by SA consumer 450. In another example, SA consumer 450 may provide trajectory information that indicate the anticipated trajectory of SA consumer 450. SAMF 490 may use this anticipated trajectory information to determine which SA instances are likely to be close to SA consumer 450 at a future time so that SAMF 490 may provide the SA information in advance of SA consumer 450 coming close to the SA.

[0128] Upon receiving the SA subscribe request, SAMF 490 may create a subscription according to the subscribe request parameters. SAMF 490 may send a successful SA subscribe response (2b) to SA consumer 450. The subscribe response may include a subscription identifier corresponding to the newly created subscription. If SAMF 490 has not created a subscription based on the SA subscribe request parameters, the subscribe response may indicate failure and may include a failure reason.

[0129] As would be understood, the SA subscription and notification method described herein may happen between SA producer 410 and SAMF 490 (not shown in the figure) for the purpose of receiving event information affecting SA instances.

[0130] At 425, the requestor (e.g., SA consumer 450) may register to SAMF 490. SA consumer 450 may send a SA register request (3a) to SAMF 490. The register request may include information identifying SA consumer and characteristics about the SA consumer such as the SA consumer spatial modeling capability, sensor capabilities and services of interest. The register request may indicate that SAMF 490 is authorized and has the user consent to obtain information about SA consumer 450 from the 5GC, such as the requestor location. SAMF 490 may store the provided information and use the provided information when receiving SA management requests from SA consumer 450. For example, SAMF 490 may obtain the location of SA consumer 450 from the 5GC to determine SA instances when SA consumer 450 performs the SA discover method. In some deployments, it can be appreciated that the registration method may create an implicit registration to SAMF 490, resulting in the requestor being automatically subscribed to events affecting SA instances.

[0131] SAMF 490 may send a successful SA register response (3b) to SA consumer 450. The register response may include a registration identifier corresponding to the newly created registration. If SAMF 490 has not accepted the registration, the register response may indicate failure and may include a failure reason.

[0132] As would be understood, the SA registration method described herein may happen between SA producer410 and SAMF 490 (not shown in the figure) for the purpose of registering to SAMF 490.

[0133] At 435 (collectively referring to 435a and 435b, the requestor (e.g., SA consumer 450) may report on SA instance usage. SA consumer 450 may send a SA report request (4a) to SAMF 49O.The report requestmay include information identifying SA consumer 450 and SA usage information from SA consumer 450. For example, SA usage information may include the SAID, the application using the SA instance, the location, and the position and orientation of SA consumer 450. The report request may indicate to SAMF 490 that the SA information that was received from SAMF 490 was indeed used. In one example, SAMF 490 may send SA information in anticipation that SA consumer 450 may soon be close to the SA. SA consumer 450 may then not come close to the SA and therefore never send a report that indicates that the SA information was used. In a second example, SAMF 490 may send SA information in anticipation that SA consumer 450 may soon be close to the SA. SA consumer 450 may then come close to the SA and therefore send a report that indicates that the SA information was used.

[0134] If SA producer 410 associated with the SA instance or the SA instance associated service have subscribed to receive SA reporting information, SAMF 490 may obtain further information associated with SA consumer 450 from the 5GC (e.g., 5GC location), and may report notification (4b) SA producer 410 or associated SA service of the report information obtained from SA consumer 450 or from the 5GC. SAMF 490 may send a successful SA report response (4c) to SA consumer 450. The report response may indicate that the SA report was successfully received or may indicate failure with a failure reason otherwise.

[0135] Alternatively, reporting may be triggered by SA producer 410 or SA instance associated service. SA producer 410 or SA instance associated service may send a SA report request (4d) to SAMF 490. The report request may indicate that reporting is needed for one or more SA instances. The report request may include the SAID, and a list of report information needed, such as the information about SA consumer 450, application using the SA instance, the location, and the position and orientation of SA consumer 450. Upon receiving the SA report notification, SAMF 490 may determine if it already has the requested SA report information. If SAMF 490 determines that it has the requested information, it may skip steps 4e and 4f, and continue the method in 4g.

[0136] If SAMF 490 determines that it does not have the requested report information, SAMF 490 may send a SA report notification (4e) to SA consumer 450 to request a report update. The SA report notification may include the SAID, and a list of report information needed, such as the information about SA consumer 450 identity, application using the SA instance, the location, and the position and orientation of SA consumer 450. SA consumer 450 may reply to the SA report notification by sending a SA report notification response (4f) to SAMF 490.

[0137] Upon determining the SA report information requested by SA producer 410 in 4d or receiving a SA report notification response from SA consumer 450 or SA instance associated service in 4f, SAMF 490 may send a SA report response (4g) to SA producer 410. The SA report response may include information determined in 4d or obtained in 4f.

[0138] At 445, the requestor (e.g., SA producer 410) may provision SA instances. SA producer 410 may send a SA provision request (5a) to SAMF 490. The SA provision request may include information identifyingSA producer 410 and SA instance information as described. Upon receiving the provision request, SAMF 490 may create a SA instance resource based on the SA instance information received in the provision request.

[0139] If SAMF 490 identifies any subscription for new SA instance, SAMF 490 may send a SA provision notification (5b) to the subscriber(s), providing the respective subscription identifiers to each subscriber and the new SA instance information to in the notification message.

[0140] Although the SA provision notification may be triggered by the provision request to SAMF 490, the SA provision notification may be triggered by other events. For example, SAMF 490 may receive location information related to SA consumer 450 and based on the location information, determine to send SA consumer 450 a notification with information about one or more SA instances that are close to SA consumer 450 or expected to soon be close to SA consumer 450.

[0141] SAMF 490 may send a SA provision response (5c) to SA producer 410. The provision response may contain an indication of success if the one or more SA instances was successfully provisioned and may include information that identifies each provisioned SA instance, such as a URI and SAID. Otherwise, SAMF 490 may include an indication of failure and a failure reason.

[0142] As would be understood, the SA provision method described herein may happen between SA consumer 450 and SAMF 490 (not shown in the figure) for the purpose of provisioning SA instances to SAMF 490, and that SA consumer 450 may be a WTRU.

[0143] At 455, the requestor (e.g., SA producer 410) may enable or disable one or more SA instances. SA producer 410 may send a SA enable request or SA disable request (6a) to SAMF 490. The enable / disable request may include information identifying a SA instance, such as a SAID. Upon receiving the enable / disable request, SAMF 490 may enable or disable the SA instance.

[0144] If SAMF 490 identifies any subscription for SA instance enabling or disabling, SAMF 490 may send a SA enable or SA disable notification (6b) to the subscriber(s), providing the respective subscription identifiers to each subscriber and indicating which SA has been enabled or disabled.

[0145] SAMF 490 may send a SA enable or SA disable response (6c) to SA producer 410. The enable / disable response may contain an indication of success if the one or more SA instances was successfully enabled or disabled and may include information that identifies each enabled or disabled SA instance. Otherwise, SAMF 490 may include an indication of failure and a failure reason.

[0146] As would be understood, the SA enable and disable method described herein may happen between SA consumer 450 and SAMF 490 (not shown in the figure) for the purpose of enabling and disabling SA instances.

[0147] At 465, the requestor (e.g., SA producer 410) may modify a SA instance. SA producer 410 may send a SA modify request (7a) to SAMF 490. The modify request may include information identifying SAinstances (e.g., SAID(s)) and information indicating changes to the SA instance. Upon receiving the modify request, SAMF 490 may modify the resource associated with the SA instance indicated in the modify request.

[0148] If SAMF 490 identifies any subscription for SA instance modification, SAMF 490 may send a SA modify notification (7b) to the subscriber(s), providing the respective subscription identifiers to each subscriber and indicating which SA has been modified and may include SA instance information of the modified SAs.

[0149] SAMF 490 may send a SA modify response (7c) to SA producer 410The modify response may contain an indication of success if the one or more SA instances was successfully modified and may include information that identifies each modified SA instance. Otherwise, SAMF 490 may include an indication of failure and a failure reason.

[0150] As would be understood, the SA modify method described herein may happen between SA consumer 450 and SAMF 490 (not shown in the figure) for the purpose of modifying SA instances.

[0151] At 475, the requestor (e.g., SA producer 410) may delete a SA instance. SA producer 410 may send a SA delete request (8a) to SAMF 490. The delete request may include information identifying one or more SA instances (e.g., SAID(s)). Upon receiving the delete request, SAMF 490 may delete the resource associated with the SA instance indicated in the delete request.

[0152] If SAMF 490 identifies any subscription for SA instance deletion, SAMF 490 may send a SA delete notification (8b) to the subscriber(s), providing the respective subscription identifiers to each subscriber and indicating which SA has been deleted.

[0153] SAMF 490 may send a SA delete response (8c) to SA producer 410. The delete response may contain an indication of success if the one or more SA instances was successfully deleted and may include information that identifies each deleted SA instance. Otherwise, SAMF 490 may include an indication of failure and a failure reason.

[0154] As would be understood, the SA delete method described herein may happen between SA consumer 450 and SAMF 490 (not shown in the figure) for the purpose of deleting SA instances.

[0155] It is important to point out that the steps that are shown in FIG. 4 may take place in any order, including orders that are different than the order that is presented in FIG. 4. For example, a SA subscribe operation 415 may be followed by a SA provision operation 445. Also, a SA provision operation 445 may be followed by a SA subscribe 415 operation.

[0156] A SA policy may be used including SA policy principles. A WTRU may be pre-provisioned with static SA instances or may have previously discovered SA instances. A WTRU may use a SA instance information (e.g., use information associated with the SA instance) to establish connectivity with, and make a service request to, the service associated with the SA instance. For example, a WTRU may use the SASID and SASCI to establish connectivity to the data network where the service is attached and to send a request to the service endpoint. A WTRU may need to determine if the one or more SA instances (e.g., static, or previouslydiscovered) is valid and if the WTRU can access the service associated with the SA instance. For example, a WTRU may have moved such that the WTRU location, position or orientation may change resulting in one or more SA instances that cannot be used anymore.

[0157] Thus, the WTRU may need to determine whether a SA instance is valid or not as accessing services associated with invalid SA instances (e.g., SA instances that cannot be displayed) may result in wasting bandwidth, computing resources, or shortening the battery life of the WTRU. However, deciding to delay reception of SA instance information until the information is absolutely needed may result in receiving the information too late and harming user experience.

[0158] A WTRU may have spatial modeling capabilities that may allow the WTRU to locally determine the usability of one or more SA instances by performing spatial modeling. In other words, a WTRU may have the required computing capabilities to perform the needed spatial modeling calculations and to determine whether a SA instance can be used or not. Spatial modeling may not be supported by a WTRU due to the high computing power needed for spatial modeling. An alternative method may be needed to determine whether a SA instance can be used by the WTRU.

[0159] SA policy may be provided or pre-provisioned on the WTRU, and the SA policy may assist with local determination of SA instances validity. A SA policy may indicate one or more conditions related to WTRU sensor values or range of values which may allow the use of a SA instance. For example, a SA policy may indicate that a WTRU should be at a precise location to use a SA instance. In other words, a WTRU may determine that a SA instance is valid if its location sensors indicate a location or location area indicated in a SA policy.

[0160] Furthermore, the SA policy may fuse sensor values to provide a set of conditions that must be met to determine whether a SA instance is valid. For example, to determine if an SA instance is valid, the SA policy may indicate that a WTRU should be at a determined location area, that the orientation of the WTRU should have a specific pitch, azimuth and roll value, and that the WTRU viewport should have a certain width and height (e.g., possibly expressed in degrees or in tiles). Pitch, azimuth (e.g., yaw) and roll are values provided by the accelerometer sensor in a WTRU and may be used to determine a specific orientation in space of the WTRU.

[0161] SA policy Information may be included. The SA policy may be composed of one or more SA rules, and each SA rule may be applicable to a SA instance or group of SA instances. The SA instance information elements may be present in a SA rule to identify the one or more SA instances that the SA rule applies to. Additionally, the following information elements may be present in a SA rule.

[0162] The SA validity criteria may indicate validity conditions that may be evaluated by a WTRU to determine if a SA instance is valid. The validity criteria may include general criteria values such as time, location, PLMN, network slice availability, etc. Additionally, the validity criteria may include spatial criteria, such as the WTRU orientation, viewport size, speed, acceleration, and may include more advanced spatial criteria,depending on the sensor capabilities of the WTRU (e.g., lidar, video, radar, etc.). Additionally, the validity criteria may include detection of available wireless networks (e.g., cellular, WiFi, etc.) orwireless devices (e.g., Bluetooth, NFC, etc.).

[0163] The SA sensor requirements may indicate the requirements of the one or more sensors used to evaluate the SA validity criteria conditions. SA sensor requirements may include sensor measurement type, sensor measurement accuracy and precision levels, and measurement frequency. For example, a SA instance may require a certain level of precision (e.g., fine location, coarse location, etc.), or may require a certain measurement speed or frequency to determine the SA instance validity. A WTRU that cannot meet the sensing requirements associated with a SA instance may not consider the SA instance valid.

[0164] The SA monitoring conditions may indicate the conditions under which a SA policy should be evaluated and reported on. SA monitoring conditions may include SA policy re-evaluation triggers (e.g., WTRU location change, WTRU orientation change, etc.), and a frequency, interval, or periodicity for SA policy re- evaluation. For example, certain SA instances may require a frequent re-evaluation of validity while other may require a re-evaluation only if the user location or orientation changes. The parameter indicates to the WTRU the frequency and conditions for re-evaluating or reporting on the SA validity.

[0165] FIG. 5 illustrates a signaling diagram 500 of a method for a SA consumer 550, such as a WTRU, for example, to determine the validity of one or more SA instances. For example, a WTRU may determine the validity of a SA instance by comparing WTRU sensor data with the SA policy. SA consumer 550 may communicate with an SAMF 590 and an associated SA instance service 595, such as an AF, for example.

[0166] At 505, SA consumer 550 may have been pre-provisioned with one or more SA instances and a SA policy. Alternatively, SA consumer 550 may have performed a SA discovery method with SAMF 590 as described herein. This discovery method may include a SA discovery request being sent by SA consumer 550 to SAMF 590. The SA discovery response from SAMF 590 to SA consumer 550 may include the SA policy in the SA discovery response.

[0167] At 515, SA consumer 550 may determine valid SA instances from the multiplicity of the discovered SA instances. The validity determination may be based on the obtained SA policy as described and may include WTRU sensor readings. An advantage of 515 enables SA consumer 550 to receive one or more SA instance information and, at a later time, determine the validity of the received one or more SA instances. Thus, SA instance information may be ''pre-loaded1' on SA consumer 550 and used when the SA instance becomes valid.

[0168] At 525, SA consumer 550 may configure the connectivity according to the determined valid SA instances. For example, in the case of a WTRU acting as SA consumer 550, the WTRU may use the SASID, the SASCI or the SATD to configure the connectivity to the service associated with a valid SA instance. Similarly, the WTRU may block traffic from being sent to the SA instance associated services for the SA instances that are invalid.

[0169] At 535, SA consumer 550 may send a SA report to SAMF 590 to indicate the SA instances that have been determined valid. Based on the reporting information, SAMF 590 may inform SA producer or SA instance associated service about the usage of the SA instance associated services and may provide information about the corresponding WTRU, as described herein.

[0170] At 545 and 555, SA consumer 550 may access associated SA instance service 595 of a determined valid SA instance. Associated SA instance service 595 may provide SA media content to SA consumer 550 such that SA consumer 550may render the SA media content.

[0171] Not specifically shown in Fig. 5, SA consumer 550 may re-evaluate the SA policy based on the SA monitoring conditions and may determine the validity of SA instances based on the SA monitoring conditions. For example, the SA monitoring conditions may require re-evaluation on a time basis, or on a sensor change basis (e.g., location, orientation, speed, etc.).

[0172] Spatial anchor reporting may include spatial anchor reporting principles. SA consumer 550 may determine the validity of SA instances based on a SA policy and may determine the usage of SA instance associated services based on SA instance validity and applications executing on SA consumer 550. SAMF 590 may assist in providing information about SA consumer 550 to associated SA instance services 595. The provided SA consumer 550 information may improve the SA media content provided by associated SA instance service 595. For example, associated SA instance service 595 may benefit from obtaining information on SA consumer 550 location, position, and orientation via SAMF 590. In cases with multiple valid SA instances, SAMF 590 may report consistent SA consumer 550 information to multiple associated SA instance services 595 and may reduce the number of reporting flows required by SA consumer 550. For example, in the case where SA consumer 550 is a WTRU, the WTRU may report WTRU location, position, and orientation information to the SAMF, and the SAMF may provide the received WTRU information to the SA instance associated services for each valid SA instance.

[0173] FIG. 6 illustrates a signaling diagram 600 illustrating a method for a SA consumer 650 (such as a WTRU, for example) to report usage of spatial anchors and provide assistance information to the SA instance associated service. SA consumer 650 communicates with a SAMF 690 and an associate SA instance service 695 (such as an AF, for example).

[0174] At 605, SA consumer 650 may determine a SA instance validity as described herein. At 615, SA consumer 650 may send a SA report to SAMF 690 to indicate the valid SA instances. The report may additionally indicate spatial or connectivity information about SA consumer 650. In an example, SA consumer 650 may include positioning information (e.g., location, position, orientation) based on the WTRU sensor data, and further include QoS information indicating the expected quality of service.

[0175] At 625, SAMF 690 may provide the obtained report information to associated SA instance service 695 associated with a valid SA instance. SAMF 690 may add additional information regarding SA consumer 650 obtained from the 5GC when SA consumer 650 is a WTRU. For example, the 5GC WTRU location maybe obtained through the NEF. Associated SA instance service 695 may use the WTRU assistance information to prepare for providing the media content for a specific WTRU or may use the information to provide more accurate media content.

[0176] At 635 and 645, SA consumer 650 may access associated SA instance service 695 of a determined valid SA instance. Associated SA instance service 695 may provide SA media content to SA consumer 650 such that SA consumer 650 may render the SA media content.

[0177] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magnetooptical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMSWhat is Claimed:

1. A wireless transmit and receive unit (WTRU), the WTRU comprising: a processor; and a transceiver operably coupled to the processor, the transceiver and processor configured to: transmit a first message to a network function to obtain information about at least one spatial anchor (SA); receive a second message indicating information about the at least one SA; determine a validity status of the at least one SA based on the information received in the second message; communicate with at least one service associated with a valid one of the at least one SA; and consume content provided by the at least one service.

2. The WTRU of claim 1 , the transceiver and processor further configured to: report valid SA information to the network function.

3. The WTRU of claim 1 , wherein the SA comprises an association between a three- dimensional (3D) location and service information.

4. The WTRU of claim 3, wherein consuming content includes obtaining virtual media from the at least one service to be displayed at the 3D location.

5. The WTRU of claim 1 , wherein the first message includes SA discovery information.

6. The WTRU of claim 5, wherein the SA discovery information includes at least one of a SA identifier (SAID), a SA consumer location and orientation, a SA service identifier (SASID) and a SA service characteristics (SASC).

7. The WTRU of claim 1 , wherein the second message indicating information about the at least one SA includes SA instance information.

8. The WTRU of claim 7, wherein the SA instance information includes SA service connection information (SASCI).

9. The WTRU of claim 1, wherein the communication with at least one service is based on connectivity to a SA service.

10. The WTRU of claim 9, wherein the SA service connectivity uses a SA service connection information (SASCI) provided in the received second message.

11. A method performed in a wireless transmit and receive unit (WTRU) for managing spatial anchors (SA), the method comprising: transmitting a first message to a network function to obtain information about at least one spatial anchor (SA); receiving a second message indicating information about the at least one SA; determining a validity status of the at least one SA based on the information received in the second message; communicating with at least one service associated with a valid one of the at least one SA; and consuming content provided by the at least one service.

12. The method of claim 11, further comprising reporting valid SA information to the network function.

13. The method of claim 11 , wherein the SA comprises an association between a three- dimensional (3D) location and service information.

14. The method of claim 13, wherein consuming content includes obtaining virtual media from the at least one service to be displayed at the 3D location.

15. The method of claim 11 , wherein the first message includes SA discovery information.

16. The method of claim 15, wherein the SA discovery information includes at least one of a SA identifier (SAID), a SA consumer location and orientation, a SA service identifier (SASID) and a SA service characteristics (SASC).

17. The method of claim 11 , wherein the second message indicating information about the at least one SA includes SA instance information.

18. The method of claim 17, wherein the SA instance information includes SA service connection information (SASCI).

19. The method of claim 11 , wherein the communication with at least one service is based on connectivity to a SA service.

20. The method of claim 19, wherein the SA service connectivity uses a SA service connection information (SASCI) provided in the received second message.