Methods, architectures, apparatus and systems for local mobile member communicate wireless / transmission

Abstract

Processes, methods, architectures, apparatuses, systems, devices, and computer program products for a local mobile meta-universe service enabler, such as an enabler implemented in a wireless transmit / receive unit (WTRU). For example, a method may include determining, by a WTRU service enabler hosted by a WTRU, that one or more application clients hosted by the WTRU are of interest in available local content. The method may include obtaining, by the WTRU service enabler, the available local content. The method may include providing, by the WTRU service enabler, the available local content to the one or more application clients.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 394,171, filed on August 1, 2022, which is incorporated herein by reference. Technical Field

[0002] The present disclosure relates generally to the fields of communications, software, and coding, including, for example, methods, architectures, apparatuses, and systems related to a local mobile metaverse wireless / transmit receive unit (WTRU) service enabler. Background Art

[0003] Devices with extended reality (XR) capabilities, such as augmented reality (AR) devices, can allow users to perceive digital overlays on their local environment. Fifth generation (5G) New Radio (NR) system enhancements will be desirable to address such use cases, such as the enabling of local content. Summary of the Invention

[0004] In a representative embodiment, a WTRU may receive configuration information indicating interest information. For example, the interest information may include: (i) one or more application identifiers (IDs) associated with one or more applications of the WTRU; and (ii) for each of one or more anchor devices, the anchor device ID and filtering information indicating that a first application of the one or more applications is interested in the corresponding anchor device ID only if the WTRU's orientation relative to the corresponding anchor device and one or more other criteria are met. The WTRU may discover a first anchor device of the one or more anchor devices. The WTRU may apply the filtering information to the first anchor device and determine that the WTRU's orientation relative to the first anchor device and the one or more other criteria are met. The WTRU may transmit information indicating the application ID of the first application and the anchor device ID of the first anchor device to a server. The WTRU may receive information indicating a uniform resource indicator (URI) associated with the anchor device ID of the first anchor device from the server. The WTRU may use the URI to obtain content from a repository. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] A more detailed understanding can be obtained from the following detailed description given as an example in conjunction with the accompanying drawings. Like the detailed description, each figure in such drawings is an example. Therefore, the figures (Figures) and detailed description should not be considered as limiting, and other equally effective examples are possible and desirable. In addition, like reference numerals ("reference") in the drawings indicate like elements, and wherein: Figure 1A is a system diagram illustrating an example communication system; Figure 1B This diagram shows the Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system is shown in FIG. Figure 1C This diagram shows the Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) used within a communication system illustrated in FIG. Figure 1D This diagram shows the Figure 1A A system diagram of a further example RAN and a further example CN for use within the communication system illustrated in FIG. Figure 2 is a block diagram illustrating an example architecture for a local mobile metaverse wireless transmit / receive unit service enabler according to an embodiment; Figure 3 is a flow chart illustrating an example method implemented in a wireless transmit / receive unit (WTRU) according to an embodiment; Figure 4 is a signaling diagram illustrating example interest configuration, anchor detection, and interest verification according to an embodiment; Figure 5 is a signaling diagram illustrating an example of enabler server-based local content detection according to an embodiment; Figure 6 is a signaling diagram illustrating an example of rule-based local content availability detection according to an embodiment; Figure 7 is a signaling diagram illustrating an example of obtaining local content according to an embodiment; Figure 8 is a process diagram illustrating an example process for a WTRU to obtain content using an anchor device; Figure 9 is a process diagram illustrating another example process for a WTRU to obtain content using an anchor device; and Figure 10 is a process diagram illustrating yet another example process for a WTRU to obtain content using an anchor device. DETAILED DESCRIPTION

[0006] In the following detailed description, many specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples can be put into practice without some or all of the specific details set forth herein. In other examples, well-known methods, processes, components, and circuits have not yet been described in detail to avoid blurring the following description. Further, the embodiments and examples that are not specifically described herein can replace or be put into practice in conjunction with the embodiments and other examples described, disclosed, or otherwise explicitly, implicitly, and / or inherently provided (collectively referred to as "providing") as described herein. Although various embodiments in which devices, systems, equipment, etc. and / or any of its elements implement operations, processes, algorithms, functions, etc. and / or any part thereof are described and / or claimed herein, it should be understood that any embodiment described and / or claimed herein prescribes that any device, system, equipment, etc. and / or any of its elements are configured to implement any operation, process, algorithm, function, etc. and / or any part thereof.

[0007] Example Communication System The methods, apparatus, and systems provided herein are well-suited for communications involving both wired and wireless networks. Figures 1A-1D To provide an overview of various types of wireless devices and infrastructure, wherein various elements of the network can utilize the methods, apparatuses, and systems provided herein, perform the methods, apparatuses, and systems provided herein, are arranged according to the methods, apparatuses, and systems provided herein, and / or are adapted and / or configured for the methods, apparatuses, and systems provided herein.

[0008] Figure 1A 1 is a system diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content (such as voice, data, video, messaging, broadcast, etc.) to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources (including wireless bandwidth). For example, the communication system 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), single carrier FDMA (SC-FDMA), zero tail (ZT) unique word (UW) discrete Fourier transform (DFT) spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0009] like Figure 1AAs shown in FIG, a communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although 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” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include or be a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in the context of an industrial and / or automated process chain), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0010] The communication system 100 may also include 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, for example, to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or the network 112. By way of example, the base stations 114a, 114b may be any of a base transceiver station (BTS), a Node-B (NB), an eNode-B (eNB), a home Node-B (HNB), a home eNode-B (HeNB), a gNode-B (gNB), an NR Node-B (NR NB), a site controller, an access point (AP), a wireless router, and the like. Although 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.

[0011] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. Base station 114a and / or 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 licensed and unlicensed spectrum. A cell may provide coverage for wireless services in a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, one for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each or any sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0012] 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, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0013] More specifically, as noted above, the communication 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 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0014] In one 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-APro).

[0015] 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 New Radio (NR).

[0016] In one 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 jointly implement LTE radio access and NR radio access, e.g., using dual connectivity (DC) principles. Thus, the air interface utilized by the 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., eNBs and gNBs).

[0017] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi)), 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), etc.

[0018] Figure 1AThe base station 114b in the example may be, for example, a wireless router, a home Node-B, a home eNode-B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, 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 one 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 one 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 any of a small cell, a pico cell, or a femto cell. Figure 1A As shown in FIG, base station 114b may have a direct connection to the Internet 110. Therefore, base station 114b may not be required to access the Internet 110 via CN 106 / 115.

[0019] The RAN 104 / 113 may be in communication with the CN 106 / 115, 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 different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although Figure 1A Not shown, but it will be appreciated, the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that may employ any of GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or Wi-Fi radio technologies.

[0020] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides 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), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) from the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communication 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 / 114 or a different RAT.

[0021] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication 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 via different wireless links). Figure 1A The WTRU 102c shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and the base station 114b, which may employ an IEEE 802 radio technology.

[0022] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B , the WTRU 102 may include, among other things, 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 supply 134, a global positioning system (GPS) chipset 136, and / or other elements / peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the above elements while remaining consistent with an embodiment.

[0023] 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 associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. 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. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and transceiver 120 may be integrated together, such as in an electronic package or chip.

[0024] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., 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 one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In one 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.

[0025] Although the transmit / receive element 122 is Figure 1B Although depicted as a single element in FIG. 1 , the WTRU 102 may include any number of transmit / receive elements 122. For example, the WTRU 102 may employ MIMO technology. Thus, in an 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.

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

[0027] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data therefrom. The processor 118 may also output user data to 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 non-removable memory 130 and / or 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, or 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).

[0028] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control power to 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, etc.

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

[0030] The processor 118 may be further coupled to other components / peripherals 138, which may include one or more software and / or hardware modules / units that provide additional features, functionality, and / or wired or wireless connectivity. For example, the components / peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (e.g., for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulation (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, etc. Components / peripherals 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geo-location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0031] The WTRU 102 may include a full-duplex radio, for which transmission and reception of some or all signals (e.g., associated with specific subframes for both uplink (e.g., for transmission) and downlink (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 hardware (e.g., a choke) or via signal processing performed by a processor (e.g., a separate processor (not shown) or via the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio, for which transmission and reception of some or all signals (e.g., associated with specific subframes for both uplink (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

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

[0033] The RAN 104 may include eNode-Bs 160a, 160b, 160c, although 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 receive wireless signals from, the WTRU 102a.

[0034] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in uplink (UL) and / or downlink (DL), etc. Figure 1C As shown in FIG, eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

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

[0036] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c 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, and 102c, activating and deactivating bearers, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and 102c, and the like. The MME 162 may also provide a control plane function for facilitating switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

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

[0038] 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.

[0039] 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 be in communication 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 other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0040] Even though the WTRU Figures 1A to 1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may employ (eg, temporarily or permanently) a wired communication interface with a communication network.

[0041] In a representative embodiment, the other network 112 may be a WLAN.

[0042] 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 to or an interface with a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating from outside the BSS and destined for a STA may arrive through the AP and be delivered to the STA. Traffic from a STA to a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within a BSS may be sent through the AP, for example, where a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between the source and destination STAs (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0043] When using 802.11ac infrastructure operation mode or a similar operation mode, the AP can transmit beacons on a fixed channel (such as a primary channel). The primary channel can be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, STAs (e.g., each STA) including the AP can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA can back off. One STA (e.g., only one station) can transmit at any given time in a given BSS.

[0044] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a primary 20 MHz channel combined with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0045] Very high throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels or by combining two non-contiguous 80 MHz channels (which may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data can be passed through a segment parser that can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be performed separately on each stream. The streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the media access control (MAC) layer, entity, etc.

[0046] The operating mode below 1 GHz is supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to the channel operating bandwidth and carrier used in 802.11n and 802.11ac. 802.11af supports 5 MHz bandwidth, 10 MHz bandwidth and 20 MHz bandwidth in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz bandwidth, 2 MHz bandwidth, 4 MHz bandwidth, 8 MHz bandwidth and 16 MHz bandwidth using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / machine type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, for example, limited capabilities, including support for (e.g., only support for) certain and / or limited bandwidths. MTC devices may include batteries whose battery life is above a threshold (e.g., to maintain very long battery life).

[0047] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for a STA that supports (e.g., only supports) a 1 MHz mode (e.g., an MTC-type device), the primary channel can be 1 MHz wide, 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 can depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which only supports the 1 MHz operating mode) transmitting to the AP, the entire available frequency band may be considered busy, even if most of the frequency band is still idle and may be available.

[0048] In the United States, 802.11ah can use the available frequency band from 902 MHz to 928 MHz. In South Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 916.5 MHz to 927.5 MHz. Depending on the country code, the total available bandwidth for 802.11ah ranges from 6 MHz to 26 MHz.

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

[0050] The RAN 113 may include gNBs 180a, 180b, and 180c, although it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from the WTRUs 102a, 102b, and 102c. 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 one embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation techniques. 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 one embodiment, the gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from the gNB 180a and gNB 180b (and / or gNB 180c).

[0051] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, 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 the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., including different numbers of OFDM symbols and / or durations of varying absolute time).

[0052] 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 a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without also accessing another RAN (e.g., such as the eNode-Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect to the gNBs 180a, 180b, 180c while also communicating / connecting to another RAN, such as the eNode-Bs 160a, 160b, 160c. For example, the 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 a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may serve as mobility anchors for the WTRUs 102a, 102b, 102c and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRUs 102a, 102b, 102c.

[0053] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown in , gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0054] Figure 1DThe CN 115 shown in FIG may include at least one AMF 182 a, 182 b, at least one UPF 184 a, 184 b, at least one session management function (SMF) 183 a, 183 b, and at least one data network (DN) 185 a, 185 b. Although each of the aforementioned elements is depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by entities other than the CN operator.

[0055] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b, for example, to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service utilized by the 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, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 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 Wi-Fi.

[0056] The SMFs 183a and 183b can connect to the AMFs 182a and 182b in the CN 115 via the N11 interface. The SMFs 183a and 183b can also connect to the UPFs 184a and 184b in the CN 115 via the N4 interface. The SMFs 183a and 183b can select and control the UPFs 184a and 184b and configure traffic routing through the UPFs 184a and 184b. The SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. The PDU session type can be IP-based, non-IP-based, Ethernet-based, and so on.

[0057] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface. These gNBs may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, for example, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184a, 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 downlink packets, providing mobility anchoring, etc.

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

[0059] Given that Figures 1A to 1D as well as Figures 1A to 1D

[0066] As described herein, one or more or all of the functionality described herein with respect to any of the following may be performed by one or more emulation elements / devices (not shown): the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other element / device(s) described herein. The emulation devices may be one or more devices configured to emulate one or more or all of the functionality described herein. For example, the emulation devices may be used to test other devices and / or simulate network and / or WTRU functionality.

[0060] The simulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or in an operator network environment. For example, the one or more simulation devices can perform 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 simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to another device for testing purposes and / or can use over-the-air wireless communication to perform testing.

[0061] The one or more simulation devices can perform one or more (including all) functions without being implemented / deployed as a part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test lab and / or in a non-deployed (e.g., test) wired and / or wireless communication network to realize the test of one or more components. The one or more simulation devices can be test equipment. The direct RF coupling and / or wireless communication carried out via RF circuits (e.g., which can include one or more antennas) can be used by the simulation device to transmit and / or receive data.

[0062] Wireless Transmitter / Receiver Unit Service Enabler The term "hosted on the WTRU" is used in this disclosure. For example, an application client may be hosted on the WTRU and referred to as a "WTRU-hosted application". A WTRU-hosted application may be an application that runs in the terminal equipment (TE) portion of the WTRU. A WTRU-hosted application may also be an application that runs on a device tethered to the WTRU via a protocol such as Bluetooth, PC5, or Wi-Fi (e.g., AR goggles, Bluetooth sensors, etc.). The terms WTRU-hosted application and application client are used interchangeably in this disclosure.

[0063] Example use case In the following example use cases, the following prerequisites may apply.

[0064] First, the user is using an AR display device, such as AR-capable glasses, a head-mounted display, a holographic display, smart glasses, or an optical see-through display. For simplicity, the term "AR-capable glasses" refers to this collection of devices. The AR-capable glasses may be tethered to a WTRU carried by the user, or alternatively, may have WTRU capabilities.

[0065] Second, the WTRU is capable of performing device-to-device communications using protocols such as WiFi, Bluetooth, and PC5.

[0066] Third, the WTRU hosts a WTRU service enabler that interfaces with WTRU-hosted applications and network services. WTRU-hosted applications include applications running on tethered devices such as AR-capable glasses. Network services include enabler servers hosted by mobile network operators (MNOs) or third-party service providers.

[0067] In this use case, the WTRU service enabler and enabler server are configured with information related to the user's interests. For example, the user's interests may include what services the WTRU-hosted application is associated with, what content the WTRU-hosted application is associated with, what products the WTRU-hosted application is associated with, etc.

[0068] As the user travels, the WTRU detects the availability of local content. Local content is information that the WTRU can receive related to its local environment. For example, local content may include information about products sold in stores close to the WTRU, information about nearby public transportation services, and so on. Local content may be associated with a specific location, AR asset, or data; and local content may be displayed to the user on AR-capable glasses.

[0069] The WTRU detects the availability of local content by receiving information (e.g., a device identifier or content identifier) ​​via device-to-device communication and providing the information to the WTRU service enabler. The WTRU service enabler then uses the information to obtain the local content from storage, from an application server, or directly from another device (e.g., the device that advertised the content or a different device). The local content can then be provided to a WTRU-hosted application (e.g., an application running on AR glasses) and displayed to the user.

[0070] 5G system enhancements are needed to enable the use cases described above.

[0071] 5G system enhancements are needed to enable the WTRU to detect the availability of local content. The enhancements should describe how the WTRU detects the availability and what information is detected. For example, the WTRU may need to detect the device identifier, the device or service type, the location of the device, etc. The WTRU may operate in an environment where there are many devices advertising content. Therefore, mechanisms are needed to allow the WTRU service enabler to be configured with information that helps it determine what local content is of interest to the user and should be provided to the WTRU-hosted application and what local content should be filtered from the user.

[0072] 5G system enhancements are needed so that a WTRU-hosted WTRU service enabler can use the detected information to obtain local content. Obtaining local content may involve providing information to a WTRU application client so that the WTRU application client can obtain the content, enabling interaction between the WTRU service enabler and a WTRU service enabler hosted in a different device to obtain the content, or enabling interaction between the WTRU service enabler and an application server to obtain the content.

[0073] Example Architecture Figure 2 An example architecture 200 is shown that supports localized mobile metaverse services in a 5G system.

[0074] The WTRU 202 may host one or more application clients 204 that interface with an application server 206. For example, the WTRU 202 may be the WTRU 102 having one or more AR capabilities. This interface with the application server 206 may be used to exchange application data traffic between the application client 204 and the application server 206. For example, the application client 204 may be provided with a uniform resource indicator (URI) for a piece of content, and the application client 204 may retrieve the content from the application server 206. Figure 2 An example is shown in which the application client 204 communicates with the application server 206 via a 3GPP core network. However, the application client 204 may communicate with the application server 206 hosted on the WTRU 202 via direct signaling, such as PC5, Wi-Fi, or Bluetooth.

[0075] The WTRU 202 may host a WTRU service enabler 208 that interfaces with an enabler server(s) 212. The WTRU service enabler 208 provides support functions required for the application client(s) 204. The WTRU service enabler 208 serves to retrieve configuration information from the enabler server 212 to enable the exchange of application data traffic. The WTRU service enabler 208 also performs discovery of available application servers 206 in the data network. It also supports the detection of mobility events. The WTRU service enabler 208 interacts with the application client(s) 204 via an interface referred to as the L-5 interface L5. The WTRU service enabler 208 may store information about elements or devices in the environment surrounding the WTRU 202 and make this information available to the application client 204 over the L-5 interface L5. The WTRU service enabler 208 functions described in this disclosure may be performed by or integrated into a service enabler architecture layer (SEAL) client. Functions, procedures, and messages described as part of the L5 interface can be executed on the SEAL-C interface. Functions, procedures, and messages described as part of the L1 interface can be executed on the SEAL-UU interface. The SEAL client, SEAL-C interface, and SEAL-UU interface are defined in 3GPP TS 23.434. Those skilled in the art should be familiar with the SEAL client, SEAL-C interface, and SEAL-UU interface.

[0076] The functionality described herein as part of the WTRU hosted application client 202 may be implemented by a Vertical Application Layer (VAL) client as described in 3GPP TS 23.434. Those skilled in the art will be familiar with VAL clients.

[0077] Functionality described herein as part of a WTRU-hosted application may be implemented by a VAL server as described in 3GPP TS 23.434. Those skilled in the art will be familiar with VAL servers. The service data network 210 may be deployed by a mobile network operator. The service data network 210 may host an enabler server 212. The enabler server 212 may interact with the application server(s) 206 via an L3 interface. The enabler server 212 performs a registration process with the application server(s) 206. The registration process may allow the application server(s) 206 to provide the enabler server 212 with information about content available to the user. For example, the information may indicate location and positioning information associated with a piece of content. The information may further indicate which users or user groups are allowed to access the content. The information may include security keys or certificates that may be used to access the content and indicate what security procedures are required to access the content. The information may include a location (i.e., URI) from which the content may be retrieved, as well as information related to the content (e.g., content type and actions associated with local content discovery). The information may include a service provider identifier (ID) and a service type. The enabler server 212 functions described in this document may be performed by or integrated into a SEAL server. Functions, procedures, and messages described as part of the L3 interface may be performed over the SEAL-S interface. The SEAL server and SEAL-S interface are defined in 3GPP TS 23.434.

[0078] The enabler server 212 may store information about user preferences for certain types of content and the WTRU's ability to retrieve certain types of content. This information may be part of the interest filters discussed later in this disclosure.

[0079] The enabler server 212 also includes an L2 interface with the core network 214, which can be used to invoke a service application programming interface (API) of the core network 214. For example, the L2 interface can be used to invoke a network exposure function (NEF) API, which provides the service enabler 208 with the location of the WTRU or the network congestion level in the WTRU's current location. The NEF API is defined in 3GPP TS 29.522. Those skilled in the art should be familiar with the NEF API.

[0080] The interface between the WTRU service enabler 208 and the enabler server 212 may be referred to as an L1 interface. The L1 interface may enable the enabler server 212 to provide the WTRU service enabler 208 with information about content available to the WTRU 202 hosting the WTRU service enabler 208.

[0081] The enabler server 212 and the WTRU service enabler 208 may perform a process in which the enabler server 212 provides the WTRU service enabler 208 with information related to the interests of the WTRU-hosted application 204 that are associated with the interests of the enabler server 212. For example, the mobile network operator or the application server 206 may configure the enabler server 212 with interest information obtained from a user, and the enabler server 212 may provide this information to the WTRU service enabler 208. For example, a user (i.e., subscriber) may have used a web portal to configure his or her interests with the network operator. The network operator may store this information in the enabler server 212.

[0082] The enabler server 212 and the WTRU service enabler 208 may perform a process in which the WTRU service enabler 208 provides the enabler server 212 with information related to the interests of the WTRU hosted application 204. The enabler server 212 and the WTRU service enabler 208 may perform a process in which the WTRU service enabler 208 provides the enabler server 212 with information related to the interests of the WTRU hosted application 204. For example, the WTRU 202 or the WTRU application client / WTRU hosted application 204 may provide a graphical user interface (GUI) that allows a user to configure interest information in the WTRU service enabler 208, and the WTRU service enabler 208 may configure the enabler server 212 with the interest information obtained from the user.

[0083] The L1 interface may be a RESTful HTTP interface provided via the user plane.

[0084] The term "anchor device" is used throughout this document. An anchor device 216 may be a device whose location is fixed or known relative to other points in the world. As explained herein, an anchor device 216 may be a device that transmits a wireless signal identifying the device so that a second device (e.g., a WTRU) can receive the identification signal and use it to determine that the WTRU 202 is in the vicinity of the anchor device 216. The anchor device 216 may provide an anchor location for displaying AR content and / or may provide an access point to local content.

[0085] The location of the anchor device 216 may be known, as it is always assumed to be in a fixed position. Alternatively, the anchor device 216 may be a positioned WTRU. 3GPP TR 23.700-86 defines a positioned WTRU as "a WTRU whose location is known or can be known using Uu-based positioning. A positioned WTRU may be used to determine the location of a target WTRU using sidelink positioning."

[0086] The anchor device 216 and the WTRU 202 may perform a process in which the WTRU 202 determines its range or location relative to the anchor device 216. Alternatively, when the anchor device 216 is the WTRU being located, the WTRU 202 may detect the nearby presence of the anchor device 216 and then request location information for the anchor device 216 and use the location information to determine the location of the WTRU 202. The location information for the anchor device 216 may be obtained from the anchor device 216 using a PC5 sidelink positioning process, or from the network (i.e., from the enabler server 212 or a location service of the network). If the anchor device 216 broadcasts identification information and provides access to content (e.g., via an interface such as PC5, Wi-Fi, or Bluetooth), it may also be considered a local access point.

[0087] Example Method Figure 3 An example method 300 implemented in a WTRU 202 is illustrated. Beginning at step 302, the method includes determining, by a WTRU service enabler 208 hosted by the WTRU 202, that one or more application clients 204 hosted by the WTRU 202 are interested in available local content. At step 304, the method includes obtaining, by the WTRU service enabler 208, the available local content. At step 306, the method includes providing, by the WTRU service enabler 208, the available local content to the one or more application clients 204.

[0088] The method 300 may perform steps 302-306 in various ways. For example, step 302 may include receiving, by the WTRU service enabler 208, a message from the anchor device 216 indicating that local content is available. Additionally or alternatively, steps 302-306 may include querying, by the WTRU service enabler 208, the enabler server 212 for information related to the interest of the one or more application clients 204 in the available local content. Alternatively or additionally, steps 302-306 may include receiving, by the WTRU service enabler 208, a message from the enabler server 212 indicating that local content of interest to the one or more application clients 204 is available. Alternatively or additionally, steps 302-306 may include determining that the one or more application clients 204 are capable of using the available local content. Alternatively or additionally, steps 302-306 may include receiving, by the WTRU service enabler 208, from the enabler server 212, one or more anchor rules indicating one or more anchor devices associated with the one or more application clients 204's interest in the available local content. Alternatively or additionally, steps 302-306 may include: receiving, by the WTRU service enabler 208, an anchor indication from the one or more anchor devices 216; and performing, by the WTRU service enabler 208, at least one action specified in the anchor rule in response to receiving the anchor indication. Alternatively or additionally, steps 302-306 may include: obtaining available local content from the enabler server 212; and providing the available local content directly to the one or more application clients 204. Alternatively or additionally, steps 302-306 may include: receiving, from the enabler server 212, a uniform resource identifier (URI) for retrieving the available local content; and providing the uniform resource identifier to the one or more application clients 204.

[0089] Prerequisites The procedures in this disclosure describe how the WTRU service enabler 208 in the WTRU 202 may receive notifications regarding the availability of local content. The notification may come from logic within the WTRU service enabler 208 (e.g., as a result of obtaining an updated WTRU location), or it may come from the enabler server 212 as a notification message.

[0090] The enabler server 212 may use the collected information to determine whether to send a notification to the WTRU service enabler 208. For example, the enabler server 212 may be configured with information related to the user's interests (e.g., interest filters). The interest information or interest filters may include information related to the user's interests, likes, dislikes, and previous activities. The interest information may come from the application server 206 or the WTRU service enabler 208 associated with the WTRU 202. The interest information may also be information collected by the enabler server 212. For example, the enabler server 212 may have stored information related to services in which the user (i.e., the WTRU service enabler 208) has previously expressed interest. The terms "interest information" and "interest filters" are used interchangeably in this disclosure. An "interest filter" may contain "interest information" related to a WTRU-hosted application.

[0091] the term The European Telecommunications Standards Institute (ETSI) Group Specification (GS) Augmented Reality Framework (ARF) 004-2 defines a world anchor as "a fixed position relative to one or more elements of the real world." ETSI GS ARF 004-2 also states that a world anchor can be attached to a trackable object. ETSI GS ARF 004-2 defines a trackable object as "an element of the real world whose features are available and / or can be extracted."

[0092] In the example procedures shown in this disclosure, the WTRU 202 performs procedures with respect to the anchor device 216 via a wireless interface (e.g., PC5, Bluetooth, Wi-Fi, etc.). It should be appreciated that the anchor device 216 may be a passively trackable object, such as an image, symbol, or picture, that is detected by the WTRU 202 and used by the WTRU 202 to determine location information. For example, the anchor device 216 may be a barcode that is detected by a camera on the WTRU 202. The barcode information may be received by the WTRU service enabler 208 (e.g., in Figure 4 408 ) and is used to obtain information about the content and location represented by the trackable object (e.g., at Figure 4(See 414 and 416 of the WTRU documentation, discussed further below.) The WTRU service enabler 208 may use the content and location information from one or more trackable objects to build a world graph accessible to WTRU-hosted applications. In this sense, the world graph may be a service provided by the WTRU service enabler 208 to WTRU-hosted applications. ETSI GS ARF 004-2 defines a world graph as "a hierarchy of trackable objects and world anchors that represent real-world knowledge in a world representation sub-function." For example, the WTRU service enabler 208 may store the world graph as a resource tree accessible to WTRU-hosted applications. Thus, each WTRU-hosted application would not need to build its own world graph; the world graph built by the WTRU service enabler 208 may be shared by multiple WTRU-hosted applications. Alternatively, the WTRU service enabler 208 and the enabler server 212 may jointly provide the world graph. For example, the enabler server 212 may host the world graph, and the WTRU service enabler 208 may provide WTRU-hosted applications with access to the world graph content in the enabler server 212.

[0093] ETSI GS ARF 003 defines world capture functionality as functionality that delivers "information relevant to the localization of an AR device or real-world objects or analysis of the environment of an application. AR systems may embed various sensors designed to better understand the real-world environment and the pose (position and orientation) of real-world objects in that environment required for the AR system or to provide accurate registration of virtual objects in the real world..." As described above, the WTRU service enabler 208 may provide world capture functionality or may be interfaced to world capture functionality in the WTRU 202. For example, the WTRU service enabler 208 may be interfaced to sensors built into the WTRU 202 to obtain positioning, image, temperature, movement, and velocity information.

[0094] ETSI GS ARF 003 defines world analysis functionality as functionality that “may estimate the pose or movement of a real object or a device providing an AR experience. It may also identify or recognize elements present in the real world, or it may reconstruct a 3D map of the real world.” As described above, the WTRU service enabler 208 may provide world analysis functionality.

[0095] ETSI GS ARF 003 defines a world storage function as a function that "delivers information about the representation of the real world (e.g., information for relocalization, 3D object recognition and identification, AR anchoring) to other functions and sub-functions. Additionally, it receives information from other functions to update the representation of the world (e.g., 3D mapping, 3D object recognition), transforms the world representation (scene meshing), or extracts parts of the representation (object 3D segmentation) for AR anchoring functions." As described above, the enabler server 212 can provide the world storage function.

[0096] The functionality described as part of the WTRU service enabler 208 may be part of the WTRU's operating system, software environment, or software library.

[0097] 3GPP TR 23.700-86 defines a reference WTRU as “a WTRU that determines a reference plane and a reference direction in ranging-based service and sidelink positioning.” The anchor device 216 described in the present disclosure may be a reference WTRU.

[0098] 3GPP TR 23.700-86 defines a helper WTRU as "a WTRU that provides assistance with ranging / sidelink positioning when direct ranging / sidelink positioning between a reference WTRU and a target WTRU cannot be supported." For example, once the WTRU determines its position relative to the helper WTRU, the enabler server 212 may provide the WTRU service enabler 208 with information about the position of other devices, AR assets, or real-world elements relative to the helper WTRU. This information may be used by the WTRU service enabler 208 or a WTRU-hosted application to determine the WTRU's position relative to the other device or real-world element.

[0099] ETSI GS ARF 004-2 defines an AR asset as “any kind of content that is positioned and oriented in the real world to change the user’s experience” and states that “AR assets can be attached and arranged relative to the real world through the use of trackable objects and / or world anchors.”

[0100] Detect local content availability and determine interest Figure 42 shows a process in which the WTRU service enabler 208 receives a message from the anchor device 216 indicating the availability of local content. The WTRU service enabler 208 then performs a process to determine whether the application client 204 hosted on the WTRU 202 is interested in the local content. Interest in the content implies that the application client 204 can utilize the local content and should be provided with the content. If the WTRU service enabler 208 determines that one or more application clients 204 hosted on the WTRU 202 are interested in the local content, the WTRU service enabler 208 may initiate a process to obtain the local content so that it can be provided to the WTRU-hosted application.

[0101] At 402, the WTRU service enabler 208 may be configured with information regarding what local content is of interest to the application client 204 hosted in the WTRU 202. The configuration information may be received from the application client hosted on the WTRU 202, or the configuration information may be received from the enabler server 212. For example, when a WTRU-hosted application is installed, the WTRU-hosted application may be triggered to configure the information in the WTRU service enabler 208. Alternatively or additionally, when the WTRU-hosted application receives information from a user through a user interface (e.g., a GUI), the WTRU-hosted application may be triggered to configure the information in the WTRU service enabler 208. Alternatively or additionally, when the WTRU-hosted application is configured by the application server 206, the WTRU-hosted application may be triggered to configure the information in the WTRU service enabler 208. For example, the enabler server 212 may be triggered to configure information in the WTRU service enabler 208 when the WTRU service enabler 208 registers with the enabler server 212 or when the enabler server 212 receives information configured by the application server 206 using interest information.

[0102] The configuration may include any of the following information.

[0103] For example, the configuration information may include an application client ID. The identity of the application client 204 may be included in the configuration information so that the WTRU service enabler 208 may know which application client 204 to notify when local content is detected or obtained.

[0104] For example, the configuration information may include an anchor ID. The anchor ID may be used by the WTRU service enabler 208 to detect whether the indication sent by the anchor device 216 may indicate local content of interest to the application client. This information may be used by the WTRU service enabler 208 at 410. For example, detection of the anchor ID may indicate that the associated local content is of interest to the application, and 414 and 416 may be skipped. Alternatively, detection of the anchor ID may indicate that the WTRU service enabler 208 should proceed to 414 and 416 to verify whether the associated local content is of interest to the application client. The WTRU service enabler 208 may verify whether the associated local content is of interest to the application client because the WTRU's interest information may be stored in the enabler server 212 and the enabler server 212 may be configured with information mapping the anchor ID to content information. The anchor ID may identify the specific device associated with the local content of interest to the application client; in this case, 414 and 416 may be skipped. The anchor ID may identify the type of service, such as a restaurant. When the anchor ID identifies the type of service, 414 and 416 may be performed so that the WTRU service enabler 208 may verify whether the local content is associated with a restaurant of interest to the application client.

[0105] For example, the configuration information may include a service provider ID. When the anchor ID identifies a specific device associated with local content, the service provider ID may not be needed in the configuration information because the anchor ID will be sufficient to determine that the application client 204 is interested in associating local content.

[0106] For example, the configuration information may include range information. The range information may indicate that the application client 204 is only interested in local content if the WTRU 202 is within a certain range of the anchor device 216. The range may be expressed as a distance and an angle or orientation relative to the anchor device 216. The range information may also include the angle or orientation between the AR device and the anchor device 216. The orientation between the AR device and the anchor device may be expressed as a distance measurement. The orientation between the AR device and the anchor device may be expressed as a measurement of the angle between a point on the AR device and a point on the anchor device. The orientation between the AR device and the anchor device may be expressed as an indication of whether the anchor device is above or below the AR device. The orientation between the AR device and the anchor device may be expressed as an indication of whether the anchor device is behind or in front of a side of the AR device. This information may be used by the WTRU service enabler 208 at 410. For example, if the anchor device 216 is not within the indicated range of the anchor device 216, the WTRU service enabler 208 may determine not to proceed with 414 and 416. The range information may be considered a type of filtering criterion.

[0107] For example, the configuration information may include geofence information. The geofence information may indicate the location of an anchor device 216 that provides local content of interest to the WTRU application client 204 only when the WTRU 202 is within a certain range of the anchor device 216. This information may be used to help the WTRU 202 determine when to begin looking for an anchor indication from the anchor device 216 (e.g., at 406).

[0108] For example, the configuration information may include other types of filtering criteria. For example, the configuration information may include filtering criteria indicating that the application client 204 is only interested in local content at certain times of the day. As another example, the filtering criteria may include WTRU trajectory information. The application client 204 is only interested in local content if the anchor device 216 is following the trajectory of the local content. As another example, the filtering criteria may include WTRU battery status. The application client 204 is interested in local content but would prefer not to drain the WTRU battery. This information may be used by the serving WTRU service enabler 208 at 410. For example, if the filtering criteria do not match the current conditions and the WTRU service enabler 208 receives an anchor indication, 414 and 416 may be skipped.

[0109] At 404, the enabler server 212 is configured with information regarding what local content is of interest to the application client 204 hosted in the WTRU 202 (i.e., interest filters). The configuration information may be received from the WTRU service enabler 208. For example, the WTRU service enabler 208 may send information to the enabler server 212. The information may be sent to the enabler server 212 so that the enabler server 212 can authorize the WTRU 202 to receive the associated content and so that the enabler server 212 can detect that the WTRU 202 may be in the vicinity of the local content of interest. The information stored in the enabler server 212 may include the same information described above as being stored in the WTRU service enabler 208. The enabler server 212 may be able to independently detect the location of the WTRU so that it can notify the WTRU 202 of anchor devices 216 that may be in the vicinity of the WTRU 202. The information stored in the enabler server 212 may include the same information described above as being stored in the WTRU service enabler 208. Additionally, the information stored in the enabler server 212 may include the identity of the WTRU service enabler 208 .

[0110] The enabler server 212 may obtain the configuration information by calling a NEF API to obtain the configuration information from the UDR. For example, the configuration information may be stored as part of the WTRU's subscription information or as a group of the WTRU's subscription information.

[0111] A SEAL procedure, such as the GET VAL WTRU configuration request described in 3GPP TS 23.434, may be used by the configuration management client to send configuration information to the enabler server 212 (ie, the configuration management server).

[0112] At 406, the anchor device 216 may perform a procedure with respect to the WTRU 202 indicating the presence of the anchor device 216. The procedure may be that the anchor device 216 broadcasts its anchor ID. Additionally, the anchor device 216 and the WTRU 202 may perform a procedure so that the WTRU 202 can determine the range between the anchor device 216 and the WTRU 202. The range information may include the distance between the WTRU 202 and the anchor device 216, the orientation of the WTRU 202 and the anchor device 216, and whether the WTRU 202 is moving closer to or farther away from the anchor device 216. This procedure may occur via PC5 signaling.

[0113] At 408, the mobile terminated (MT) portion of the WTRU 202 may send a notification with the anchor ID and ranging information to the WTRU service enabler 208. An attention (AT) command may be used to send this information from the MT portion of the WTRU 202 to the WTRU service enabler 208 hosted in the TE portion of the WTRU 202.

[0114] At 410, the WTRU service enabler 208 may use the interest information configured at 402 to determine whether the anchor device 216 is associated with information of interest to the WTRU-hosted application client 204. As described above, if the interest information includes an anchor ID, which may have been received at 408, the WTRU service enabler 208 may determine to execute 412 and skip 414 through 418. As described above, if the interest information includes filtering information, the WTRU service enabler 208 may use the filtering information to determine that no WTRU-hosted application client 204 is currently interested in content associated with the anchor device 216 and 414 through 418 may be skipped. If the WTRU service enabler 208 determines that the WTRU-hosted application client 204 may be interested in content associated with the anchor device 216, the WTRU service enabler 208 may proceed to 414 to further verify whether the WTRU-hosted application client 204 should be provided with the content or only a portion of the content. For example, the application client 204 may be interested in obtaining information about what products are available in a location rather than the prices of the products (e.g., to display available products on a pair of AR goggles without displaying prices).

[0115] At 412, the information from the anchor notification at 408 may be forwarded to the app client, which uses the anchor ID to identify the local content and initiate an application layer process to obtain the associated content so that it can be displayed to the user (e.g., shown on the user's smart goggles).

[0116] At 414, the WTRU service enabler 208 may send an interest check request message to the enabler server 212. The interest check request message may include the WTRU hosted application client ID and the anchor ID. The enabler server 212 may compare the WTRU hosted application client ID and the anchor ID with the interest configuration received by the enabler server 212 at 404 to determine whether the WTRU hosted application should be provided with content. The enabler server 212 may then resolve the anchor ID into a URI pointing to the associated local content.

[0117] For example, the enabler server 212 may have been configured with resolution information indicating the association between each anchor ID and a URI. Alternatively, the enabler server 212 may query another server to perform the resolution. The URI may be a URI pointing to the associated local content.

[0118] At 416, the enabler server 212 may send an interest-check response to the WTRU service enabler 208 indicating to the WTRU whether the application client 204 should be provided with local content. The message may include a URI that may be used to retrieve the local content. The interest-check response may also include metadata associated with the content (e.g., location information, positioning information, content type, identity of the associated service provider, security protocols required to access the data, access keys for retrieving the data, etc.).

[0119] At 418, the WTRU service enabler 208 may perform a process to obtain local content or assist the WTRU application client 204 in obtaining local content. Example processes for obtaining local content are discussed later in this disclosure.

[0120] Enabler server-based detection of local content Figure 5 The diagram illustrates a process that may be performed in a scenario where detection of local content is performed by the enabler server 212. The enabler server 212 may be configured to periodically check whether it should send an enabler server notification message to the WTRU service enabler 208, or the enabler server 212 may be configured to check whether it should send an enabler server notification message to the WTRU service enabler 208 when the enabler server 212 receives a notification regarding a change in the WTRU's state. Figure 5The anchor device 216 need not be involved in the process because the enabler server 212 may detect that the WTRU 202 and the anchor device 216 are in proximity and provide information related to local content to the WTRU 202. For example, the enabler server 212 may receive notifications that the WTRU 202 is in a certain location, that the WTRU's battery is low, that the WTRU 202 is moving within a certain speed range, and so on. Upon receiving information related to the WTRU's status, the enabler server 212 may verify whether there is local content available to the WTRU 202 that matches the WTRU's interests and determine to send an enabler server notification to the WTRU service enabler 208. The enabler server notification may provide the WTRU service enabler 208 with information related to the local content.

[0121] At 502 and 504, similar to combining Figure 4 As discussed above at 402 and 404, the WTRU service enabler 208 and the enabler server 212 may be configured with information related to the WTRU's interests.

[0122] At 506, the enabler server 212 may initiate a process to obtain information related to the WTRU 202. For example, at 506, the enabler server 212 verifies the location of the WTRU. However, the enabler server 212 may initiate other processes to obtain information related to the enabler server 212. For example, the enabler server 212 may request information related to the speed of the WTRU 202 hosting the WTRU service enabler 208, the battery level of the WTRU 202 hosting the WTRU service enabler 208, the network congestion level in the location of the WTRU, etc. In some embodiments, instead of being sent to the WTRU 202, the request may be sent to another server or to the 5G core network via the NEF. For example, as described in 3GPP TS 23.434, the enabler server 212 (e.g., a location management server) may send a location information request to the location management client (e.g., the WTRU service enabler 208).

[0123] The enabler server 212 may agree with the WTRU service enabler 208 on how often to check the WTRU's location, depending on some parameters such as one or more mobility aspects of the user and / or how many anchor devices 216 are in a certain area (e.g., if there are many anchor devices 216, it may be more convenient to refresh the WTRU location more often), the range of the anchor devices 216 (e.g., anchors with a small range may experience refreshes of the WTRU location more often to see if there are new anchors and, therefore, new local content of interest), and possibly depending on the WTRU-hosted application (e.g., checking gas stations may require less frequent WTRU location updates than checking nearby public bathrooms).

[0124] The enabler server 212 may request information related to the WTRU's location from the WTRU service enabler 208. If suitable location services are available within the 5G system (5GS), the 5GS may be requested to provide information related to the WTRU's location.

[0125] Another trigger for verifying the WTRU's location may be if the WTRU application host and / or the user triggers the WTRU service enabler 208 to request some local content from the enabler server 212. For example, if the user wants to search for public restrooms or if the user remembers to inquire about nearby gift shops, such a request may trigger the WTRU side (e.g., the WTRU service enabler 208) to query the enabler server 212 for local content, if available.

[0126] In this case, the request may trigger the provision of WTRU location information to the enabler server 212 by the WTRU service enabler 208 through a specific local content request, or the enabler server 212 may simply ask the 5GS to provide the WTRU location.

[0127] Another trigger may be related to a certain state of the WTRU 202 itself. For example, if the WTRU battery level is low, this state may trigger the WTRU service enabler 208 to request local content reflecting "nearby charging stations" for the WTRU application host. In this example, the user does not actively request the content when it occurs, but rather leaves it to the WTRU service enabler 208 to manage and / or trigger the request.

[0128] Another trigger may be the WTRU 202 entering a configured geo-fenced area. At 502, the WTRU 202 may be configured with this information. Upon entering the location, the WTRU 202 may send an indication to the enabler server 212. The message may include the WTRU's location or information to help identify the geo-fence. Processing may then continue to 510.

[0129] At 508, the requested information may be provided to the WTRU service enabler 208. For example, at 508, the WTRU service enabler 208 in the WTRU 202 provides the WTRU's location information to the enabler server 212. However, as explained above, the enabler server 212 may also be provided with information related to the WTRU's battery level, speed, and network congestion level. This information may be provided to the enabler server 212 by the WTRU service enabler 208, another application server 206, or the NEF of the 5G core network.

[0130] At 510, the enabler server 212 may use the WTRU location information obtained at 508 and any other information (e.g., battery information, trajectory, speed, congestion level), and interest profile to detect the availability of local content for the WTRU 202. The enabler server 212 may use this information by comparing the WTRU location with the available location points available to the enabler server 212, and the initial WTRU location may be mapped to the closest location point within a certain distance. From this mapping, the enabler server 212 may determine which possible local content to provide around the location point. For example, if it has some association information between which anchor devices 216 are associated with the location point, then the local content associated with these anchor devices 216 may be provided to the WTRU 202. For example, at 510, interaction between the enabler server 212 and the service provider may help determine what information should be sent to the WTRU service enabler 208. For example, this interaction may allow the service provider to control targeted advertising.

[0131] There may be triggers that initiate the process of the enabler server 212 to initiate the provision of local content for the user. One of the triggers may be the WTRU location. In addition to the interest configuration, the enabler server 212 may also use the WTRU location to determine which local content is available for provision and should also be provided to the WTRU 202. The enabler server 212 may periodically check the WTRU's location and, if it changes, use the new location to determine the available local content.

[0132] At this stage, the enabler server 212 may approve the detected local content to be provided to the WTRU 202 by performing an interest check. Depending on configuration information at the enabler server 212 (such as the anchor ID, service provider ID, some ranging information, and further filtering conditions like what time of day certain WTRU-hosted application IDs are interested in local content), the enabler server 212 may determine what information to send to the WTRU service enabler 208. This configuration information may be similar to the configuration information of the present disclosure. Figure 4 402.

[0133] The enabler server 212 may determine that there is no local content available for the user at the WTRU's location. For example, if the WTRU's location is 5 km from the closest location point, then no local content is available for the WTRU 202. The enabler server 212 may determine that there is available content for the WTRU-hosted application, but after running an interest check, it may determine that the available local content is not relevant to the WTRU 202 (e.g., there are some "open gym" places near the WTRU 202, but the time of day is evening and the WTRU's preference for gym suggestions is only in the morning).

[0134] At 512, the enabler server 212 may send a notification regarding the availability of local content related to the WTRU-hosted application to the WTRU service enabler 208. The notification may include information about the local content available to the WTRU 202 (such as the anchor ID of the anchor device 216 from which the WTRU 202 can obtain the content), and may include some information about how to obtain such local content. The message may include a URI that may be used to retrieve the local content, and the message may include the identity of the WTRU-hosted application client(s) 204 that may be interested in the content.

[0135] Depending on the enabler server configuration, the message may also be a notification that no local content is available or that local content is available but not relevant to the WTRU 202 .

[0136] In another scenario, the enabler server 212 may choose not to perform interest checking for available local content, but instead decide to notify the WTRU service enabler 208 of the availability of local content with information such as nearby available anchor devices 216. The WTRU service enabler 208 may then perform interest checking on its own to determine whether the content is relevant to the WTRU 202.

[0137] The enabler server notification may provide the WTRU service enabler 208 with information related to local content and may carry the same information as in the Figure 4 The interest check response message has the same contents as described in the process.

[0138] The WTRU service enabler 208 may initiate a process to obtain local content at 514. Example processes for obtaining local content are discussed later in this disclosure.

[0139] Other local content detection Figure 6 Shown Figure 4 An example of an implementation of the process described in , where the WTRU hosting application configures anchor rules in the WTRU service enabler 208. Those rules are Figure 4 216 . Those rules enable discovery of anchor devices 216 by the WTRU 202 and enable associating the anchor with its associated representation in the world representation. One example of an anchor device 216 is a trackable device that can be used by the WTRU application client 204 to determine what scene to display on the screen. For example, the screen can be part of a pair of smart goggles, and the anchor device 216 can be considered a trackable device because the anchor device 216 is placed at a fixed point in three-dimensional space. The WTRU application client 204 can use the presence of the anchor device 216 to determine what images to display on the screen above or behind other people or objects present in the three-dimensional space with the anchor device 216. Another example of an anchor device 216 is an access point (e.g., a WiFi AP, a Proximity Service (ProSe) device) that provides access to localized content. The WTRU service enabler 208 can configure the WTRU 202 to discover the anchors identified by the anchor rules. Upon discovering the anchor device 216, the WTRU service enabler 208 may select one or more applicable rules and apply the actions defined by the rules.

[0140] At 602, the WTRU application client 204 may provide the user's interests (i.e., interest filters) (e.g., in products or services, and possibly associated with contextual information such as time limits, ranges of times of day in which the interests are relevant, etc.) to the application server 206.

[0141] At 604, the application server 206 may obtain the WTRU location (e.g., using the 5G service API or through the enabler server 212). For example, if the application server 206 already knows the WTRU location, 604 may not be necessary. For example, as described in 3GPP TS 23.434, the enabler server 212 (i.e., the location management server) may send a location information request to the location management client (i.e., the WTRU service enabler 208).

[0142] At 606, the application server 206 may obtain a list of anchor devices 216 that are relevant to the user's interests. The application server 206 may obtain this list from its own database or from an external service. This process may rely on the local service provider registering their anchor devices 216 with the application or external service before the process begins. The application server 206 may update the world representation for the WTRU application client's session to add the obtained list of anchor devices 216, using a world anchor ID to identify those anchors. In an example, the world anchor ID may be a URI. The world anchor ID may be related to the anchor device ID or anchor service ID, although it may or may not be constructed using those IDs. The application server 206 may prepare anchor rules that associate the anchor device / service ID with the world anchor ID and other information elements.

[0143] In certain representative embodiments, the anchor rule information element may include any of the following: an anchor rule ID identifying the rule; a world anchor ID (i.e., an ID known to the application and associated with the anchor); an anchor device ID; an anchor service ID; an anchor type (e.g., trackable object, access point, etc.); a discovery method (e.g., ProSe, WiFi service discovery, etc.); access credentials (enabling access to the anchor device); interest filters (e.g., location information (e.g., cell ID, GPS location, etc.), distance information, time of day range information, etc.); and / or an action, identified by the information element. For example, the action identification information may include an action type indicating that the WTRU 202 should establish a connection to the anchor, send an indication to the enabler server 212, send an indication to the WTRU application client, or download content. For example, the action identification information may include an actor ID identifying the WTRU service enabler 208, the enabler server 212, or a group of the WTRU service enabler 208 and / or the enabler server 212. The actor ID may identify which entity or entities should perform the action. For example, the action identification information may include additional parameters specific to the action type (eg, a URI for downloading content).

[0144] At 608 , the application server 206 may send the anchor rules to the enabler server 212 .

[0145] At 610, the application server 206 may send an updated world representation to the WTRU application client, the updated world representation including the world anchor IDs included in the anchoring rules. For example, if the world representation on the WTRU application client 204 already includes those world anchor IDs (e.g., if the WTRU application client 204 has been pre-loaded with a complete world representation in a scenario where the WTRU application client 204 always runs when the WTRU 202 is located in a pre-known location (such as a sports or athletic venue), then 610 may not be necessary. The WTRU application client 204 may update the relevant information for the WTRU service enabler 208 (e.g., in the case where the world map is maintained by the WTRU service enabler 208). In some systems, the application server 206 may send the updated world representation to the enabler server 212, which may send it to the WTRU service enabler 208 (e.g., in the case where the world map is handled collaboratively by the WTRU service enabler 208 and the enabler server 212).

[0146] At 612 , the enabler server 212 may send the anchor rules to the WTRU service enabler 208 .

[0147] At 614, the WTRU service enabler 208 may configure the WTRU 202 to discover the anchors present in the anchor rule. This process may include configuring ProSe service discovery, WiFi service discovery, etc., and may use the discovery method configured in the rule to select the appropriate method. The WTRU service enabler 208 may use the filter of the rule to configure discovery only if the WTRU 202 is in the configured location for the rule (e.g., within a cell identified by a cell ID, or within a certain distance of a GPS location), at a time of day within a configured time range for the rule, etc.

[0148] At 616, at some point, the anchor device 216 may be discovered by the WTRU 202. An anchor indication message may be received by the WTRU 202 including the anchor device ID or the anchor service ID.

[0149] At 618 , the anchor indication may be transmitted by the WTRU 202 to the WTRU service enabler 208 .

[0150] At 620, the WTRU service enabler 208 may select one or more applicable anchor rules (e.g., using the discovered anchor device ID and / or anchor service ID). The WTRU service enabler 208 may also use rule filters (e.g., location and time of day) to perform the selection. The WTRU service enabler 208 may implement the actions specified in the selected anchor rule(s), as described below.

[0151] At 622, assuming the selected anchor rule specifies establishing a connection to the anchor device 216, the WTRU service enabler 208 may trigger the establishment of the connection (e.g., over ProSe, WiFi, etc.). This action may, for example, be limited to certain anchor types (e.g., access point anchor types). For example, the anchor type parameter may indicate that the anchor device 216 is an access point. For example, the anchor type parameter may indicate the type of radio access technology that the anchor point uses for communication. Examples of radio access technologies are protocols based on Bluetooth, Wi-Fi, and PC5.

[0152] Assuming that the selected anchor rule specifies that an indication be sent to the enabler server 212, the WTRU service enabler 208 may send an indication to the enabler server 212 at 624. The parameters of the indication message may include the anchor rule ID and / or any anchor rule information elements, including the world anchor ID, anchor device ID, anchor service ID, anchor type, and / or discovery method. Upon receiving the indication, the enabler server 212 may act according to the rule configuration at 626 (e.g., it may initiate a download of the content and / or send an indication to the application server 206).

[0153] Assuming the selected anchor rule specifies that an indication be sent to the WTRU application client, the WTRU service enabler 208 may send an indication to the WTRU application client 204 at 628. The parameters of the indication message may include any anchor rule information elements, including the world anchor ID, anchor device ID, anchor service ID, anchor type, and / or discovery method. Upon receiving the indication, the WTRU application client 204 may perform an action based on application-specific logic at 630. For example, the WTRU application client 204 may decide to download local content associated with the world anchor ID, may decide to locate and use a trackable object associated with the world anchor ID, or other application-specific actions.

[0154] Get local content As described above, the WTRU service enabler 208 may receive an interest check response or enabler server notification from the enabler server 212. The interest check response or enabler server notification may provide the WTRU service enabler 208 with a URI pointing to local content that may be of interest to the WTRU-hosted application. Figure 7The process of illustrates how information from the interest check response or enabler server notification may be used to obtain information for the WTRU application client 204. The WTRU application client 204 may then display the information to the user (e.g., displaying the information on the user's AR glasses).

[0155] At 702, as described above, the WTRU service enabler 208 may receive content information from the enabler server 212, for example, in an interest check response (such as in Figure 4 416 in the example above) or in an enabler server notification (such as at 512). The response or notification may include content, a URI that can be used to retrieve the content, or an anchor ID. For example, if the message at 702 includes content, the process may jump to 714 and complete when 714 is completed. For example, if the message at 702 includes an anchor ID, the process may continue to 704. For example, if the message at 702 includes a URI that can be used to retrieve the content, the process may jump to 710 or 718.

[0156] The URI received at 702 (ie, in an interest check response or enabler server notification) may identify content or identify a storage location for the content.

[0157] At 704, the WTRU service enabler 208 may send the anchor ID to the MT portion of the WTRU and request the MT portion of the WTRU 202 to establish communication with the anchor device 216. The request may be sent by invoking an AT command.

[0158] At 706, the MT portion of the WTRU 202 may establish communication with the anchor device 216. For example, establishing communication with the anchor device 216 may involve listening for devices broadcasting an anchor ID. For example, establishing communication with the anchor device 216 may involve transmitting a solicitation request for the anchor device 216. For example, the solicitation message may include the anchor ID. For example, establishing communication with the anchor device 216 may involve ProSe direct communication or communication over a Uu interface. For example, establishing communication with the anchor device 216 may involve performing an 802.11aq discovery procedure.

[0159] A number of steps or processes may be performed at 706. For example, the steps may involve discovering the anchor device 216, establishing a secure connection with the anchor device 216, and then retrieving content from the anchor device 216. For example, once communication with the anchor device 216 is established, the WTRU service enabler 208 may communicate with the application client 204 or the WTRU service enabler 208 in the anchor device 216 to retrieve the content. Alternatively, the WTRU service enabler 208 may use the URI received from the enabler server 212 in step 1 to retrieve specific content that may be of interest to the WTRU application client 204. Alternatively, the WTRU service enabler 208 may obtain the URI for the content from the anchor device 216.

[0160] If content was retrieved from the anchor device 216 at 706, the process may jump to 714 and may complete when 714 is complete.

[0161] If on the other hand a URI is retrieved from the anchor device 216 at 706, then Figure 7 The process in may jump to sub-process 708, where the service enabler 218 obtains the content and provides it to the WTRU application client 2014, or Figure 7 The process in may jump to sub-process 716, where the service enabler 208 notifies the WTRU application client 204 and then the WTRU application client 204 gets the content.

[0162] At 710, the WTRU service enabler 208 may use the URI received at 702 or 706 to request content from the enabler server 212. As an example, Figure 7 The content is shown to be retrieved from the enabler server 212. However, it is possible that the URI points to content stored on a different (i.e., third-party) server. Thus, the interaction between the WTRU serving the enabler 208 at 710 may be with a different server than the enabler server 212 involved at 702.

[0163] At 712 , the enabler server 212 may provide the requested content to the WTRU service enabler 208 .

[0164] At 714, the WTRU service enabler 208 may provide the content to the WTRU application client 204. The WTRU application client 204 may then display the content to the user (eg, on the display 128 or on the peripheral device 138 such as AR glasses).

[0165] At 718, the WTRU service enabler 208 may send a notification to the WTRU application client 204 that the content has been detected. The notification may include the URI of the content received at 702 or 706.

[0166] At 720 , the WTRU application client 204 may use the URI to request content from the enabler server 212 . Figure 7 The content is shown to be retrieved from the enabler server 212. However, the URI may point to content stored on a different (i.e., third-party) server. Thus, the interaction between the WTRU application client 204 at 720 and the enabler server 712 may be with a different server than the enabler server 212 that participated at 702.

[0167] At 722, the enabler server 212 may provide the requested content to the WTRU application client 204. The WTRU application client 204 may then display the content to the user (eg, on the display 128 or on the peripheral device 138 such as AR glasses).

[0168] Interest Filters If combined Figure 4 As described with reference to 402 and 404, the WTRU service enabler 208 and the enabler server 212 may be configured with information regarding what local content is of interest to the application client 204 hosted in the WTRU. This information may be referred to as an interest filter.

[0169] The interest filter may indicate a service type (eg, restaurant) associated with each of the subtypes (eg, restaurant type) of WTRU-hosted applications and services.

[0170] The interest filter may indicate the identity of a specific service (eg, a pizza restaurant on the street) associated with each of the WTRU-hosted applications.

[0171] The interest filter may indicate when each piece of content becomes relevant to each of the WTRU-hosted applications. For example, an interest filter in the enabler server 212 may indicate that a piece of content should be sent to the WTRU service enabler 208 only if the associated anchor device 216 is within a certain distance (e.g., 25 meters) of the WTRU 202. The interest filter in the WTRU service enabler 208 may indicate that the same piece of content should be sent to the WTRU-hosted application only if the associated anchor device 216 is within a smaller distance (e.g., 5 meters) of the WTRU 202 and is located in front of the field of view of AR goggles tethered to the WTRU 202. Similarly, the filter may indicate that content should be shared only if the WTRU 202 meets other criteria such as speed (e.g., a WTRU-hosted application may determine that a piece of content should be displayed to a user only in scenarios where the user appears to be pausing, stopping, or lingering in a certain area (e.g., near a store window).

[0172] The WTRU service enabler 208 may be Figure 4 The interest filter may be applied at 410 of the WTRU. For example, the filter may indicate whether each WTRU-hosted application is interested in certain anchor IDs. Additionally, if the anchor notification at 408 includes information such as ranging information, then an interest filter may be used to "filter out" certain information. For example, the WTRU service enabler 208 may determine to proceed only if the anchor device 216 is within a certain range. Figure 4 The interest filter may indicate that the WTRU-hosted application is only interested in content associated with an anchor device 216 that is within a certain range. Alternatively, the interest filter may indicate that content associated with the anchor device 216 should be retrieved if the WTRU 202 is within a certain range of the anchor device 216, and that the content should be shared with the WTRU-hosted application only if the WTRU 202 is within a closer range of the WTRU 202.

[0173] The enabler server 212 may determine Figure 4 The interest filter is applied at 416 when determining what content to send to the WTRU service enabler 208. For example, the interest filter in the enabler server 212 may be used to determine whether the interest check response should provide the WTRU service enabler 208 with the content or a URI to the content.

[0174] The WTRU service enabler 208 may be Figure 4 The interest filter is applied at 418. For example, upon receiving the URI to the content at 416, the enabler server 212 may also send metadata such as location information, service provider identifier, scope criteria, etc. The WTRU service enabler 208 may use the interest filter and metadata to determine whether the associated content should be retrieved.

[0175] As described above and Figure 4 、 Figure 5 、 Figure 6 and Figure 7 As shown in , interest filters can be used to help make the following determinations.

[0176] First, whether the server enabler should request more information about the content associated with the anchor device 216 .

[0177] Second, whether the enabler server 212 should provide the WTRU service enabler 208 with more information about the content associated with the anchor device 216 .

[0178] Third, whether the WTRU service enabler 208 should retrieve content associated with the anchor device 216 or perform other actions, such as sending an indication, upon discovery of the anchor device 216 .

[0179] Fourth, whether the WTRU service enabler 208 should provide the content associated with the anchor device 216 to the WTRU hosted application.

[0180] Fifth, whether the WTRU service enabler 208 should enable discovery of the anchor device 216 .

[0181] Figure 8 is a process diagram illustrating an example process for a WTRU 102 (e.g., WTRU 202) to obtain content using an anchor device 216. Figure 8 , the WTRU 102 may receive configuration information indicating interest information at 802. For example, the interest information may include: (i) one or more application IDs associated with one or more applications of the WTRU 102; and (ii) for each of one or more anchor devices 216, the anchor device ID and filtering information indicating that a first application in the one or more applications is interested in the corresponding anchor device ID only if the orientation of the WTRU 102 relative to the corresponding anchor device 216 and one or more other criteria are met. At 804, the WTRU 102 may discover a first anchor device 216 in the one or more anchor devices 216. For example, the discovery at 804 may be performed as described herein (e.g., by using WiFi, Bluetooth, and / or PC5 communications). At 806, the WTRU 102 may apply the filtering information to the first anchor device 216 and determine that the orientation of the WTRU 102 relative to the first anchor device 216 and the one or more other criteria are met. At 808, the WTRU 102 may transmit information indicating the application ID of the first application and the anchor device ID of the first anchor device to a server (e.g., the enabler server 212) (e.g., based on the determination at 806). At 810, the WTRU 102 may receive from the server information indicating a URI associated with the anchor device ID of the first anchor device 216. At 812, the WTRU 102 may use the URI (e.g., the indicated URI from 810) to obtain content from the repository. For example, the WTRU 102 may Figure 7 Get the content as described in .

[0182] In certain representative embodiments, the one or more other criteria may be based on any of the following: (i) a time window (e.g., a certain time period); (ii) one or more times of day (e.g., a set of times); (iii) the first anchor device having an association with a service provider ID; (iii) the distance of the WTRU 102 relative to the first anchor device 216 (e.g., within a range or a threshold); (iv) battery status (e.g., above or below a threshold); (v) mobility information of the WTRU 102 (e.g., speed or trajectory); and / or (vi) the anchor device type of the first anchor device (e.g., what access type is provided by the first anchor device 216). Other criteria may be used as described herein.

[0183] In certain representative embodiments, the WTRU 102 may provide the obtained content to an application (e.g., Figure 7 (as in the example above).

[0184] In certain representative embodiments, the WTRU 102 may use a URI to obtain content from a repository, such as by obtaining the content from the first anchor device 216 based on the URI.

[0185] In certain representative embodiments, the WTRU 102 may use a URI to obtain content from a repository, such as by obtaining the content from a server such as the enabler server 212 (eg, different from the first anchor device) based on the URI.

[0186] In certain representative embodiments, the WTRU 102 may use a URI to obtain content from a repository, such as by providing the URI to an application and transmitting a request from the application to the repository based on the URI.

[0187] In certain representative embodiments, the WTRU 102 may discover the first anchor device 216 using broadcast information received from the first anchor device 216 .

[0188] In certain representative embodiments, the WTRU 102 may provide a notification to the application that the first anchor device 216 is associated with and / or discovered after determining the orientation of the WTRU 102 relative to the first anchor device 216 and the one or more other criteria are met.

[0189] In certain representative embodiments, the WTRU 102 may determine that the orientation of the WTRU 102 relative to the first anchor device and the distance of the WTRU relative to the first anchor device are satisfied as the one or more other criteria.

[0190] In certain representative embodiments, the WTRU 102 may perform ranging to determine the distance of the WTRU 102 relative to the first anchor device 216 .

[0191] In certain representative embodiments, the WTRU 102 may perform discovery of the first anchor device 216, such as by receiving (eg, broadcasting) information indicating an anchor device ID of the first anchor device and / or a type of the first anchor device (eg, WiFi, Bluetooth, PC5 communication).

[0192] In certain representative embodiments, the orientation of the WTRU 102 may correspond to a field of view associated with the WTRU 102 (e.g., of a camera, AR glasses).

[0193] In certain representative embodiments, the orientation of the WTRU 102 may correspond to a measure of the location of the WTRU 102 relative to the location of the first anchor device 216 .

[0194] Figure 9 is a process diagram illustrating an example process for a WTRU 102 (e.g., WTRU 202) to obtain content using the anchor device 216. Figure 9 As shown in , the WTRU 102 may receive configuration information indicating interest information at 902. For example, the interest information may include: (i) one or more application IDs associated with one or more applications of the WTRU; and (ii) for each of the one or more anchor devices 216, the anchor device ID and filtering information indicating that a first application of the one or more applications is of interest to the corresponding anchor device 216 only if one or more criteria are satisfied. At 902, the WTRU 102 may perform discovery of a first anchor device 216 of the one or more anchor devices 216. At 904, the WTRU 102 may transmit information indicating the application ID of the first application and the anchor device ID of the first anchor device 216 to a server (e.g., an enabler server 212) based on the one or more criteria corresponding to the filtering information for the first anchor device 216 being satisfied. At 906, the WTRU 102 may receive information from the server indicating a location of content associated with the first anchor device. At 908, the WTRU 102 may obtain the content from the indicated location. For example, the WTRU 102 may Figure 7 Get the content as described in .

[0195] In certain representative embodiments, the one or more criteria may be based on any of the following: (i) a time window (e.g., a period of time); (ii) one or more times of day (e.g., a set of times); (iii) the first anchor device having an association with a service provider ID; (iii) the distance of the WTRU 102 relative to the first anchor device 216 (e.g., within a range or a threshold); (iv) a battery status (e.g., above or below a threshold); (v) mobility information of the WTRU 102 (e.g., speed or trajectory); (vi) an anchor device type of the first anchor device (e.g., what access type is provided by the first anchor device 216); and / or (vii) an orientation of the WTRU 102 (e.g., relative to the first anchor device 216).

[0196] In certain representative embodiments, the WTRU 102 may perform ranging to determine the distance of the WTRU 102 relative to the first anchor device 216 .

[0197] In certain representative embodiments, the orientation of the WTRU 102 may correspond to a field of view associated with the WTRU 102 (e.g., of a camera, AR glasses).

[0198] In certain representative embodiments, the orientation of the WTRU 102 may correspond to a measure of the location of the WTRU 102 relative to the location of the first anchor device 216 .

[0199] In certain representative embodiments, the WTRU 102 may be as described herein (e.g., as Figure 7 ) to obtain content and / or provide content to an application.

[0200] In certain representative embodiments, the WTRU 102 may discover the first anchor device 216 using broadcast information received from the first anchor device 216 .

[0201] In certain representative embodiments, the WTRU 102 may, after discovering the first anchor device 216 , such as at 904 , provide a notification to the application that the first anchor device 216 is associated with and / or discovered.

[0202] In certain representative embodiments, the WTRU 102 may perform discovery of the first anchor device 216, such as by receiving (eg, broadcasting) information indicating an anchor device ID of the first anchor device and / or a type of the first anchor device (eg, WiFi, Bluetooth, PC5 communication).

[0203] Figure 10 is a process diagram illustrating an example process for a WTRU 102 (e.g., WTRU 202) to obtain content using an anchor device 216. Figure 10, the WTRU 102 may receive, at 1002, filtering information indicating that a first application of the WTRU 102 is interested in an anchor device (e.g., general or specific anchor(s)) only if one or more criteria are satisfied. At 1004, the WTRU 102 may receive identification information of the first anchor device 216. At 1006, the WTRU 102 may transmit, to a server (e.g., the enabler server 212), information indicating an application ID of the first application and an anchor device ID of the first anchor device 216 based on the one or more criteria of the filtering information being satisfied. At 1008, the WTRU 102 may receive, from the server, information indicating a location of content associated with the first anchor device 216. At 1010, the WTRU 102 may obtain the content from the indicated location (e.g., the URI indicated at 1008). For example, the WTRU 102 may Figure 7 Get the content as described in .

[0204] In certain representative embodiments, the filtering information (eg, received at 1002) may be an interest filter as described herein.

[0205] In certain representative embodiments, identification information of the first anchor device 216 may be received (eg, from the first anchor device 216 ), such as during the discovery process at 1004 .

[0206] In certain representative embodiments, the WTRU 102 may perform a process (e.g., implemented as a method) that includes a WTRU service enabler 208 hosted by the WTRU 102 determining that one or more application clients 204 hosted by the WTRU 102 are interested in available local content. The WTRU service enabler 208 may obtain the available local content. The WTRU service enabler 208 may provide the available local content to the one or more application clients 204.

[0207] In certain representative embodiments, the WTRU service enabler 208 may receive a message from an anchor device indicating that local content is available.

[0208] In certain representative embodiments, the WTRU service enabler 208 may query the enabler server 212 for information regarding the interest of the one or more application clients 204 in available local content.

[0209] In certain representative embodiments, the WTRU service enabler 208 may receive a message from the enabler server 212 indicating that local content of interest to the one or more application clients 204 is available.

[0210] In certain representative embodiments, the WTRU service enabler 208 may determine that the one or more application clients 204 are capable of using available local content.

[0211] In certain representative embodiments, the WTRU service enabler 208 may receive one or more anchor rules indicating one or more anchor devices from the enabler server 212. For example, the anchor device may be associated with available local content of interest to the one or more application clients 204.

[0212] In certain representative embodiments, the WTRU service enabler 208 may receive an anchor indication from the one or more anchor devices. The WTRU service enabler 208 may perform at least one action specified in the anchor rule in response to receiving the anchor indication.

[0213] In certain representative embodiments, the anchor indication may correspond to at least one of: (i) an image detected by the WTRU; (ii) a symbol detected by the WTRU; (iii) a picture detected by the WTRU; and / or (iv) an anchor indication message including any one of an anchor device identity and / or an anchor service identity.

[0214] In certain representative embodiments, the WTRU service enabler 208 may obtain the available local content by receiving the available local content from at least one of the enabler server 212 or another enabler server. For example, the available local content may be provided (e.g., directly) to the one or more application clients 204.

[0215] In certain representative embodiments, the WTRU service enabler 208 may obtain available local content and provide the available local content (e.g., indirectly) to the one or more application clients 204. For example, the WTRU service enabler 208 may receive a URI for retrieving the available local content from the enabler server 212. The URI may be provided (e.g., transmitted) to the one or more application clients 204.

[0216] in conclusion Although features and elements are provided above in specific combinations, it will be appreciated by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. The present disclosure is not limited in terms of the specific embodiments described in this application, which are intended to be illustrative of various aspects. Many modifications and variations can be made without departing from its spirit and scope, which will be obvious to those skilled in the art. None of the elements, actions or instructions used in the specification of this application should be understood as being essential or essential to the present invention unless so explicitly stated. In addition to those listed herein, functionally equivalent methods and devices within the scope of the present disclosure will be obvious to those skilled in the art from the description above. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is limited only by the terms of the appended claims and the full scope of equivalents to which such claims are entitled. It should be understood that the present disclosure is not limited to a particular method or system.

[0217] For simplicity, the above embodiments are discussed with respect to the terminology and structure of wireless communication functional devices (e.g., radio transmitters and receivers). However, the embodiments discussed are not limited to these systems and can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0218] It should also be understood that the terms used herein are used only to describe specific embodiments and are not intended to be limiting. As used herein, the term "video" or the term "imagery" may mean any of a snapshot, a single image, and / or a plurality of images displayed on a time basis. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE", the term "remote" and / or the term "head mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of many embodiments of a WTRU; (iii) a wirelessly enabled and / or wired enabled device (e.g., shareable via a mobile phone) configured with, among other things, some or all of the structure and functionality of a WTRU; (iii) a wirelessly enabled and / or wired enabled device configured with less than all of the structure and functionality of a WTRU; (iv) and the like. This document is about Figures 1A to 1DDetails are provided for an example WTRU that can represent any WTRU described herein. As another example, various disclosed embodiments are described above and below herein as utilizing a head-mounted display. Those skilled in the art will appreciate that devices other than head-mounted displays can be utilized and that some or all of the present disclosure and various disclosed embodiments can be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted reality experience.

[0219] In addition, the method provided herein can be incorporated into a computer program, software or firmware for a computer or processor to perform. The example of a computer readable medium includes an electronic signal (transmitted by a wired or wireless connection) and a computer readable storage medium. The example of a computer readable storage medium includes but is not limited to a read-only memory (ROM), a random access memory (RAM), a register, a cache memory, a semiconductor memory device, a magnetic medium (such as an internal hard disk and a removable disk), a magneto-optical medium and an optical medium (such as a CD-ROM disk and a digital versatile disk (DVD)). The processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, a UE, a terminal, a base station, an RNC or any host computer.

[0220] Variations of the methods, devices, and systems provided above are possible without departing from the scope of the present invention. In view of the wide variety of embodiments that can be applied, it should be understood that the illustrated embodiments are merely examples and should not be considered as limiting the scope of the appended claims. For example, the embodiments provided herein include handheld devices that can include or be utilized with any suitable voltage source (such as a battery, etc.) to provide any suitable voltage.

[0221] In addition, in the embodiments provided above, processing platforms, computing systems, controllers and other devices including processors are mentioned. These devices may include at least one central processing unit ("CPU") and memory. According to the practice of those skilled in the art of computer programming, reference to the symbolic representation of actions and operations or instructions can be performed by various CPUs and memories. Such actions and operations or instructions can be referred to as "being executed," "being executed by a computer," or "being executed by a CPU."

[0222] Those skilled in the art will appreciate that actions and symbolically represented operations or instructions comprise manipulation of electrical signals by the CPU. The electrical system represents data bits, which can result in a resulting transformation or reduction of the electrical signal and maintain the data bits at memory locations in the memory system, thereby reconfiguring or otherwise changing the operation of the CPU, as well as other processing of the signal. The memory location where the data bits are maintained is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that the embodiments are not limited to the platforms or CPUs mentioned above, and other platforms and CPUs may support the provided methods.

[0223] The data bits may also be maintained on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage systems that can be read by a CPU. The computer-readable media may include cooperating or interconnected computer-readable media that reside exclusively on the processing system or distributed among multiple interconnected processing systems that may be local or remote to the processing system. It should be understood that the embodiments are not limited to the memories mentioned above, and other platforms and memories may support the provided methods.

[0224] In an illustrative embodiment, any operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0225] There is little distinction between hardware and software implementations of aspects of the system. The use of hardware or software is typically (but not always, as the choice between hardware and software may become important in certain contexts) a design choice that represents a cost versus efficiency trade-off. There may be a variety of vehicles by which the processes and / or systems and / or other technologies described herein can be implemented (e.g., hardware, software, and / or firmware), and the preferred vehicle may vary with the context in which the processes and / or systems and / or other technologies are deployed. For example, if an implementer determines that speed and accuracy are most important, the implementer may select a primarily hardware and / or firmware vehicle. If flexibility is most important, the implementer may select a primarily software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0226] The above detailed description has been described using block diagrams, flow charts and / or examples to illustrate various embodiments of the device and / or process. Since such block diagrams, flow charts and / or examples include one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flow charts or examples can be implemented individually and / or collectively by a variety of hardware, software, firmware or almost any combination thereof. In one embodiment, several portions of the subject matter described herein can be implemented via an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP) and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be equivalently implemented in whole or in part in an integrated circuit as one or more computer programs running on one or more computers (e.g., implemented as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., implemented as one or more programs running on one or more microprocessors), as firmware or almost any combination thereof, and in view of the present disclosure, designing circuits and / or writing code for software and / or firmware will be well within the skills of those skilled in the art. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein can be distributed as a program product in a variety of forms, and that the illustrative embodiments of the subject matter described herein are applicable regardless of the particular type of signal-bearing medium used to actually implement the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media such as floppy disks, hard drives, CDs, DVDs, digital tapes, computer memories, and the like; and transmission media such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, and the like).

[0227] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner set forth herein, and subsequently use engineering practices to integrate such described devices and / or processes into data processing systems. That is, at least a portion of the devices and / or processes described herein can be integrated into data processing systems via a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system can typically include one or more of the following: a system unit housing, a video display device, a memory (such as, volatile and non-volatile memory), a processor (such as, a microprocessor and a digital signal processor), a computing entity (such as, an operating system, a driver, a graphical user interface and an application), one or more interactive devices (such as, a touchpad or screen) and / or a control system including a feedback loop and a control motor (e.g., feedback for sensing position and / or speed, a control motor for moving and / or adjusting components and / or quantity). A typical data processing system can be implemented using any suitable commercially available component, such as those components typically found in data computing / communication and / or network computing / communication systems.

[0228] The subject matter described herein sometimes illustrates different components that are included in or connected to different other components. It should be understood that this depicted architecture is merely an example, and in fact, many other architectures that implement the same function can be implemented. In a conceptual sense, any arrangement of components that implement the same function is effectively "associated" so that the desired function can be achieved. Therefore, any two components that are combined to implement a specific function herein can be considered to be "associated" with each other so that the desired function is achieved, regardless of the architecture or intermediate components. Similarly, any two components that are so associated can also be considered to be "operably connected" or "operably coupled" to each other to achieve the desired function, and any two components that can be so associated can also be considered to be "operably coupled" to each other to achieve the desired function. The specific examples of operable coupling include, but are not limited to, components that can be physically paired and / or physically interacted and / or components that can be wirelessly interacted and / or wirelessly interacted and / or components that logically interact and / or can logically interact.

[0229] With respect to the use of substantially any plural and / or singular terms herein, those skilled in the art can translate from the plural to the singular and / or from the singular to the plural as appropriate to the context and / or application. For purposes of clarity, various singular / plural permutations may be expressly set forth herein.

[0230] Those skilled in the art will understand that, in general, the terms used herein and particularly in the appended claims (e.g., the bodies of the appended claims) are generally intended to be "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "comprising" should be interpreted as "including but not limited to," etc.). Those skilled in the art will further understand that if a specific number of an introduced claim recitation is intended, such intent will be expressly recited in the claim, and if no such recitation is made, such intent does not exist. For example, where only one item is intended, the term "single" or similar language may be used. As an aid to understanding, the appended claims and / or the description herein may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be understood to imply that the introduction of a claim recitation by the indefinite article "a" or "an" will include any particular claim of such introduced claim recitation limited to embodiments including only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles to introduce claim recitations. In addition, even if specific numbers of introduced claim recitations are explicitly recited, those skilled in the art will recognize that such recitation should be interpreted as meaning at least the recited numbers (e.g., the unmodified recitation of "two recitations" without other modifiers means at least two recitations or two or more recitations). Furthermore, in those instances where a convention similar to “at least one of A, B, and C, etc.” is used, generally speaking, such construction is intended in the sense that one skilled in the art would understand the convention (e.g., “a system having at least one of A, B, and C” would include, but is not limited to, a system having only A, a system having only B, a system having only C, a system having A and B together, a system having A and C together, a system having B and C together, and / or a system having A, B, and C together, etc.). In those instances where a convention similar to “at least one of A, B, or C, etc.” is used, generally speaking, such construction is intended in the sense that one skilled in the art would understand the convention (e.g., “a system having at least one of A, B, or C” would include, but is not limited to, a system having only A, a system having only B, a system having only C, a system having A and B together, a system having A and C together, a system having B and C together, and / or a system having A, B, and C together, etc.).Those skilled in the art will further understand that, whether in the specification, claims or drawings, almost any disjunctive word and / or phrase presenting two or more interchangeable terms should be understood to consider the possibility of including one of the terms, any one of the two terms, or both of the terms. For example, the phrase "A or B" will be understood to include the possibility of "A" or "B" or "A and B". Further, as used herein, the term "any of..." followed by a list of multiple items and / or multiple categories of items is intended to include "any one," "any combination," "any multiple," and / or "any combination of multiple" of the items and / or categories, either alone or in combination with other items and / or other categories of items. In addition, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero. Moreover, as used herein, the term "multiple" is intended to be synonymous with "plurality."

[0231] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0232] As will be understood by those skilled in the art, for any and all purposes, such as providing a written description, all ranges disclosed herein also encompass any and all possible subranges and combinations thereof. Any listed range can be easily identified as fully describing the same range and enabling the same range to be decomposed into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein can be easily decomposed into a lower third, a middle third, and an upper third, etc. As will be understood by those skilled in the art, all language such as "up to," "at least," "greater than," and "less than" includes the recited number and refers to a range that can subsequently be decomposed into the subranges discussed above. Finally, as will be understood by those skilled in the art, a range includes each individual member. Thus, for example, a group having 1 to 3 units refers to a group having 1, 2, or 3 units. Similarly, a group having 1 to 5 units refers to a group having 1, 2, 3, 4, or 5 units, and so on.

[0233] Furthermore, the claims should not be read as limited to the order or elements provided unless so stated. Furthermore, the use of the term "means for..." in any claim is intended to invoke 35 USC §112, 6 or “means-plus-function” claim format, and any claim without the term “means for…” is not intended to be so.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: A processor, a memory, and a transceiver configured to: receiving configuration information indicating interest information, the interest information comprising: (i) one or more application identifiers (IDs) associated with one or more applications of the WTRU; and (ii) for each of one or more anchor devices, the anchor device ID and filtering information indicating that a first application of the one or more applications is interested in the corresponding anchor device ID only if an orientation of the WTRU relative to the corresponding anchor device and one or more other criteria are satisfied, discovering a first anchor device among the one or more anchor devices, applying the filtering information with respect to the first anchor device and determining that the orientation of the WTRU relative to the first anchor device and the one or more other criteria are satisfied, transmitting information indicating an application ID of the first application and an anchor device ID of the first anchor device to a server, receiving information from the server indicating a uniform resource indicator (URI) associated with an anchor device ID of the first anchor device, and The URI is used to obtain the content from the repository.

2. A WTRU as described in claim 1, wherein the one or more other criteria are based on any one of the following: (i) a time window; (ii) one or more times of the day; (iii) the first anchor device has an association with a service provider ID; (iii) the distance of the WTRU relative to the first anchor device; (iv) battery status; (v) mobility information of the WTRU; and / or (vi) an anchor device type of the first anchor device.

3. The WTRU of any one of claims 1-2, wherein the processor, the memory, and the transceiver are configured to provide the obtained content to the application.

4. The WTRU of any one of claims 1-3, wherein the processor, the memory, and the transceiver are configured to obtain the content from the repository using the URI, including obtaining the content from the first anchor device based on the URI.

5. The WTRU of any one of claims 1-3, wherein the processor, the memory, and the transceiver are configured to obtain the content from the repository using the URI, including obtaining the content from a server based on the URI.

6. The WTRU of any one of claims 1-3, wherein the processor, the memory, and the transceiver are configured to obtain the content from the repository using the URI, comprising providing the URI to the application and transmitting a request from the application to the repository based on the URI.

7. The WTRU of any one of claims 1-6, wherein the processor, the memory, and the transceiver are configured to discover the first anchor device using broadcast information received from the first anchor device.

8. The WTRU of any one of claims 1-7, wherein the processor, the memory and the transceiver are configured to: after determining the orientation of the WTRU relative to the first anchor device and the one or more other criteria are met, provide a notification related to and / or discovered by the first anchor device to the application.

9. The WTRU of any one of claims 1-8, wherein the processor, the memory, and the transceiver are configured to determine an orientation of the WTRU relative to the first anchor device and a distance of the WTRU relative to the first anchor device as the one or more other criteria are satisfied.

10. The WTRU of claim 9 wherein the processor, the memory, and the transceiver are configured to perform ranging to determine a distance of the WTRU relative to the first anchor device.

11. The WTRU of any one of claims 1-10, wherein the processor, the memory, and the transceiver are configured to discover the first anchor device, which includes receiving information indicating an anchor device ID of the first anchor device and / or a type of the first anchor device.

12. The WTRU of any one of claims 1-11, wherein the orientation of the WTRU corresponds to a measure of the WTRU's location relative to the location of the anchor device.

13. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: receiving configuration information indicating interest information, the interest information comprising: (i) one or more application identifiers (IDs) associated with one or more applications of the WTRU; and (ii) for each of one or more anchor devices, the anchor device ID and filtering information indicating that a first application of the one or more applications is interested in the corresponding anchor device ID only if an orientation of the WTRU relative to the corresponding anchor device and one or more other criteria are satisfied; discovering a first anchor device among the one or more anchor devices; applying the filtering information with respect to the first anchor device and determining that an orientation of the WTRU relative to the first anchor device and the one or more other criteria are satisfied; transmitting information indicating an application ID of the first application and an anchor device ID of the first anchor device to a server; receiving, from the server, information indicating a uniform resource indicator (URI) associated with an anchor device ID of the first anchor device; and The URI is used to obtain the content from the repository.

14. A method as claimed in claim 13, wherein the one or more other criteria are based on any one of the following: (i) a time window; (ii) one or more times of the day; (iii) the first anchor device has an association with a service provider ID; (iii) the distance of the WTRU relative to the first anchor device; (iv) battery status; (v) mobility information of the WTRU; and / or (vi) an anchor device type of the first anchor device.

15. The method of any one of claims 13-14, further comprising: The obtained content is provided to the application.

16. The method of any of claims 13-15, wherein using the URI to obtain the content from the repository comprises: The content is obtained from the first anchor device based on the URI.

17. The method of any of claims 13-15, wherein using the URI to obtain the content from the repository comprises: The content is obtained from another server based on the URI.

18. The method of any of claims 13-15, wherein using the URI to obtain the content from the repository comprises: The URI is provided to the application and a request from the application is transmitted to the repository based on the URI.

19. The method of any one of claims 13-18, wherein the discovery of the first anchor device uses broadcast information received from the first anchor device.

20. The method of any one of claims 13-19, further comprising: After determining the orientation of the WTRU relative to the first anchor device and the one or more other criteria are satisfied, providing a notification to the application that the first anchor device is associated with and / or discovered.

21. The method of any one of claims 13-20, wherein the one or more other criteria include: The distance of the WTRU relative to the first anchor device is less than a threshold.

22. The method of claim 21, further comprising: Ranging is performed to determine a distance of the WTRU relative to the first anchor device.

23. The method of any one of claims 13 to 22, wherein the discovery of the first anchor device comprises: Information indicating an anchor device ID of the first anchor device and / or a type of the first anchor device is received.

24. The method of any one of claims 13-23, wherein the orientation of the WTRU corresponds to a measure of the WTRU's location relative to the location of the anchor device.

Images