Wireless Transmission / Receive Unit (WTRU)-Driven Edge Service Discovery, Selection, and Provisioning Using Common Edge Application Server (EAS) Information and Registrar Edge Enable Server (EES) Information

Abstract

A wireless transmit / receive unit (WTRU) may send a discovery request to a first edge enabling server (EES) instance to obtain edge application server (EAS) information. The WTRU may receive a discovery response from the first EES instance. The discovery response may indicate a list of EAS information and / or registrar EES information for one or more EAS instances within the list of EAS information. The WTRU may select an EAS instance based on one or more of the list of EAS information or the registrar EES information for one or more EAS instances. A second EES instance of the plurality of EES instances may be the registrar EES of the selected EAS instance.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 466,372, filed May 15, 2023, the entire content of which is incorporated herein by reference in its entirety.

Background Art

[0002] The cellular communication system edge activation service layer may have a cardinality rule that limits Edge Application Server (EAS) registration to a single Edge Enabler Server (EES). To discover the edge services available to a WTRU, an EAS discovery request must be sent to the EES (e.g., a registrar EES) where the EAS is registered. Discovering a common EAS for a group of Application Clients (ACs) may require discovery of the EAS (e.g., by communicating with an EES other than the registrar EES of the EAS). Thus, a cellular communication system may be configured to support EAS discovery, for example, using an EES other than a registrar EES.

[0003] Described herein are one or more techniques related to the use of a non - registrar EES for discovery operations.

[0004] As a first instance, the WTRU may obtain information regarding available EAS instances in the Edge Data Network (EDN) by sending an EAS discovery request to each EES instance within the EDN. Additionally, new use cases may require that EAS information from different registrar EESs be provided during edge service discovery or selection. For example, the WTRU may discover and select edge services without individually connecting to all EESs in the EDN. The edge activation service layer of a cellular communication system may be used to enable edge service discovery, for example, using an EES other than the registrar EES of the EAS that needs to be discovered.

[0005] As a second instance, a particular edge service discovery procedure may provide EAS information about discovered EAS instances registered with the EES that processes the request. For example, if the EES can return EAS information from an EAS registered with another EES instance, the WTRU may not be able to determine the EES in which that EAS is registered and may not be able to indicate an EAS and Application Context Relocation (ACR) scenario selection in the registrar EES. Service continuity procedure failures may occur. Therefore, the edge activation service layer of a cellular communication system may be used to enable the WTRU to obtain the registrar EES information required to correctly indicate an ACR scenario selection in the EAS and the EES in which the selected EAS is registered. Further, or alternatively, the edge activation service layer of a cellular communication system may be used to enable the EES to correctly handle the service continuity of an EAS registered with another EES. SUMMARY OF THE INVENTION

[0006] A wireless transmit / receive unit (WTRU) may send a discovery request to a first edge enabling server (EES) instance to obtain edge application server (EAS) information. The WTRU may receive a discovery response from the first EES instance. The discovery response may indicate a list of EAS information and / or registrar EES information for one or more EAS instances within the list of EAS information. The WTRU may select an EAS instance based on one or more of the list of EAS information or the registrar EES information for one or more EAS instances. A second EES instance of the plurality of EES instances may be the registrar EES of the selected EAS instance.

[0007] The WTRU may send an EAS information provisioning request to the second EES instance. The EAS information provisioning request may indicate the selected EAS instance and one or more selected application context relocation (ACR) scenarios. The WTRU may receive an information provisioning response from the second EES instance. The WTRU may select the first EES instance of the plurality of EES instances based on the EAS information sharing capabilities of the first EES instance. The discovery request may include an indication that EAS information is requested from multiple EES instances. The discovery request may be sent on the condition that the EAS information sharing capabilities of the first EES instance indicate that the first EES instance is capable of obtaining EAS information from other EES instances within an edge data network (EDN). The discovery request may indicate a list of one or more other EES instances for obtaining EAS information. The discovery response may indicate one or more ACR scenarios supported by one or more EAS instances within the list of EAS information. The WTRU may receive an EAS information provisioning response indicating registrar EES information on the condition that one or more of the selected EAS instance or one or more selected ACR scenarios are rejected.

[0008] The WTRU may select one or more ACR scenarios based on a list of EAS information or one or more of the registrar EES information for each discovered EAS instance. The WTRU may use the registrar EES information to obtain a registrar EES profile. The registrar EES profile may be obtained from a local cache, from a discovery response, and / or by performing a service provisioning procedure at an edge configuration server (ECS). The WTRU may select one or more of the selected ACR scenarios according to the EAS information and the registrar EES information and profile.

Brief Description of the Drawings

[0009]

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Modes for Carrying Out the Invention

[0010] FIG. 1A is a diagram illustrating an exemplary 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 a plurality of wireless users. The communication system 100 may enable a plurality of wireless users to access such content through sharing of system resources including wireless bandwidth. For example, the communication system 100 may use 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 unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC).

[0011] As shown in Figure 1A, the communication system 100 can include wireless transmission / reception units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can 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 can be referred to as a “station” and / or “STA,” can be configured to transmit and / or receive wireless signals and can be a user equipment (WTRU), a mobile station, a fixed subscriber unit or mobile subscriber unit, a subscriber-based unit, a wireless call, 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, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., for remote surgery), an industrial device and application (e.g., a robot and / or other wireless device operating in an industrial and / or automated processing chain context), a home appliance, a device operating in a commercial wireless network and / or an industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a WTRU.

[0012] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as CN 106 / 115, Internet 110, and / or other network 112. By way of example, base stations 114a, 114b may be a base transceiver station (BTS), Node B, eNode B, home Node B, home eNode B, gNB, NR Node B, site controller, access point (AP), wireless router, etc. Base stations 114a, 114b are each illustrated as a single element, but it will be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0013] The base station 114a can be part of the RAN 104 / 113 and can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a and / or the base station 114b can be configured to transmit and / or receive radio signals at one or more carrier frequencies, which can be referred to as a cell (not shown). These frequencies can be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. The cell can provide wireless service coverage to a specific geographic area that can be relatively fixed or can change over time. The cell can be further divided into cell sectors. For example, the cell associated with the base station 114a can be divided into three sectors. Thus, in one embodiment, the base station 114a can include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the base station 114a can employ multiple-input multiple-output (MIMO) technology and can utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0014] The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d via the air interface 116, which can 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 can be established using any suitable radio access technology (RAT).

[0015] More specifically, as described above, the communication system 100 can be a multiple access system and can use one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a within RAN104 / 113, and the WTRUs 102a, 102b, 102c can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use wideband CDMA (WCDMA) to establish the air interfaces 115 / 116 / 117. WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

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

[0017] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use New Radio (NR) to establish the air interface 116.

[0018] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Accordingly, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of base stations (e.g., eNBs and gNBs) and / or multiple types of radio access technologies transmitted by and / or to these base stations.

[0019] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), IS-95, IS-856, Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0020] The base station 114b in FIG. 1A can be, for example, a wireless router, a home node B, a home e-node B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area such as an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless 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 can implement a wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0021] RAN 104 / 113 can communicate with CN 106 / 115, and CN 106 / 115 can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, 102d. The data can have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 may provide call control, billing services, mobile location information services, prepaid calls, internet connectivity, video distribution, etc., and / or may perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs using the same or different radio access technologies (RATs) as RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113 which may utilize New Radio (NR) radio technology, CN 106 / 115 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0022] CN106 / 115 can also serve as a gateway for WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 may include a circuit-switched telephone network that provides a plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, where these networks and devices use a common communication protocol such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP internet protocol suite. The network 112 may include a wired communication network and / or a wireless communication network that is owned and / or operated by another service provider. For example, the network 112 may include another CN connected to one or more RANs that may use the same RAT or a different RAT as the RAN104 / 113.

[0023] Some or all of the WTRU102a, 102b, 102c, 102d within the communication system 100 may include multimode capabilities (e.g., the WTRU102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in Figure 1A may be configured to communicate with a base station 114a that may employ a cellular-based wireless technology and a base station 114b that may employ IEEE802 wireless technology.

[0024] Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 can 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, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138. It will be understood that the WTRU 102 can include any partial combination of the foregoing elements while remaining consistent with one embodiment.

[0025] The processor 118 can be a general-purpose processor, a dedicated 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 can perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120 which can be coupled to the transmit / receive element 122. Although Figure 1B illustrates the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[0026] The transmission / reception element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmission / reception element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmission / reception element 122 can be an emitter / detector configured to transmit and / or receive, for example, IR signals, UV signals, or visible light signals. In yet another embodiment, the transmission / reception element 122 can be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmission / reception element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0027] Although the transmission / reception element 122 is depicted in FIG. 1B as a single element, the WTRU 102 can include any number of transmission / reception elements 122. More specifically, the WTRU 102 can employ MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmission / reception elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 116.

[0028] The transceiver 120 can be configured to modulate signals transmitted by the transmission / reception element 122 and demodulate signals received by the transmission / reception element 122. As noted above, the WTRU 102 can have a multimode function. Accordingly, the transceiver 120 can include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs such as, for example, NR and IEEE 802.11.

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

[0030] 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 supplying power to the WTRU 102. For example, the power source 134 may include one or more dry cells (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), a solar cell, a fuel cell, and the like.

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

[0032] Processor 118 may further be coupled to other peripheral devices 138, and the processor 118 may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connections. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality / Augmented Reality (VR / AR) device, an activity tracker, etc. The peripheral devices 138 may include one or more sensors, and the sensors may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0033] WTRU102 may include a full-duplex radio in which transmission and reception of some or all of the signals associated with a particular subframe (e.g., for both UL (e.g., for transmission) and downlink (e.g., for reception)) can be parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce and / or substantially eliminate self-interference, either via hardware (e.g., a choke) or via signal processing through a processor (e.g., a separate processor (not shown) or processor 118). In one embodiment, WRTU102 may include a half-duplex radio for transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either UL (e.g., for transmission) or downlink (e.g., for reception)).

[0034] Figure 1C is a system diagram illustrating RAN104 and CN106 according to one embodiment. As described above, RAN104 may employ E-UTRA radio technology to communicate with WTRU102a, 102b, 102c via air interface 116. RAN104 may also communicate with CN106.

[0035] RAN104 may include eNodeBs 160a, 160b, 160c, although it will be understood that RAN104 may include any number of eNodeBs while remaining consistent with one embodiment. Each of eNodeBs 160a, 160b, 160c may include one or more transceivers for communicating with WTRU102a, 102b, 102c via air interface 116. In one embodiment, eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, eNodeB 160a may transmit and / or receive radio signals from / to WTRU102a, for example, using multiple antennas.

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

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

[0038] The MME 162 may be connected to each of the eNode Bs 162a, 162b, and 162c in the RAN 104 via the S1 interface and may function as a control node. For example, the MME 162 may authenticate users of the WTRUs 102a, 102b, and 102c, activate / deactivate bearers, select a specific serving gateway during the initial attach of the WTRUs 102a, 102b, and 102c, etc. The MME 162 may provide control plane functions for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

[0039] The SGW 164 can be connected to each of the eNodeBs 160a, 160b, and 160c in the RAN 104 via the S1 interface. The SGW 164 can generally route and transfer user data packets to and from the WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as the function of anchoring the user plane during handover between eNodeBs, the function of triggering paging when DL data is available to the WTRUs 102a, 102b, and 102c, and the function of managing and storing the context of the WTRUs 102a, 102b, and 102c.

[0040] The SGW 164 can be connected to the PGW 166, and the PGW 166 can provide the WTRUs 102a, 102b, and 102c with access to a packet switched network such as the Internet 110 to facilitate communication between the WTRUs 102a, 102b, and 102c and IP-enabled devices.

[0041] The CN 106 can facilitate communication with other networks. For example, the CN 106 can provide the WTRUs 102a, 102b, and 102c with access to a circuit switched network such as the PSTN 108 to facilitate communication between the WTRUs 102a, 102b, and 102c and conventional landline communication devices. For example, the CN 106 can include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 can provide the WTRUs 102a, 102b, and 102c with access to other networks 112, which can include other wired and / or wireless networks owned and / or operated by other service providers.

[0042] The WTRU is described as a wireless terminal in FIGS. 1A - 1D, but in certain representative embodiments, it is contemplated that such a terminal can use a wired communication interface (e.g., temporarily or permanently) with a communication network.

[0043] In a representative embodiment, the other network 112 can be a WLAN.

[0044] A WLAN in infrastructure basic service set (BSS) mode can have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP can have access or an interface to a distribution system (DS), or another type of wired / wireless network that carries traffic entering and / or exiting the BSS. Traffic destined for an STA that originates outside the BSS can reach and be delivered to the STA through the AP. Traffic originating from an STA to a destination outside the BSS can be sent to the AP to be delivered to their respective destinations. Traffic between STAs within the BSS can be transmitted, for example, through the AP. The source STA can send the traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be transmitted between the source STA and the destination STA (e.g., directly between them) using direct link setup (DLS). In certain representative embodiments, the DLS can use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS mode of communication can be referred to herein as the "ad hoc" communication mode.

[0045] When using the operation of 802.11ac infrastructure mode or the operation of a similar mode, the AP may transmit beacons on a fixed channel such as the primary channel. The primary channel can be of a fixed width (e.g., a 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel can be the operating channel of the BSS, but can also be used by the STA 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. In the case of CSMA / CA, STAs including the AP (e.g., any STA) 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. Only one STA (e.g., only one station) can transmit at any given time in a given BSS.

[0046] A High Throughput (HT) STA can use a 40 MHz wide channel for communication, and this 40 MHz wide channel can be formed, for example, through a combination of a primary 20 MHz channel and an adjacent or non - adjacent 20 MHz channel.

[0047] A Very High Throughput (VHT) STA may support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. A 40 MHz and / or 80 MHz channel may be formed by combining a plurality of consecutive 20 MHz channels. A 160 MHz channel may be formed by combining eight consecutive 20 MHz channels or by combining two non-consecutive 80 MHz channels, which may be referred to as an 80+80 configuration. In the case of an 80+80 configuration, after channel encoding, the data may pass through a segment parser that can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing may be performed separately on each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed, and the combined data may be transmitted to the Medium Access Control (MAC).

[0048] The sub-1 GHz operating mode is supported by 802.11af and 802.11ah. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS) spectrum, and 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support meter type control / machine type communication, such as MTC devices within a macro communication range area. The MTC device may have limited capabilities including a particular capability, e.g., support for a particular and / or limited bandwidth (e.g., support only therefor). The MTC device may include a battery having a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0049] A WLAN system that supports multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes channels that can be designated as primary channels. The primary channel may 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 restricted by an STA from among all STAs operating in a BSS that supports a minimum bandwidth operation mode. In an example of 802.11ah, the primary channel is 1 MHz wide for an STA (e.g., an MTC type device) that supports the 1 MHz mode (e.g., supports only that) even when the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or Network Allocation Vector (NAV) setting may depend on the status of the primary channel. For example, if the primary channel is busy due to an STA transmitting to the AP (supporting only the 1 MHz operation mode), most of the frequency band may remain in an operation pause and, even if available, the entire available frequency band may be considered busy.

[0050] In the United States, the available frequency band that can be used by 802.11ah is 902 MHz to 928 MHz. In Korea, the available frequency band is 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6 MHz to 26 MHz depending on the country code.

[0051] Figure 1D is a system diagram illustrating RAN113 and CN115 according to one embodiment. As described above, RAN113 may use NR radio technology to communicate with WTRU102a, 102b, 102c via air interface 116. RAN113 may also communicate with CN115.

[0052] RAN 113 may include gNBs 180a, 180b, 180c, but it will be understood that RAN 113 may include any number of gNBs while remaining consistent with one embodiment. Each of gNBs 180a, 180b, 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, 102c via air interface 116. In one embodiment, gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, 180c. Thus, gNB 180a may transmit and / or receive radio signals to and from WTRU 102a, for example, using multiple antennas. In one embodiment, gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to 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, gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmission from gNB 180a and gNB 180b (and / or gNB 180c).

[0053] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, the OFDM symbol interval and / or the OFDM sub-carrier interval can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using sub-frames of various or extensible lengths (e.g., including a varying number of OFDM symbols and / or having an absolute time of varying length) or transmission time intervals (TTIs).

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

[0055] Each of gNBs 180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decision-making, handover decision-making, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to user plane functions (UPFs) 184a, 184b, routing of control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, gNBs 180a, 180b, and 180c may communicate with each other via the Xn interface.

[0056] As shown in FIG. 1D, CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and optionally data networks (DNs) 185a, 185b. Although each of the foregoing elements is shown as part of CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0057] AMF 182a and 182b can be connected to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can function as control nodes. For example, AMF 182a and 182b can play roles such as authentication of users of WTRUs 102a, 102b, and 102c, support for network slicing (e.g., handling different PDU sessions with different requirements), selection of specific SMFs 183a and 183b, management of the registration area, termination of NAS signaling, and mobility management. Network slices can be used by AMF 182a and 182b to customize the CN support for WTRUs 102a, 102b, and 102c based on the type of service being utilized by WTRUs 102a, 102b, and 102c. For example, different network slices can be established for different use cases such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, and services for machine type communication (MTC) access. AMF 162 can provide control plane functions for switching between RAN 113 and other RANs (not shown) that use other radio technologies such as non-3GPP access technologies like LTE, LTE-A, LTE-A Pro, and / or WiFi.

[0058] SMF183a and 183b can be connected to AMF182a and 182b within CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b within CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and allocating WTRU 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, etc.

[0059] UPF184a and 184b can be connected to one or more of gNB180a, 180b, and 180c within RAN113 via the N3 interface, thereby providing WTRU102a, 102b, and 102c access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-corresponding devices. UPF184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-home PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0060] CN115 may facilitate communication with other networks. For example, CN115 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN115 and PSTN108. Additionally, CN115 may provide access to other network 112 for WTRU102a, 102b, 102c, and other network 112 may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to local data network (DN) 185a, 185b through UPF184a, 184b via an N3 interface to UPF184a, 184b and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0061] In view of FIGS. 1A-1D and the corresponding descriptions thereof, one or more of the functions described herein with respect to one or more of WTRU102a-d, base stations 114a and b, eNode-Bs 160a-c, MME162, SGW164, PGW166, gNBs 180a-c, AMFs 182a-ab, UPFs 184a and b, SMFs 183a and b, DNs 185a and b, and / or any other device described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functionality.

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

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

[0064] The techniques described herein can be associated with an edge enhancement architecture and / or can be used to minimize (e.g., prevent) an ACR failure. As described herein, a WTRU can discover and select edge services using an EES that is not a registrar EES. An EES instance deployed within an EDN can share registered EAS information and can provide, for example, EAS information and registrar EES information to a WTRU during edge service discovery.

[0065] Common terms applicable to the disclosed embodiments are defined. A registrar EES may refer to an EES instance in which an EAS instance is registered.

[0066] An anchor EES may refer to an EES instance used by an EEC to discover and select edge services within an EDN.

[0067] Registrar EES information may refer to information regarding the EES instance in which an EAS is registered. Registrar EES information may include a unique EES identifier, any information from the EES profile, or any data specific to the EES instance.

[0068] EAS information may refer to information regarding the EAS instance registered in an EES. EAS information may include a unique EAS identifier, any information from the EAS profile, or any data specific to the EAS instance.

[0069] A repository may refer to a central location where data is stored. An EES may perform a repository function to store and share EAS information and registrar EES information.

[0070] A WTRU may request that an EES provide EAS information from one or more EES instances within an EDN. The WTRU may use the discovered EAS information and registrar EES information to select an EAS and communicate with the registrar EES of the selected EAS for ACR scenario selection and provisioning.

[0071] The WTRU may request that the EES perform an anchor EES function. The WTRU may use the discovered EAS information to select an EAS and may select and provision an ACR scenario with the anchor EES. The anchor EES may determine that the selected EAS is registered with a different EES. The anchor EES may use the registrar EES as a proxy to communicate with the selected EAS.

[0072] Figure 2 is a system diagram illustrating an exemplary SA6 architecture 200 to enable edge applications. As shown in Figure 2, the components of the SA6 architecture 200 can include at least an Application Client (AC), an Edge Application Server (EAS), an Edge Enabler Client (EEC), an Edge Enabler Server (EES), an Edge Configuration Server (ECS), a Notification Management Client (NMC), and a Notification Management Server (NMS).

[0073] The AC can be a user application resident on a WTRU that communicates with the EAS. The WTRU can use several ACs simultaneously.

[0074] The EAS can be an application server resident in an Edge Data Network (EDN). Typically, it can be a software server running on general-purpose hardware located at the edge and providing services to the AC. In the context of mobility / relocation use cases, the Source-EAS (S-EAS) is an instance of the EAS at the initial location and provides services to the AC before mobility / relocation occurs. The Target-EAS (T-EAS) is an instance of the EAS at the destination location and provides services to the AC after mobility / relocation has occurred. There can be multiple EAS instances per EDN. Each EDN can include a different set of different types of EAS instances (e.g., different EAS IDs). The EAS can provide services to one or more AC instances resident on different WTRUs.

[0075] The EEC can provide edge support to an AC instance on a WTRU. There can be one or more EECs per WTRU. Each AC uses only one EEC.

[0076] EES provides the support functions required by EAS and EEC. In the context of mobility / relocation use cases, Source-EES (S-EES) is the EES used before mobility / relocation occurs. Target-EES (T-EES) is the EES used after mobility / relocation has occurred. There can be one or more EES instances per EDN (or per Data Network Name (DNN)). Multiple EDN instances can exist within the network.

[0077] ECS may provide a support function to discover the EES instance that provides a particular EAS where there is an EEC or EES. One or more ECSs can exist for the network.

[0078] NMC may provide a support function for the EEC to create a notification channel between the NMC and the NMS to receive notifications from the ECS or EES. Each EEC uses only one NMC.

[0079] NMS may provide a support function for the ECS or EES to send notifications to the EEC via the notification channel created between the NMC and the NMS. One or more NMSs can exist for the network.

[0080] The service continuity procedure for transferring the application context from S-EAS to T-EAS can be defined in the Edge Enablement Layer (EEL). For example, context transfer can be triggered by, for example, WTRU mobility and / or non-mobility events such as EAS server maintenance, overload, etc. Service continuity can be used to minimize the interruption of edge services to the AC running on the WTRU.

[0081] FIG. 3 is a flowchart 300 illustrating a high-level overview of application context relocation (ACR). Service continuity for applications that require context relocation can be specified by the EEL in five different application context relocation (ACR) scenarios. Each scenario can be composed of one or more (e.g., four) different phases including detection, decision, execution, and post-execution. The ACR scenarios can specify different EEL entities (e.g., EEC, EES, EAS) for the detection phase and the decision phase (e.g., detection entity and decision-making entity). Different sets of interactions between the EEL entities can be defined for the execution phase.

[0082] The detection entity can monitor the location and movement of the WTRU and can notify the decision-making entity. The decision-making entity then determines whether ACR is required and instructs the execution entity to execute the ACR. The execution entity then executes the ACR procedure defined in the service continuity scenario to transfer the application context from the S-EAS to the T-EAS. When the ACR execution is complete, ACR cleanup is performed.

[0083] EAS information sharing capabilities and configurations are disclosed herein. Sharing EAS information between EES instances within the EDN requires that the EAS information sharing participants provide the EAS information sharing capabilities. This can enable the determination of the EAS information sharing configuration to be applied. The EAS information sharing participants are the EESs.

[0084] The EAS information sharing capabilities can include an indication that the EES is capable of supporting EAS information sharing, a list of supported sharing methods, an indication that the EES can be a repository of EAS information, a notification URL for receiving EAS information sharing configuration updates, and the EAS information sharing configuration.

[0085] The EAS information sharing configuration may include a selected sharing method, one or more repository addresses (e.g., IP address, URI, FQDN), and endpoints, as well as a list of EES instances that share the registered EAS information.

[0086] In a centralized EAS information sharing configuration, when supported, EES instances deployed within the EDN may share the registered EAS information. The centralized approach may be used to share EAS information among EES instances. The repository function may be added to one or more EESs such that during EES registration, the registrar EES instance may receive information about the EES repository to be used for sharing EAS information. An EES instance may publish EAS information to the EES repository and obtain updated EAS information from the EES repository. If multiple EES repositories are configured in the EDN, they may synchronize data to provide consistent EAS information.

[0087] FIG. 4 is a flowchart 400 illustrating EAS information sharing using an EES repository according to one embodiment. As shown in FIG. 4, EES-1 404 may execute a repository function, for example, to support EAS information sharing.

[0088] At 410, EES-1 404 may send an EES registration request to ECS402. The EES registration request may include EAS information sharing capabilities. For example, EES-1 404 may indicate that it supports centralized EAS information sharing and / or provide an indication that it can be an EAS information repository for the EDN.

[0089] At 412, the ECS 402 may send an EES registration response to the EES-1 404. The EES registration response may include an EAS information sharing configuration applied in the EES. The ECS 402 may use the EES instance to be registered and the EAS information sharing capabilities of the registered EES instance to determine which EAS information sharing configuration to return. The ECS 402 may determine that one or more EES repositories are available and may decide to configure one or more EES repositories in the EAS information sharing configuration. When multiple EES repositories are configured within the EDN, the EES repositories may synchronize data to ensure data consistency within the EDN.

[0090] For example, the ECS 402 may determine that the EES-1 404 is the only EES in the EDN and that the EES-1 404 supports a repository function. The ECS 402 may select the EES-1 404 as the EAS information repository for the EDN and may include the EES-1 repository connection information in the EAS information sharing configuration. Alternatively, the ECS 402 may determine that multiple EES instances support the repository function and may select multiple EES instances as the EAS information repository.

[0091] At 414, the EES-2 406 may send an EES registration request to the ECS 402. The EES registration request may include EAS information sharing capabilities. For example, the EES-2 406 may indicate that it supports centralized EAS information sharing.

[0092] At 416, the ECS 402 may send an EES registration response to the EES-2 406. The EES registration response may include an EAS information sharing configuration applied in the EES. The ECS 402 may use the EES instance to be registered and the EAS information sharing capabilities of the registered EES instance to determine the EAS information sharing configuration.

[0093] For example, ECS402 may indicate that a repository should be used for EAS information sharing and may include EES-1 repository connection information in the EAS information sharing configuration.

[0094] In 418, EES-2 406 may send an EAS information search request to a provisioned EES-1 repository (e.g., EES-1 404) to obtain the latest EAS information. The EAS information search request may be triggered by EES-2 406 receiving the EES-1 repository connection information.

[0095] Although not shown in FIG. 4, EES-2 406 may subscribe to notifications from the EES-1 repository (e.g., EES-1 404), for example, when EAS information is updated in the repository. The subscribe operation may be triggered by EES-2 receiving the EES-1 repository connection information.

[0096] In 420, the EES-1 repository (e.g., EES-1 404) may send an EAS information search response to EES-2 406. The EAS information search response may include a list of EAS information and registrar EES information for each EAS instance.

[0097] For example, if the repository contains EAS information regarding the EAS instances registered in EES-1 404, the EAS information search response may include the EAS profiles of the registered EAS instances and the EES profile of EES-1 404.

[0098] In 422, EAS408 may execute an EAS registration procedure with EES-2 406.

[0099] At 424, the EES-2 406 may send an EAS information update request to a provisioned EES-1 repository (e.g., EES-1 404). The EAS information update request may include a list of EAS information for the EAS instances registered in the EES-2 406, and may include registrar EES information for the EES-2 406.

[0100] At 426, the EES-1 repository (e.g., EES-1 404) may send an EAS information update response to the EES-2 406. The EAS information update response may include a list of EAS information, and registrar EES information for each EAS instance.

[0101] For example, if the repository includes updated EAS information from any of the EES instances in the EDN, the EES-1 repository (e.g., EES-1 404) may include the updated EAS information and registrar EES information in the EAS information update response.

[0102] Although not shown in FIG. 4, the EES-1 repository (e.g., EES-1 404) may be notified of changes to the EAS information repository by the subscribed EES instances from the same EDN.

[0103] In a distributed EAS information sharing configuration, when supported, the EES instances deployed within the EDN may share the registered EAS information. The distributed approach may be used to share EAS information among EES instances. An EES instance may obtain a list of EESs within the same EDN and issue an EAS information update for one or more EESs from this list.

[0104] FIG. 5 is a flowchart 500 illustrating an example associated with distributed EAS information sharing. At 512, the EES-1 504 may send an EES registration request to the ECS 502. The EES registration request may include an EAS information sharing capability.

[0105] For example, EES-1 504 may indicate that it supports distributed EAS information sharing and may provide a URL and an endpoint for receiving EAS information updates.

[0106] In 514, ECS502 may send an EES registration response to EES-1 504. The EES registration response may include the EAS information sharing configuration applied in the EES. ECS502 may use the EES instance to be registered and the EAS information sharing capabilities of the registered EES instance to determine the EAS information sharing configuration to be returned.

[0107] For example, ECS502 may determine that distributed EAS information sharing should be used and may add EES-1 504 to the list of EES instances in the EDN for which EAS information is to be shared.

[0108] In 516, an EAS (e.g., EAS-1 506, etc.) may execute an EAS registration procedure with EES-1 504. EES-1 504 may use the provisioned EAS information sharing configuration to determine whether an EAS information update is required.

[0109] For example, EES-1 504 may be the only EES instance in the EDN within the configured EAS information sharing list and may not need to send EAS information to other EES instances.

[0110] In 518, EES-2 508 may send an EES registration request to ECS502. The EES registration request may include EAS information sharing capabilities.

[0111] For example, EES-2 508 may indicate that it supports distributed EAS information sharing and may provide a URL and an endpoint for receiving EAS information updates.

[0112] At 520, the ECS502 may send an EES registration response to the EES-2 508. The EES registration response may include an EAS information sharing configuration applied in the EES (e.g., the EES-2 508). The ECS502 may use the EAS information sharing capabilities of the EES instance to be registered and the registered EES instance to determine the EAS information sharing configuration.

[0113] For example, the ECS502 may indicate that distributed EAS information sharing should be used and may add the EES-2 508 to the list of EES instances that should share EAS information within the EDN.

[0114] Although not shown in FIG. 5, the registered EES may use the provisioned EAS information sharing configuration to determine, for example, whether EAS information update is necessary.

[0115] For example, the EES-2 508 may know that the EES-1 504 is on the list of EES instances that share EAS information. However, the EES-2 508 may not have any registered EAS instance information to share and may not need to send an EAS information update.

[0116] At 522, the ECS502 may send an EAS information sharing configuration update notification to the EES-1 504. The EAS information sharing configuration update notification may include an updated EAS information sharing configuration applied in the EES-1 504.

[0117] For example, the ECS502 may notify the EES-1 504 that the EES-2 508 is currently available for EAS information sharing.

[0118] At 524, the EES-1 504 may send an EAS information update notification to the EES-2 508. The EAS information update notification may include a list of EAS information for the EAS instances registered in the EES-1 504.

[0119] At 526, an EAS (e.g., EAS-2 510) may execute an EAS registration procedure with an EES-2 508. The EES-2 508 may use a provisioned EAS information sharing configuration to determine whether EAS information update is necessary.

[0120] For example, the EES-2 508 may determine that new EAS instance information should be provided to the EES-1 504.

[0121] The EES-2 508 may send an EAS information update notification to the EES-1 504. The EAS information update notification may include a list of EAS information about the EAS instances registered in the EES-2 508.

[0122] The solution solves the problem that a WTRU cannot discover edge services registered in an EES instance other than the one that processes the request. The solution also solves the problem that when a WTRU is permitted to discover edge services registered in other EES instances, the WTRU cannot determine in which EES instance the discovered EAS instance is registered. The WTRU may not be able to indicate the selected EAS and ACR scenario to the EES in which the selected EAS is registered, which may cause the service continuity procedure to fail. This solution enables the WTRU to obtain the registrar EES information necessary to indicate the EAS and ACR scenario information within the EES in which the selected EAS is registered.

[0123] The WTRU may perform the following actions to discover and select edge services within the EDN. The WTRU may send a service provisioning request to the ECS. The WTRU may receive a service provisioning response from the ECS, the service provisioning response may include EDN configuration information, the EDN configuration information may include a list of EES instances and the EAS information sharing capabilities of the EAS instances, and the EAS information sharing capabilities may indicate that the EES is capable of supporting EAS information sharing. The WTRU may select an EES instance according to the EAS information sharing capabilities of the EES. On the condition that the EAS information sharing capabilities of the EES indicate that the EES is capable of obtaining EAS information from other EES instances within the EDN, the WTRU may send an EAS discovery request to the selected EES, the EAS discovery request may include a list of one or more other EES instances for obtaining EAS information, or may include an indication that the EAS information may be obtained from other EES instances in the EDN, and the WTRU may receive an EAS discovery response from the selected EES, the EAS discovery response may include a list of EAS instance information, may include information on the registrar EES for each discovered EAS instance, the registrar EES is the EES instance where the EAS is registered, and the registrar EES information may include a unique EES identifier, an EES profile, and any information specific to the registrar EES instance, and select an EAS instance according to the EAS instance information and / or the registrar EES information. On the condition that the registrar EES of the selected EAS instance is different from the selected EES instance from the EAS discovery response, the WTRU may obtain the registrar EES profile using the registrar EES information, the registrar EES profile may be obtained from the local cache, from the EAS discovery response, or by performing a service provisioning procedure with the ECS, and may select an ACR scenario according to the EAS instance information and the registrar EES information and profile. The WTRU may send an EAS information provisioning request to the registrar EES, and the EAS information provisioning request may include the selected EAS and the ACR scenario.The WTRU may receive an EAS information provisioning response from a registrar EES, the EAS information provisioning response may include an indication that a selected EAS and ACR scenario has been accepted or rejected, the rejection indication may include EAS instance information and registrar EES information for different EAS instances, and the returned EAS instance may be requested or preferred by the EES. On the condition that the registrar EES of the EAS instance returned in the EAS provisioning response is different from the EES instance that sent the EAS provisioning response, the WTRU may send an EAS information provisioning request to the registrar EES of the EAS instance returned in the EAS provisioning response, may receive an EAS information provisioning response from the registrar EES, and the EAS information provisioning response may include an indication that the selected EAS and ACR scenario has been accepted.

[0124] One or more techniques associated with edge service discovery and selection using registrar EES information are disclosed herein. The WTRU may determine to discover edge services in the EDN without having to query each EES in the EDN. When supported by an EES, the WTRU may send a discovery request to one EES in the EDN, for example, to obtain EAS information and registrar EES information from one or more EES instances in the EDN. The WTRU may use the discovered EAS information and registrar EES information to select an EAS and communicate with the registrar EES of the selected EAS for selection and provisioning of ACR scenarios.

[0125] FIG. 6 is a flowchart 600 illustrating an example associated with edge service discovery and selection using registrar EES information. At 614, EES instances (e.g., EES608, registrar EES610) within an EDN may register with an ECS606. EAS instances (e.g., EAS612) within an EDN may register with an EES (e.g., registrar EES610). EES608 may receive EAS information from an EAS information update notification sent by another EES (e.g., registrar EES610).

[0126] The EES registration request may include the EAS information sharing capability of the EES instance. The ECS606 may use the EAS information sharing capability to determine the EAS information sharing configuration for each EES instance. An EAS (e.g., EAS612) may register with one of the EES instances (e.g., registrar EES610). The registrar EES610 may share the registered EAS information with other EES instances within the same EDN.

[0127] Further, or alternatively, the AC602 may register with the EEC604 at 616 and may request an edge service.

[0128] At 618, the EEC604 may send a service provisioning request to the ECS606.

[0129] At 620, the ECS606 may send a service provisioning response to the EEC604. The service provisioning response may include the EAS information sharing capability of the EES instance.

[0130] For example, the EAS information capability may notify the EEC604 about which EES instance may be used to obtain EAS information from all EES instances within the EDN.

[0131] At 624, the EEC 604 may select an EES to be used for edge service discovery. The EEC 604 may consider the EAS information sharing capabilities of the EES instance while making the selection.

[0132] For example, the EEC 604 may prefer to select an EES instance from an EDN that supports EAS information sharing.

[0133] At 626, the EEC 604 may send a discovery request (e.g., an EAS discovery request) to the selected EES (e.g., EES 608) to obtain, for example, EAS information and registrar EES information for a plurality of EES instances. The discovery request may include a list of one or more EES instances for which EAS information is requested, or may indicate that EAS information is requested from a plurality of (e.g., all) EES instances within the EDN. The discovery request may include an indication that EAS information is requested from a plurality of EES instances. The EEC 604 may send the discovery request at 626 on the condition that the EAS information sharing capabilities of the selected EES (e.g., EES 608) indicate that the selected EES (e.g., EES 608) is capable of obtaining EAS information from other EES instances within the EDN.

[0134] EES608 can determine EAS information and registrar EES information about EAS instances registered in other EES instances. For example, EES608 can determine EAS information and registrar EES information based on an EAS information sharing configuration associated with EES608. The EAS information sharing configuration associated with EES608 can include a selected sharing method, one or more repository addresses, one or more repository endpoints, and / or a list of EES instances sharing EAS information. When receiving a discovery request (e.g., an EAS discovery request), EES608 can obtain EAS information and registrar EES information about the requested EES instance. EES608 can obtain EAS information and registrar EES information from a local cache of EAS information sharing results or by sending an EAS information search request to an EES repository. EES608 can store EAS information and registrar EES information about EAS instances registered in other EES instances. The registrar EES information can include a unique EES identifier, an EES profile, and / or other information unique to the registrar EES instance.

[0135] In 628, the selected EES (e.g., EES608) can send a discovery response (e.g., an EAS discovery response) to EEC604. The discovery response can include a list of EAS information (e.g., EAS instance information) and can include registrar EES information about one or more EAS instances (e.g., when the registrar EES610 is different from the selected EES608). The discovery response can indicate one or more ACR scenarios supported by one or more EAS instances within the list of EAS information.

[0136] For example, if EES608, which processes an EAS discovery request, does not have an EAS instance registered but has received EAS instance information from another EES instance, EES608 that processes the request can provide the EAS profile of the EAS instance and its registrar EES information in the EAS discovery response.

[0137] At 630, the EEC604 may select an EAS instance (e.g., EAS612) and / or an ACR scenario for provisioning. While making the selection, the EEC604 may consider the EAS information from each discovered EAS and the registrar EES information. This information enables the EEC604 to make a better information-based selection within the EDN. For example, at 630, the EEC604 may select an EAS instance based on a list of EAS information and / or registrar information for one or more EAS instances. At 630, the EEC604 may select an EAS instance having a registrar EES610 different from the EES instance (e.g., EES608) selected at 624. At 630, the EEC604 may select one or more ACR scenarios based on a list of EAS information or one or more of the registrar EES information for each discovered EAS instance. For example, at 630, the EEC604 may select one or more ACR scenarios according to the EAS information, the registrar EES information, and / or the registrar EES profile.

[0138] For example, in a single EAS discovery procedure, the EEC604 may have obtained the EAS information of all EAS instances within the EDN, and at 630, while making the EAS and ACR scenario selection, the EEC604 may compare the key performance indicators (KPIs) or service continuity capabilities from all EAS and registrar EES instances.

[0139] If the selected EAS instance is registered with the EES608 used for edge service discovery, the EAS and ACR scenario selection may continue using the existing procedure. If the selected EAS instance is registered with a different EES, the EEC604 may use the registrar EES information to determine where the service provisioning request should be sent.

[0140] Although not shown in FIG. 6, EEC604 may need to obtain a registrar EES profile from locally cached service provisioning results, or EEC604 may need to re-execute the service provisioning procedure. For example, EEC604 may obtain a registrar EES profile using registrar EES information. The registrar EES profile may be obtained from a local cache, from a discovery response, or by executing an edge service provisioning procedure at ECS606. The edge service provisioning procedure may include EAS information provisioning as described herein. ACR scenario selection may require re-evaluation using the registrar EES service continuity capability. Finally, EEC604 may need to register with a selected registrar EES (e.g., registrar EES610) if the registrar EES610 requires EEC registration.

[0141] At 632, EEC604 may execute one or more edge service provisioning procedures (e.g., EAS information provisioning, etc.) with the registrar EES610 of the selected EAS instance (e.g., EAS612). For example, at 632, EEC604 may send an EAS information provisioning request to the registrar EES610. The EAS information provisioning request may indicate the selected EAS instance (e.g., EAS612) and one or more ACR scenarios. At 632, EEC604 may receive an EAS information provisioning response indicating registrar EES information on the condition that the selected EAS instance (e.g., EAS612) and / or one or more selected ACR scenarios are rejected. Additionally or alternatively, EES608 may send an EAS information request to a repository, for example, when the EAS information sharing configuration indicates that EES608 supports EAS information sharing with the repository. EES608 may receive an EAS information response from the repository. The EAS information response may include EAS information and registrar EES information for EAS instances registered with other EES instances among a plurality of EES instances.

[0142] At 634, the AC602 may establish a service session with a selected EAS instance (e.g., EAS612).

[0143] Edge service provisioning using registrar EES information is disclosed herein. A WTRU may desire to discover edge services within an EDN without the need to query each EES within the EDN. When supported by an EES, the WTRU may send a discovery request to one EES within the EDN to obtain EAS information and registrar EES information from one or more EAS instances within the EDN. The WTRU may use the discovered EAS information and registrar EES information to select an EAS and communicate with the registrar EES of the selected EAS for ACR scenario selection and provisioning.

[0144] The solution solves the problem that EAS information is only available in the EES in which the EAS is registered. The solution also solves the problem that an EES can only provide EAS information about the EAS instances registered in that EES. The EES may perform the following actions to enable discovery and selection of edge services within the EDN. The EES may send an EES registration request to the ECS, and the EES registration request may include an EAS information sharing capability, and the EAS information sharing capability may include an indication that the EES is capable of supporting EAS information sharing, a list of supported sharing methods, a list of EES instances for sharing EAS information, a notification URL for receiving EAS information sharing configuration updates, an address (e.g., IP address, URI, FQDN) and endpoint for receiving EAS information updates, and an indication that the EES may be a repository for EAS information. The EES may receive an EES registration response having an EAS information sharing configuration, and the EAS information sharing configuration may include a selected sharing method, one or more repository addresses (e.g., IP address, URI, FQDN), and a list of EES instances sharing the registered EAS information.

[0145] On the condition that the EAS information sharing configuration includes a repository, the EES may send an EAS information search request to the repository and may receive an EAS information search response from the repository. The EAS information search response may include a list of EAS information and registrar EES information for each EAS instance. The registrar EES is the EES instance in which the EAS is registered, and the registrar EES information may include a unique EES identifier, an EES profile, and any information specific to the registrar EES instance.

[0146] On the condition that EAS registration is executed with the EES, the EES may send an EAS information update request to the repository. The EAS information update request may include a list of EAS information for the EAS instances registered with the EES, and the EES may receive an EAS information update response from the repository. The EAS information search response may include a list of EAS information and registrar EES information for each EAS instance.

[0147] On the condition that the EAS information sharing configuration provides a list of EES instances that share EAS information, and on the condition that an EAS information sharing configuration update notification is received together with an updated list of EES instances that share EAS information, or on the condition that EAS registration is executed in the EES, the EES may send an EAS information update notification to one or more of the EES instances. The EAS information notification may include a list of EAS information and registrar EES information. The registrar EES is the EES instance in which the EAS is registered, and the registrar EES information may include a unique EES identifier, an EES profile, and any information specific to the registrar EES instance.

[0148] The EES may store EAS information received through EAS information sharing, and the received EAS information may be obtained by querying a repository or from an EAS information update notification sent by another EES instance within the EDN. The EES may receive an EAS discovery request from a UE / EEC, and the EAS discovery request may include a list of one or more EES instances for obtaining EAS information and may include an indication that the EAS information should be obtained from all EES instances in the EDN. The EES may send an EAS discovery response to the UE / EEC, and the EAS discovery response may include a list of EAS information and may include registrar EES information for each discovered EAS instance, and the EAS information may have been obtained from EAS information sharing. The EES may receive an EAS information provisioning request from a WTRU, and the EAS information provisioning request includes a selected EAS and an ACR scenario. The EES may evaluate the selected EAS and ACR scenario, and the evaluation may check whether the selected EAS is registered with another EES, verify that the selected ACR scenario can be configured, and also verify whether there is an EAS (e.g., preferred or requested) already configured for this WTRU. The EES may send an EAS information provisioning response to the WTRU, and the EAS information provisioning response may include an indication that the selected EAS and ACR scenario have been accepted or rejected, and the rejection indication may include EAS instance information and registrar EES information for different EAS instances, and the returned EAS instance may be requested or preferred by the EES.

[0149] FIG. 7 is a flowchart 700 illustrating an example associated with edge service provisioning using resistra EES information. At 716, one or more EES instances (such as, for example, EES-1 708 and EES-2 712, etc.) within the EDN may register with the ECS706. The EES registration request may include the EAS information sharing capabilities of the EES instance (such as, for example, EES-1 708 and EES-2 712, etc.). The ECS706 may use the EAS information sharing capabilities to determine the EAS information sharing configuration for each EES instance. One or more EAS instances (such as, for example, EAS-1 710 and EAS-2 714, etc.) may register with the EES instance (such as, for example, EES-1 708 and EES-2 712, etc.) and may trigger EAS information sharing among the EES instances (such as, for example, EES-1 708 and EES-2 712, etc.) within the EDN.

[0150] Further, or alternatively, the AC702 may register with the EEC704 at 718 and may request an edge service. The EEC704 may obtain the EDN configuration information and the EES information using the service provisioning procedure. The EEC704 may select an EES and may use the selected EES to discover an EAS instance.

[0151] At 720, the EEC704 may select an EAS and / or ACR scenario.

[0152] At 722, the EEC704 may send an EAS information provisioning request to the selected EES (such as, for example, EES-1 708).

[0153] At 724, EES708 may send an EAS information provisioning response to EEC704. The EAS information provisioning response may include EAS instance information and registrar EES information for different (e.g., preferred or requested) EAS instances. If the selected EAS instance is registered with a different EES, EEC704 may use the registrar EES information to determine where the EAS information provisioning request should be sent.

[0154] At 726, EEC704 may reselect an ACR scenario according to the service continuity capabilities of the registrar EES. EEC704 may obtain the registrar EES profile from locally cached service provisioning results, or EEC704 may re - execute the service provisioning procedure. The ACR scenario selection may be re - evaluated using the registrar EES service continuity capabilities. If the registrar EES requires EEC registration, EEC704 may need to register with the selected registrar EES.

[0155] At 728, EEC704 may execute an edge service provisioning procedure (e.g., an EAS information provisioning procedure, etc.) with the registrar EES (e.g., EES - 2 712) of the selected EAS instance (e.g., EAS - 2 714).

[0156] At 730, AC702 may establish a service session with the selected EAS instance (e.g., EAS - 2 714).

[0157] Edge service discovery using an anchor EES is disclosed herein. The WTRU may desire to discover edge services within the EDN without having to query each EES in the EDN. When supported by an EES, the WTRU may select one EES to operate as an anchor EES. The WTRU may communicate with the anchor EES to obtain EAS information from other EES instances within the EDN.

[0158] Figure 8 is a flowchart 800 illustrating an example associated with edge service discovery using an anchor EES. At 814, an EES (e.g., anchor EES 808) may send an EES registration request to the ECS 806. The EES registration request may include anchor EES capabilities. The anchor EES capabilities may include an indication that the EES (e.g., anchor EES 808) supports anchor EES functionality.

[0159] At 816, the ECS 806 may send an EES registration response to the EES (e.g., anchor EES 808).

[0160] At 818, the EAS 812 may register with one of the EES instances (e.g., registrar EES 810). The registrar EES 810 may share the registered EAS information with other EES instances within the same EDN.

[0161] At 820, the AC 802 may register with the EEC 804 and may request an edge service.

[0162] At 822, the EEC 804 may send a service provisioning request to the ECS 806.

[0163] At 824, the ECS 806 may send a service provisioning response to the EEC 804. The service provisioning response may include the anchor EES capabilities of the EES instance.

[0164] For example, the anchor EES capabilities may notify the EEC 804 about which EES instance may be used as an anchor EES within the EDN.

[0165] At 826, the EEC 804 may select an EES to use for edge service discovery. The EEC 804 may consider the anchor EES capabilities of the EES instance while making the selection.

[0166] For example, EEC804 may select an EES instance that supports the anchor EES function.

[0167] At 828, EEC804 may send an EEC registration request to the selected EES (e.g., anchor EES808). The EEC registration request may include an indication that the EES (e.g., anchor EES808) has been selected as the anchor EES for the requesting EEC804.

[0168] At 830, the selected EES (e.g., anchor EES808) may send an EEC registration response to EEC804. The EEC registration response may include an indication that the EES (e.g., anchor EES808) accepts being the anchor EES for the requesting EEC804. Anchor EES808 may create and maintain an EEC context and an EAS mapping to appropriately process future requests from EEC804.

[0169] At 832, EEC804 may send an EAS discovery request to anchor EES808. The EAS discovery request may include an indication that the EES (e.g., anchor EES808) has been selected as the anchor EES for the requesting EEC804. The indication that the EES (e.g., anchor EES808) has been selected as the anchor EES may be omitted if EEC804 has already provided this indication during EEC registration.

[0170] At 834, anchor EES808 may send an EAS discovery response to EEC804. The EAS discovery response may include a list of EAS instance information obtained from all EES instances in the EDN.

[0171] For example, the anchor EES (e.g., anchor EES808) may return the discovered EAS instances obtained from the EAS information sharing.

[0172] The solution solves the problem that the EES can only provide EAS information about the EAS instances registered in that EES. The solution also solves the problem that when the EES is permitted to provide EAS information about EAS instances registered in other EES instances, the WTRU may provision the selected EAS and ACR scenario in an EES where the selected EAS is not registered, which may lead to service continuity disruptions. This solution enables the EES to correctly handle service continuity provisioning for EASs registered in another EES.

[0173] The EES may perform the following actions to enable discovery and selection of edge services within the EDN. The EES may send an EES registration request to the ECS. The EES registration request may include an indication that the EES is capable of performing the anchor EES function. The anchor EES is an EES instance that can be used by the WTRU as a gateway for performing edge service discovery, selection, and provisioning procedures within the EDN.

[0174] The EES may receive an EEC registration request from the WTRU. The EEC registration request may include an indication that the EES has been selected as the anchor EES.

[0175] The EES may send an EEC registration response to the WTRU. The EEC registration response may include an indication that the EES accepts being the anchor EES for the WTRU.

[0176] The EES may receive an EAS discovery request from the WTRU. The EAS discovery request may include an indication that the EES has been selected as the anchor EES.

[0177] The EES may send an EAS discovery request to the WTRU. The EAS discovery response may include an indication that the EES accepts being the anchor EES for the WTRU and may include a list of EAS information obtained from one or more EES instances within the EDN.

[0178] On the condition that the anchor EES receives an EAS information provisioning request from the WTRU, and on the condition that the selected EAS provided in the EAS information provisioning request is registered in another EES instance, the anchor EES may send an EAS proxy setup request to the registrar EES, where the registrar EES is the EES instance in which the EAS is registered, the EAS proxy establishment request may include EAS proxy configuration information, and the EAS proxy configuration information may include the selected EAS profile, as well as the anchor EES address (e.g., IP address, URI, FQDN) and endpoint. The anchor EES may receive an EAS proxy setup response from the registrar EES, and the EAS proxy establishment response may include an indication that the EAS proxy has been successfully established and configured. The anchor EES may send an EAS proxy request to the EAS proxy in the registrar EES, and the EAS proxy request may include a message to be sent to the selected EAS, and the message may be an ACR management event notification of type "ACR selection".

[0179] Edge service selection and provisioning using the anchor EES are disclosed herein. After discovering an edge service within the EDN, the WTRU may select an EAS, select and provision an ACR scenario using the anchor EES. The anchor EES may determine that the selected EAS is registered in a different EES and may use the registrar EES as a proxy to communicate with the selected EAS.

[0180] FIG. 9 is a flowchart 900 illustrating an example associated with edge service selection and provisioning using the anchor EES. At 914, an EES instance within the EDN may register with the ECS 906. The EES registration request may include the anchor EES capabilities of the EES instance. The EAS 912 may register with one of the EES instances (e.g., the registrar EES 910). The registrar EES 910 may share the registered EAS information with other EES instances within the same EDN.

[0181] Furthermore, or alternatively, at 916, AC902 may register with EEC904 and may request edge services. EEC904 may obtain EDN configuration information and EES information using service provisioning procedures. EEC904 may select an anchor EES908 and may use the anchor EES908 to discover EAS instances.

[0182] Furthermore, or alternatively, at 918, EEC904 may select an EAS instance and / or an ACR scenario for provisioning. When selecting an ACR scenario, EEC904 may consider the service continuity capabilities of the anchor EES908.

[0183] At 920, EEC904 may send an EAS information provisioning request to the anchor EES908.

[0184] The anchor EES908 may use the EAS information and registrar EES information obtained from EAS information sharing to verify whether the selected EAS (e.g., EAS912) is registered with another EES instance. If the selected EAS instance is registered with a different EES instance, at 922, the anchor EES908 may send an EAS proxy setup request to the registrar EES910 of the selected EAS to establish and configure an EAS proxy. The EAS proxy setup request may include EAS proxy configuration information. The EAS proxy configuration information may include the selected EAS profile, and the anchor EES address (e.g., IP address, URI, FQDN), and / or an endpoint for processing requests proxied from EAS912.

[0185] For example, the registrar EES910 may have published the EAS information of the EAS instances registered with the registrar EES910 to the EES repository. The anchor EES908 may have retrieved the EAS information and the registrar EES information from the EES repository. The anchor EES908 may determine that a selected EAS (e.g., EAS912) is not registered with the anchor EES908 and may use this information to trigger the establishment of an EAS proxy in the registrar EES910.

[0186] At 924, the registrar EES910 may send an EAS proxy setup response to the anchor EES908. The EAS proxy setup response may indicate whether the EAS proxy has been successfully established and configured.

[0187] At 926, the anchor EES908 may send an EAS proxy request to the EAS proxy in the registrar EES910. The EAS proxy request may include a message to be sent to the selected EAS (e.g., EAS912).

[0188] For example, during EAS and ACR scenario information provisioning, the anchor EES908 may indicate that an "ACR selection" ACR management event notification should be sent to the selected EAS (e.g., EAS912).

[0189] The EAS proxy in the registrar EES910 may send the requested message to EAS912.

[0190] For example, the EAS proxy in the registrar EES910 may send an ACR management event notification to the selected EAS (e.g., EAS912) to provide ACR selection information to EAS912 at 928.

[0191] In the registrar EES910, the EAS proxy can send an EAS proxy response to the anchor EES908 at 930. The EAS proxy response can indicate whether the request has been successfully processed by the EAS proxy.

[0192] At 932, the anchor EES908 can send an EAS information provisioning response to the EEC904. The EAS information provisioning response can include an indication that the selected EAS (e.g., EAS912) and the ACR scenario have been accepted.

[0193] At 934, the AC902 can establish a service session with the selected EAS instance (e.g., EAS912).

[0194] The following abbreviations and acronyms are included. Application Client (AC), Application Context Relocation (ACR), Data Network (DN), Data Network Name (DNN), Edge Application Server (EAS), Edge Configuration Server (ECS), Edge Data Network (EDN), Edge Enablement Client (EEC), Edge Enablement Layer (EEL), Edge Enablement Server (EES), Fully Qualified Domain Name (FQDN), Key Performance Indicator (KPI), Notification Management Client (NMC), Notification Management Server (NMS), Quality of Service (QoS), Source Edge Application Server (S-EAS), Source Edge Enablement Server (S-EES), Technical Specification (TS), Target Edge Application Server (T-EAS), Target Edge Enabler Server (T-EES), and Universal Resource Identifier (URI).

Claims

Claim 1 A wireless transmission / reception unit (WTRU) comprising a processor, the processor being configured to: send a discovery request to a first edge enabler server (EES) instance to obtain edge application server (EAS) information; receive a discovery response from the first EES instance, the discovery response indicating a list of EAS information and registrar EES information for one or more EAS instances within the list of EAS information; and select an EAS instance based on one or more of the list of EAS information or the registrar EES information for the one or more EAS instances, the selected EAS instance being registered with a second EES instance different from the first EES instance. Claim 2 The WTRU of claim 1, wherein the processor is further configured to send an EAS information provisioning request to the second EES instance, the EAS information provisioning request indicating the selected EAS instance and one or more selected application context relocation (ACR) scenarios. Claim 3 The WTRU of claim 1 or 2, wherein the processor is further configured to select the first EES instance from among a plurality of EES instances based on the EAS information sharing capabilities of the first EES instance. Claim 4 The WTRU of any one of claims 1 to 3, wherein the discovery request includes an indication that EAS information is requested from a plurality of EES instances. Claim 5 The WTRU of any one of claims 1 to 4, wherein the discovery request is sent on the condition that the EAS information sharing capabilities of the first EES instance indicate that the first EES instance is capable of obtaining EAS information from other EES instances within an edge data network (EDN). Claim 6 The WTRU of any one of claims 1 to 5, wherein the discovery request indicates a list of one or more other EES instances for obtaining EAS information. Claim 7 ​ The WTRU according to any one of claims 1 to 6, further configured such that the processor receives an EAS information provisioning response indicating registrar EES information on the condition that one or more of the selected EAS instances or one or more of the selected ACR scenarios are rejected. **Claim 8** The WTRU according to any one of claims 1 to 7, further configured such that the processor selects one or more ACR scenarios based on one or more of the list of the EAS information or the registrar EES information for each discovered EAS instance. **Claim 9** The WTRU according to claim 8, wherein the processor is further configured to obtain a registrar EES profile using the registrar EES information, and the registrar EES profile is obtained from a local cache, from the discovery response, or by executing a service provisioning procedure at an edge configuration server (ECS). **Claim 10** The WTRU according to claim 9, further configured such that the processor selects the one or more selected ACR scenarios according to the EAS information and the registrar EES information and profile. **Claim 11** A method performed by a wireless transmission / reception unit (WTRU), the method comprising: transmitting a discovery request to a first edge enabler server (EES) instance to obtain edge application server (EAS) information; receiving a discovery response from the first EES instance, the discovery response indicating a list of EAS information and registrar EES information for one or more EAS instances within the list of EAS information; selecting an EAS instance based on one or more of the list of the EAS information or the registrar EES information for the one or more EAS instances, wherein the selected EAS instance is registered with a second EES instance different from the first EES instance. **Claim 12** Further comprising transmitting an EAS information provisioning request to the second EES instance, wherein the EAS information provisioning request indicates the selected EAS instance and one or more selected application context relocation (ACR) scenarios, the method according to claim 11.

13. The method according to claim 11 or 12, further comprising selecting the first EES instance among the plurality of EES instances based on the EAS information sharing ability of the first EES instance.

14. The method according to any one of claims 11 to 13, wherein the discovery request includes an indication that EAS information is requested from a plurality of EES instances.

15. The discovery request is transmitted on the condition that the EAS information sharing ability of the first EES instance indicates that the first EES instance is capable of obtaining EAS information from other EES instances within an edge data network (EDN), the method according to any one of claims 11 to 14.

16. The method according to any one of claims 11 to 15, wherein the discovery request indicates a list of one or more other EES instances for obtaining EAS information.

17. The method according to any one of claims 11 to 16, further comprising transmitting an EAS information provisioning response indicating registrar EES information on the condition that one or more of the selected EAS instance or one or more selected ACR scenarios are rejected.

18. The method according to any one of claims 11 to 17, further comprising selecting one or more ACR scenarios based on one or more of the list of the EAS information or the registrar EES information for each discovered EAS instance.

19. The method according to claim 18, further comprising obtaining a registrar EES profile using the registrar EES information, wherein the registrar EES profile is obtained from a local cache, from the discovery response, or by executing a service provisioning procedure at an edge configuration server (ECS).

20. The method according to claim 19, further comprising selecting the one or more selected ACR scenarios according to the EAS information and the registrar EES information and profile.

Images