Wireless transmit / receive unit (WTRU) driven edge service discovery, selection and provisioning using shared edge application server (EAS) information and registrar edge enabler server (EES) information

Abstract

A wireless transmit / receive unit (WTRU) may send a discovery request to a first edge enabler 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 in the list of EAS information. The WTRU may select the EAS instance based on one or more of the list of EAS information or registrar EES information for the one or more EAS instances. A second EES instance of the plurality of EES instances may be a registrar EES of the selected EAS instance.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 466,372, filed May 15, 2023, the entire contents of which are incorporated herein by reference. Background Technology

[0002] The edge enablement service layer of a cellular communication system can have cardinality rules that restrict edge application server (EAS) registration to a single edge enabler server (EES). For a WTRU to discover available edge services, an EAS discovery request must be sent to the EES where the EAS is registered (e.g., the registrar EES). Discovery of a common EAS for a group of application clients (ACs) can be requested (e.g., by communicating with an EES that is not the registrar EES). Therefore, a cellular communication system can be configured to support EAS discovery, for example, by using an EES other than the registrar EES.

[0003] This article describes one or more techniques associated with using unregistered EES for discovery operations.

[0004] As a first instance, the WTRU can obtain information about available EAS instances in the EDN by sending an EAS discovery request to each EES instance within the EDN. Additionally, new use cases may require EAS information from one or more different registrar EES during edge service discovery or selection. For example, the WTRU can discover and select edge services without needing to connect individually to each EES in the EDN. The edge-enabled service layer of a cellular communication system can be used to enable edge service discovery, for example, by using EES other than the registrar EES that need to be discovered.

[0005] As a second example, a specific edge service discovery procedure can provide EAS information for EAS instances discovered registered to the EES that handle the request. For instance, if the EES can return EAS information from an EAS registered to another EES instance, the WTRU may be unable to determine which EES the EAS is registered to and cannot indicate the EAS and Application Context Relocation (ACR) scenario selection in the registrar EES. Service continuity procedure failure may occur. Therefore, the edge-enabled service layer of a cellular communication system can be used to enable the WTRU to obtain the registrar EES information required to correctly indicate the EAS and ACR scenario selection in the EES where the selected EAS is registered. Alternatively, the edge-enabled service layer of a cellular communication system can be used to enable the EES to correctly handle service continuity for EAS registered to another EES. Summary of the Invention

[0006] A Wireless Transmit / Receive Unit (WTRU) can send a discovery request to a first Edge Enabler Server (EES) instance to obtain Edge Application Server (EAS) information. The WTRU can receive a discovery response from the first EES instance. The discovery response may indicate the EES information list and / or the registrar EES information of one or more EES instances within the EES information list. The WTRU can select an EES instance based on one or more of the EES information list or the registrar EES information of one or more EES instances. A second EES instance among multiple EES instances can be the registrar EES of the selected EES instance.

[0007] The WTRU can send an EAS information provisioning request to a second EES instance. The EAS information provisioning request can indicate the selected EAS instance and one or more selected Application Context Relocation (ACR) scenarios. The WTRU can receive an information provisioning response from the second EES instance. The WTRU can select a first EES instance from a pool of EES instances based on the first EES instance's EAS information sharing capabilities. This discovery request can include indications to request EAS information from multiple EES instances. A discovery request can be sent if the first EES instance's EAS information sharing capabilities indicate that the first EES instance can obtain EAS information from other EES instances within the Edge Data Network (EDN). This discovery request can indicate a list of one or more other EES instances from which it obtains EAS information. The discovery response can indicate one or more ACR scenarios supported by one or more EAS instances in the EAS information list. The WTRU can receive an EAS information provisioning response indicating registrar EES information if one or more of the selected EAS instance or one or more selected ACR scenarios have been rejected.

[0008] WTRU can select one or more ACR scenarios based on one or more of the EAS information list or the registrar EES information for each discovered EAS instance. WTRU can use the registrar EES information to obtain a registrar EES profile. The registrar EES profile can be obtained from a local cache, from the discovery response, and / or by utilizing an Edge Configuration Server (ECS) to perform a service provisioning process. WTRU can select one or more ACR scenarios based on the EAS information and the registrar EES information and profile. Attached Figure Description

[0009] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments can be implemented.

[0010] Figure 1B The illustration shows an embodiment that can be usedFigure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system.

[0011] Figure 1C The illustration shows an embodiment that can be used Figure 1A The diagram shows a system diagram of an example radio access network (RAN) and an example core network (CN) used in a communication system.

[0012] Figure 1D The illustration shows an embodiment that can be used Figure 1A The diagram shows another example RAN and another example CN used in the communication system.

[0013] Figure 2 This is a system diagram illustrating an example SA6 architecture for enabling edge applications.

[0014] Figure 3 This is a flowchart illustrating a high-level overview of Application Context Relocation (ACR).

[0015] Figure 4 This is a flowchart illustrating information sharing by an Edge Application Server (EAS) using an Edge Enabler Server (EES) repository.

[0016] Figure 5 This is a flowchart illustrating an example associated with distributed EAS information sharing.

[0017] Figure 6 This is a flowchart illustrating an example of edge service discovery and selection associated with utilizing registrar EES information.

[0018] Figure 7 This is a flowchart illustrating an example of how edge service provision is associated with utilizing registrar EES information.

[0019] Figure 8 This is a flowchart illustrating an example associated with edge service discovery using anchored EES.

[0020] Figure 9 This is a flowchart illustrating an example of edge service selection and provisioning associated with using anchored EES. Detailed Implementation

[0021] Figure 1AThis diagram illustrates an example communication system 100 in which one or more of the disclosed embodiments may be implemented. Communication system 100 may be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. Communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Spread Spectrum OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), and the like.

[0022] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it will be appreciated that the disclosed embodiments are contemplated to any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 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 include user equipment (WTRUs), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and the like. Any of WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as WTRUs.

[0023] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), Node-B, eNode B, home Node B, home eNode B, gNB, NR Node B, site controllers, access points (APs), wireless routers, and the like. Although base stations 114a and 114b are each depicted as a single element, it will be appreciated that base stations 114a and 114b may include any number of interconnected base station and / or network elements.

[0024] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for radio services to a specific geographic area, which may be relatively fixed or may change over time. The cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0025] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116. Air interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

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

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

[0028] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as NR radio access, which can establish an air interface 116 using a new radio (NR).

[0029] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can jointly implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0030] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSMEDGE (GERAN), and the like.

[0031] Figure 1A Base station 114b can be, for example, a wireless router, a home Node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, and the like. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

[0032] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although inFigure 1A Although not shown, it will be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may utilize NR radio technology, CN106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0033] CN 106 / 115 can also serve as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

[0034] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capability (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example... Figure 1A The WTRU 102c shown can be configured to communicate with base station 114a, which can employ cellular-based radio technology, and with base station 114b, which can employ IEEE 802 radio technology.

[0035] Figure 1B This is a system diagram illustrating the example WTRU 102. (Example:) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It will be appreciated that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0036] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple 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, and the like. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmitting / receiving element 122. Although Figure 1B While the processor 118 and transceiver 120 are depicted as separate components, it will be understood that the processor 118 and transceiver 120 can be integrated together in an electronic package or chip.

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

[0038] Despite Figure 1B While the transmit / receive element 122 is described as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 116.

[0039] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers for example enabling WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

[0040] The processor 118 of WTRU 102 can be coupled to and receive user input data from: a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Furthermore, the processor 118 can access information from and store data in any suitable type of memory (such as non-removable memory 130 and / or removable memory 132). 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. Removable memory 132 may include a subscriber identity module (SIM) card, memory stick, secure digital storage (SD) card, and the like. In other embodiments, the processor 118 can access information from and store data in memory that is not physically located on WTRU 102 (such as a server or home computer (not shown)).

[0041] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0042] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about 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 base stations (e.g., base stations 114a, 114b) via air interface 116, and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0043] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, and the like. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, attitude sensors, biosensors, and / or humidity sensors.

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

[0045] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0046] RAN 104 may include eNode-Bs 160a, 160b, and 160c, although it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

[0047] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the UL and / or DL, and the like. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0048] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. While each of the foregoing elements is depicted as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0049] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, and so on. The MME 162 can provide control plane functions for switching between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0050] The SGW 164 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, managing and storing the context of WTRUs 102a, 102b, and 102c, and so on.

[0051] The SGW 164 can be connected to the PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0052] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRU 102a, 102b, 102c with access to a circuit-switched network such as PSTN 108 to facilitate communication between WTRU 102a, 102b, 102c and conventional landline communication equipment. For example, CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) serving as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRU 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0053] Despite WTRU in Figures 1A-1D While described as a wireless terminal, it is envisioned that in some representative embodiments, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0054] In a representative embodiment, another network 112 may be a WLAN.

[0055] In Infrastructure Basic Services Set (BSS) mode, a WLAN may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have access to or interfacing with a Distributed System (DS) or carry services within and / or out of the BSS to another type of wired / wireless network. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined outside the BSS can be sent to the AP for delivery to the appropriate destination. For example, traffic between STAs within the BSS can be sent via the AP, where the source STA can send traffic to the AP, and the AP can deliver 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 sent between a source STA and a destination STA (e.g., directly between the source STA and the destination STA) using Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to as the "self-organizing" communication mode in this document.

[0056] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., a wide bandwidth of 20 MHz) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, each STA, including the AP, can listen on the primary channel. If the primary channel is listened to / detected by a particular STA and / or determined to be busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0057] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels.

[0058] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining adjacent 20 MHz channels. A 160 MHz channel can be formed by combining eight adjacent 20 MHz channels, or by combining two non-adjacent 80 MHz channels—this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data passes through a segment resolver, which splits the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0059] 802.11af and 802.11ah support sub-1 GHz operating modes. Compared to the operating modes used in 802.11n and 802.11ac, the channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV Blank (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support metering-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities (e.g., limited capabilities) including support (e.g., only support) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0060] WLAN systems that support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STAs that support the minimum bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Assignment Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, the entire available band can be considered busy, even if most of the band remains idle and can be available.

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

[0062] Figure 1D This diagram illustrates a system diagram of RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0063] RAN 113 may include gNBs 180a, 180b, and 180c, although it should be understood that RAN 113 may include any number of GNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, GNBs 180a and 108b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Thus, for example, gNB 180a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. 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, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0064] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable digitization. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or varying absolute durations).

[0065] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without access to other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, while also communicating / connecting with another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0066] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, and the like. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0067] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements is depicted as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0068] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service types being used by WTRU 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, services for Machine Type Communication (MTC) access, and so on. AMF 162 can provide control plane functions for switching between RAN 113 and other RANs (not shown) that employ other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

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

[0070] UPF 184a and 184b can be connected via the N3 interface to one or more of gNB 180a, 180b, and 180c in RAN 113. This N3 interface provides WTRU 102a, 102b, and 102c with access to a packet-switched network (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-destination PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and so on.

[0071] CN 115 can facilitate communication with other networks. For example, CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) acting as an interface between CN 115 and PSTN 108. Furthermore, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c may be connected to local DNs 185a and 185b via the N3 interface to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and data networks (DNs) 185a and 185b.

[0072] Given Figures 1A-1D and Figures 1A-1D The corresponding descriptions herein regarding one or more of the functions of WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-ab, UPF184a-b, SMF 183a-b, DN 185a-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 functions.

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

[0074] One or more emulation devices may perform one or more functions (including all functions) but are not implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be used in test scenarios in a test laboratory and / or in non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. One or more emulation devices may be test equipment. Emulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0075] The techniques described in this article are associated with edge enhancement architectures and / or can be used to minimize (e.g., prevent) ACR failures. As described in this article, WTRU can use an EES that is not a registrar's EES to discover and select edge services. EES instances deployed within the EDN can share registered EAS information and can provide EAS and registrar's EES information to WTRU, for example, during edge service discovery.

[0076] General terminology applicable to the disclosed embodiments is defined. "Registrar EES" may refer to the EES instance to which the EAS instance is registered.

[0077] Anchored EES can refer to an EES instance used by the EEC to discover and select edge services within the EDN.

[0078] Registrar EES information can refer to information about the EES instance where 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.

[0079] EAS information can refer to information about an EAS instance that has been registered with EES. EAS information may include a unique EAS identifier, any information from the EAS profile, or any data specific to the EAS instance.

[0080] A repository can refer to a central location where data is stored. EES can perform repository functions to store and share EES information and registrar EES information.

[0081] WTRU can request EES to provide EAS information from one or more EES instances within EDN. WTRU can use the discovered EAS information and registrar EES information to select an EAS and communicate with the registrar EES of the selected EAS to select and provision ACR scenarios.

[0082] The WTRU can request the EES to perform the anchored EES function. The WTRU can use discovered EAS information to select an EAS and can select and provision ACR scenarios with anchored EES. Anchored EES can determine if the selected EAS is registered to a different EES. Anchored EES can use the registrar EES as a proxy to communicate with the selected EAS.

[0083] Figure 2 This is a system diagram illustrating an example SA6 architecture 200 for enabling edge applications. Figure 2 As shown, the components of the SA6 architecture 200 may 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).

[0084] An AC can be a user application residing on a WTRU that communicates with the EAS. A WTRU can use several ACs simultaneously.

[0085] An EAS can be an application server residing 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 the mobility / relocation use case, the source EAS (S-EAS) is an instance of the EAS that is in the initial location and serves the AC before mobility / relocation occurs. The destination EAS (T-EAS) is an instance of the EAS that is in the destination location and serves the AC after mobility / relocation has occurred. Multiple EAS instances can exist within each EDN. Each EDN can contain different sets of EAS instances of different types (e.g., different EASIDs). An EAS can serve one or more AC instances residing on different WTRUs.

[0086] An EEC can provide edge support to AC instances on a WTRU. Each WTRU can have one or more EECs. Each AC uses only one EEC.

[0087] EES provides the support functionality required by EAS and EEC. In the context of the mobility / relocation use case, the source EES (S-EES) is the EES used before mobility / relocation occurs. The destination EES (T-EES) is the EES used after mobility / relocation has occurred. Each EDN (or each Data Network Name (DNN)) can have one or more EES instances. Multiple EDN instances can exist in a network.

[0088] ECS can provide support functions for EEC or EES to discover EES instances that provide a specific EAS. A network can contain one or more ECS instances.

[0089] The NMC can provide support functionality for the EEC to create a notification channel between the NMC and NMS to receive notifications from the ECS or EES. Each EEC uses only one NMC.

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

[0091] Service continuity procedures for transferring 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 WTRU mobility and / or non-mobility events, such as EAS server maintenance, overload, etc. Service continuity can be used to minimize edge service disruptions to ACs operating on WTRUs.

[0092] Figure 3 This is a flowchart illustrating a high-level overview of Application Context Relocation (ACR) 300. EELs can specify service continuity for applications requiring context relocation in five different ACR scenarios. Each scenario can consist of one or more (e.g., four) distinct phases, including detection, decision, execution, and post-execution. ACR scenarios can specify different EEL entities (e.g., EEC, EES, EAS) for the detection and decision phases (e.g., detection entity and decision-making entity). Different sets of interactions between EEL entities can be defined for the execution phase.

[0093] The detection entity can monitor the location and movement of WTRUs and can notify the decision-making entity. The decision-making entity then determines whether an Application Context (ACR) is required and commands the execution entity to perform the ACR. The execution entity then runs the ACR procedure defined in the service continuity scenario to transfer the application context from the S-EAS to the T-EAS. After the ACR execution is complete, ACR cleanup is performed.

[0094] This document discloses EAS information sharing capabilities and configurations. Sharing EAS information between EES instances within an EDN requires EAS information sharing participants to provide EAS information sharing capabilities. This allows for the determination of the EAS information sharing configuration that should be applied. The EAS information sharing participant is the EES instance.

[0095] EAS information sharing capabilities may include indications that EES can support EAS information sharing, a list of supported sharing methods, indications that EES can be a repository for EAS information, a notification URL for receiving EAS information sharing configuration updates, and the EAS information sharing configuration.

[0096] EAS information sharing configuration may include the selected sharing method, one or more repository addresses (e.g., IP address, URI, FQDN) and endpoints, and a list of EES instances with which to share the registered EAS information.

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

[0098] Figure 4 This is a flowchart illustrating EAS information sharing 400 using an EES repository according to one embodiment. Figure 4 As shown, the EES-1 404 can perform repository functions, such as supporting EAS information sharing.

[0099] At 410, EES-1 404 can send an EES registration request to ECS 402. 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 instructions that it may be an EAS information repository that can be an EDN.

[0100] At position 412, ECS 402 can send an EES registration response to EES-1 404. The EES registration response can include the EAS information sharing configuration to be applied at the EES. ECS 402 can use the EAS information sharing capabilities of the registering and registered EES instances to determine which EAS information sharing configuration to return. ECS 402 can determine that one or more EES repositories are available and can 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 can synchronize data to ensure data consistency within the EDN.

[0101] For example, ECS 402 can determine that EES-1 404 is the only EES in the EDN, and that EES-1 404 supports repository functionality. ECS 402 can select EES-1 404 as the EAS information repository for the EDN and can include EES-1 repository connection information in the EAS information sharing configuration. Alternatively, ECS 402 can determine that multiple EES instances support repository functionality and can select multiple EES instances as EAS information repositories.

[0102] At position 414, EES-2 406 can send an EES registration request to ECS 402. The EES registration request can include EAS information sharing capabilities. For example, EES-2 406 can instruct it to support centralized EAS information sharing.

[0103] At position 416, ECS 402 can send an EES registration response to EES-2 406. The EES registration response can include the EAS information sharing configuration to be applied at EES. ECS 402 can use the EAS information sharing capabilities of the EES instances that are registering and those that have already registered to determine the EAS information sharing configuration.

[0104] For example, ECS 402 can indicate that the repository should be used for EAS information sharing, and can include EES-1 repository connectivity information in the EAS information sharing configuration.

[0105] At 418, EES-2 406 can send an EAS information retrieval request to the supplied EES-1 repository (e.g., EES-1 404) to obtain the latest EAS information. The EAS information retrieval request can be triggered by EES-2 406 receiving EES-1 repository connectivity information.

[0106] Although Figure 4Not shown, but when EES information is updated in the repository, EES-2 406 can subscribe to notifications, for example, from the EES-1 repository (e.g., EES-1 404). The subscription operation can be triggered by EES-2 receiving connectivity information from the EES-1 repository.

[0107] At position 420, the EES-1 repository (e.g., EES-1 404) can send an EAS information retrieval response to EES-2 406. The EAS information retrieval response may include a list of EAS information and the registrar's EES information for each EAS instance.

[0108] For example, if the repository includes EAS information about EAS instances registered to EES-1 404, the EAS information retrieval response may include the EAS profile of the registered EAS instance and the EES profile of EES-1 404.

[0109] At 422, EAS 408 can use EES-2 406 to perform the EAS registration procedure.

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

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

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

[0113] Although Figure 4 Not shown, but an EES-1 repository (e.g., EES-1 404) can notify EES instances subscribed from the same EDN of changes to the EAS information repository.

[0114] In a distributed EAS information sharing configuration, when supported, EES instances deployed within an EDN can share their registered EAS information. Distributed methods can be used to share EES information among EES instances. EES instances obtain a list of EES instances within the same EDN and publish EAS information updates to one or more EES instances from that list.

[0115] Figure 5 This is a flowchart illustrating an example associated with distributed EAS information sharing 500. At 512, EES-1 504 can send an EES registration request to ECS 502. The EES registration request can include EAS information sharing capabilities.

[0116] For example, EES-1 504 can indicate that it supports distributed EAS information sharing and can provide URLs and endpoints to receive EAS information updates.

[0117] At position 514, ECS 502 can send an EES registration response to EES-1 504. The EES registration response can include the EAS information sharing configuration to be applied at EES. ECS 502 can use the EAS information sharing capabilities of the EES instances that are registering and those that have been registered to determine the EAS information sharing configuration to return.

[0118] For example, ECS 502 can determine that distributed EAS information sharing should be used, and EES-1 504 can be added to the list of EES instances that should share EAS information within the EDN.

[0119] At point 516, the EAS (e.g., such as EAS-1 506) can utilize EES-1 504 to perform the EAS registration procedure. EES-1 504 can use the supplied EAS information sharing configuration to determine whether an EAS information update is required.

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

[0121] At point 518, EES-2 508 can send an EES registration request to ECS 502. The EES registration request may include EAS information sharing capabilities.

[0122] For example, EES-2 508 can indicate that it supports distributed EAS information sharing and can provide URLs and endpoints to receive EAS information updates.

[0123] At position 520, ECS 502 can send an EES registration response to EES-2 508. The EES registration response can include the EAS information sharing configuration to be applied at the EES (e.g., EES-2 508). ECS 502 can use the EAS information sharing capabilities of the EES instances that are registering and those that have been registered to determine the EAS information sharing configuration.

[0124] For example, ECS 502 can indicate that distributed EAS information sharing should be used, and EES-2 508 can be added to the list of EES instances that should share EAS information within the EDN.

[0125] Although not in Figure 5 As shown, however, a registered EES can, for example, use the supplied EAS information sharing configuration to determine whether an EAS information update is required.

[0126] For example, EES-2 508 can see EES-1 504 on the list of EES instances with which it wants to share EAS information. However, EES-2 508 may not have any registered EAS instance information to share, and may not need to send EAS information updates.

[0127] At point 522, ECS 502 can send an EAS information sharing configuration update notification to EES-1 504. The EAS information sharing configuration update notification can include the updated EAS information sharing configuration to be applied at EES-1 504.

[0128] For example, ECS 502 can notify EES-1 504: EES-2 508 is now available for EAS information sharing.

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

[0130] At point 526, the EAS (e.g., EAS-2 510) can perform the EAS registration procedure to the EES-2 508. The EES-2 508 can use the supplied EAS information sharing configuration to determine whether an EAS information update is required.

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

[0132] EES-2 508 can send EAS information update notifications to EES-1 504. These notifications can include a list of EAS information for EAS instances registered with EES-2 508.

[0133] One solution addresses the issue that the WTRU cannot discover edge services registered to EES instances other than the one handling the request. This solution also addresses the issue that when the WTRU is allowed to discover edge services registered to other EES instances, it cannot determine which EES instance the discovered EAS instance is registered to. The WTRU may be unable to indicate the selected EAS and ACR scenario to the EES where the selected EAS is registered, potentially causing service continuity failures. This solution enables the WTRU to obtain the registrar EES information required to indicate the EAS and ACR scenario information in the EES where the selected EAS is registered.

[0134] The WTRU can perform the following actions to discover and select edge services within the EDN. The WTRU can send service provisioning requests to the ECS. The WTRU can receive service provisioning responses from the ECS; these responses may include EDN configuration information, which may include a list of EES instances and the EAS information sharing capabilities of the EAS instances; the EAS information sharing capabilities indicate that the EES supports EAS information sharing. The WTRU can select EES instances based on the EES's EAS information sharing capabilities. Under the condition that the EES's EAS information sharing capability indicates that the EES can obtain EAS information from other EES instances within the EDN, the WTRU can send an EAS discovery request to the selected EES; wherein the EAS discovery request may include a list of one or more other EES instances from which it has obtained EAS information, or may include an indication that EAS information can be obtained from other EES instances in the EDN, and may receive an EAS discovery response from the selected EES; wherein the EAS discovery response may include a list of EAS instance information, and may include information about the registrar EES for each discovered EAS instance; wherein the registrar EES is the EES instance where the EAS is registered; wherein the registrar EES information may include a unique EES identifier, an EES profile, and any information specific to the registrar EES instance, and the EAS instance is selected based on the EAS instance information and / or the registrar EES information. When the registrar EES of the selected EAS instance differs from the selected EES instance in the EAS discovery response, the WTRU can use the registrar EES information to obtain a registrar EES profile. This profile can be obtained from a local cache, from the EAS discovery response, or by providing services using an ECS instance. The WTRU can then select one or more ACR scenarios based on the EAS instance information, the registrar EES information, and the profile. The WTRU can send an EAS information provisioning request to the registrar EES, which may include the selected EAS instance and one or more ACR scenarios. The WTRU can receive an EAS information provisioning response from the registrar EES, which may include an indication that the selected EAS instance and ACR scenario have been accepted or rejected. The rejection indication may include EAS instance information and registrar EES information for different EAS instances. The returned EAS instance may be requested by the EES or preferred by the EES. If the EES registrar of the EAS instance returned in the EAS provisioning response is different from the EES instance that sent the EAS provisioning response, the WTRU can send an EAS information provisioning request to the EES registrar of the EAS instance returned in the EAS provisioning response, and can receive an EAS information provisioning response from the registrar EES; wherein the EAS information provisioning response may include an indication that the selected EAS and ACR scenario have been accepted.

[0135] This document discloses one or more techniques associated with edge service discovery and selection using registrar EES information. The WTRU can determine and discover edge services within an EDN without having to query every EES in the EDN. When supported by an EES, the WTRU can 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 within the EDN. The WTRU can use the discovered EAS information and registrar EES information to select an EAS and communicate with the registrar EES of the selected EAS for selecting and provisioning ACR scenarios.

[0136] Figure 6 This is a flowchart illustrating an example of edge service discovery and selection associated with utilizing registrar EES information 600. At 614, an EES instance within the EDN (e.g., EES 608, registrar EES 610) can register with ECS 606. An EAS instance within the EDN (e.g., EAS 612) can register with an EES (e.g., registrar EES 610). EES 608 can receive EAS information from EAS information update notifications sent by other EESs (e.g., registrar EES 610).

[0137] EES registration requests may include the EAS information sharing capabilities of an EES instance. ECS 606 can use EAS information sharing capabilities to determine the EAS information sharing configuration for each EES instance. An EAS (e.g., EAS 612) can register with one of the EES instances (e.g., registrar EES 610). Registrar EES 610 can share the registered EAS information with other EES instances within the same EDN.

[0138] Alternatively, AC 602 can register with EEC 604 at 616 and request edge services.

[0139] At point 618, EEC 604 can send a service provisioning request to ECS 606.

[0140] At position 620, ECS 606 can send a service provisioning response to EEC 604. The service provisioning response can include the EES instance's EAS information sharing capabilities.

[0141] For example, the EAS information capability can notify EEC 604 which EES instances can be used to obtain EAS information from all EES instances within the EDN.

[0142] At point 624, EEC 604 can select EES for edge service discovery. EEC 604 can consider the EES instance's EAS information sharing capabilities when making this selection.

[0143] For example, EEC 604 may preferentially select an EES instance from an EDN that supports EAS information sharing therein.

[0144] At point 626, EEC 604 may send a discovery request (e.g., an EAS discovery request) to a selected EES (e.g., EES 608) to obtain, for example, EAS information and registrar EES information for multiple EES instances. The discovery request may include a list of one or more EES instances from which it requests EAS information, or it may include an indication to request EAS information from multiple (e.g., all) EES instances within the EDN. The discovery request may include an indication to request EAS information from multiple EES instances. EEC 604 may send a discovery request at point 626 provided that the selected EES (e.g., EES 608)'s EAS information sharing capability indicates that the selected EES (e.g., EES 608) can obtain EAS information from other EES instances within the EDN.

[0145] EES 608 can determine the EAS information and registrar EES information of EAS instances registered to other EES instances. For example, EES 608 can determine the EAS information and registrar EES information based on the EAS information sharing configuration associated with EES 608. The EAS information sharing configuration associated with EES 608 may include a selected sharing method, one or more repository addresses, one or more repository endpoints, and / or a list of EES instances with which it shares EAS information. Upon receiving a discovery request (e.g., an EAS discovery request), EES 608 can obtain the EAS information and registrar EES information of the requested EES instance. EES 608 can obtain the EAS information and registrar EES information from a local cache of EAS information sharing results or by sending an EAS information retrieval request to an EES repository. EES 608 can store the EAS information and registrar EES information of EAS instances registered to other EES instances. Registrar EES information may include a unique EES identifier, an EES profile, and / or other information specific to the registrar's EES instance.

[0146] At 628, the selected EES (e.g., EES 608) can send a discovery response (e.g., an EES discovery response) to EEC 604. The discovery response may include a list of EES information (e.g., EES instance information) and may include registrar EES information for one or more EES instances (e.g., when registrar EES 610 is different from the selected EES 608). The discovery response may indicate one or more ACR scenarios supported by one or more EES instances in the EES information list.

[0147] For example, if the EES 608 handling the EAS discovery request does not have the registered EAS instance, but has received EAS instance information from another EES instance, the EES 608 handling the request can provide the EAS profile of the EAS instance and its registrar EES information in the EAS discovery response.

[0148] At 630, EEC 604 can select the EAS instance (e.g., EAS 612) and / or (one or more) ACR scenarios for provisioning. When making a selection, EEC 604 can consider EAS information and registrar EES information from each discovered EAS instance. This information will allow EEC 604 to make a more informed choice within the EDN. For example, at 630, EEC 604 can select an EAS instance based on the EAS information list and / or the registrar information of one or more EAS instances. EEC 604 can select at 630 an EAS instance with a different registrar, EES 610, than the EES instance selected at 624 (e.g., EES 608). At 630, EEC 604 can select one or more ACR scenarios based on one or more of the EAS information list or the registrar EES information of each discovered EAS instance. For example, EEC 604 allows you to select one or more ACR scenarios at 630 based on EAS information, registrar EES information, and / or registrar EES profile.

[0149] For example, using a single EAS discovery procedure, at point 630, EEC 604 can have obtained EAS information for all EAS instances within the EDN, and EEC 604 can compare key performance indicators (KPIs) or service continuity capabilities from all EAS and registrar EES instances, while making a choice between EAS and (one or more) ACR scenarios.

[0150] If the selected EAS instance is registered to EES 608 for edge service discovery, then the selection of the EAS and (one or more) ACR scenarios can proceed using existing procedures. If the selected EAS instance is registered to a different EES, then EEC 604 can use the registrar's EES information to determine where the service provisioning request should be sent.

[0151] Although Figure 6 Not shown, but EEC 604 may need to obtain the registrar EES profile from the service provisioning results cached locally, or EEC 604 may need to run the service provisioning process again. For example, EEC 604 can use registrar EES information to obtain the registrar EES profile. The registrar EES profile can be obtained from the local cache, from the discovery response, or by performing an edge service provisioning process with ECS 606. The edge service provisioning process may include EAS information provisioning as described herein. ACR scenario selection may require a re-evaluation using registrar EES service continuity capabilities. Finally, if registrar EES 610 requires EEC registration, EEC 604 may need to register with the selected registrar EES (e.g., registrar EES 610).

[0152] At 632, EEC 604 can utilize the registrar EES 610 of the selected EAS instance (e.g., EAS 612) to perform one or more edge service provisioning procedures (e.g., EAS information provisioning). For example, EEC 604 can send an EAS information provisioning request to the registrar EES 610 at 632. The EAS information provisioning request can indicate the selected EAS instance (e.g., EAS 612) and one or more ACR scenarios. At 632, if the selected EAS instance (e.g., EAS 612) and / or one or more selected ACR scenarios have been rejected, EEC 604 can receive an EAS information provisioning response indicating registrar EES information. Additionally or alternatively, for example, when the EAS information sharing configuration indicates that EES 608 supports EAS information sharing with a storage repository, EES 608 can send an EAS information request to the storage repository. EES 608 can receive an EAS information response from the storage repository. EAS information responses may include EAS information of other EES instances registered to multiple EES instances, as well as EES registrar information.

[0153] At 634, AC 602 can establish a service session with the selected EAS instance (e.g., EAS 612).

[0154] This document discloses edge service provisioning using registrar EES information. A WTRU may wish to discover edge services within an EDN without having to query every EES in the EDN. When supported by an EES, the WTRU can send a discovery request to one EES in the EDN to obtain EAS information and registrar EES information from one or more EES instances within the EDN. The WTRU can use the discovered EAS 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.

[0155] One solution addresses the issue that EAS information is only available within the EES where the EAS is registered. This solution also addresses the issue that the EES can only provide EAS information to EAS instances registered with it. The EES can perform the following actions to enable the discovery and selection of edge services within an EDN: The EES can send an EES registration request to the ECS; wherein the EES registration request may include EAS information sharing capabilities; wherein the EAS information sharing capabilities may include an indication that the EES supports EAS information sharing, a list of supported sharing methods, a list of EES instances with which to share 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 can receive an EES registration response with EAS information sharing configuration; wherein the EAS information sharing configuration may include the selected sharing method, one or more repository addresses (e.g., IP address, URI, FQDN), and a list of EES instances with which to share the registered EAS information.

[0156] When the EAS information sharing configuration includes a repository, the EES can send an EAS information retrieval request to the repository and receive an EAS information retrieval response from the repository. The EAS information retrieval response may include a list of EAS information and the registrar EES information for each EAS instance. The registrar EES is the EES instance where the EAS is registered. The registrar EES information may include a unique EES identifier, an EES profile, and any information specific to the registrar EES instance.

[0157] When performing EAS registration with EES, EES can send an EAS information update request to the storage repository; wherein the EAS information update request may include a list of EAS information of EAS instances registered with EES; and receive an EAS information update response from the storage repository; wherein the EAS information update response may include the list of EAS information and the registrar EES information for each EAS instance.

[0158] Under the condition that the EAS information sharing configuration provides a list of EES instances with which it shares EAS information, and under the condition that it receives an EAS information sharing configuration update notification with an updated list of EES instances with which it shares EAS information, or under the condition that it performs EAS registration with the EES, the EES may send an EAS information update notification to one or more of the EES instances; wherein the EAS information notification may include an EAS information list and registrar EES information; wherein the registrar EES is the EES instance with which the EAS is registered; wherein the registrar EES information may include a unique EES identifier, an EES profile, and any information specific to the registrar EES instance.

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

[0160] Figure 7This is a flowchart illustrating an example associated with an edge service provisioning 700 utilizing registrar EES information. At 716, one or more EES instances within the EDN (e.g., such as EES-1 708 and EES-2 712) can register with ECS 706. An EES registration request may include EAS information sharing capabilities for one or more EES instances (e.g., such as EES-1 708 and EES-2 712). ECS 706 can use these EAS information sharing capabilities to determine the EAS information sharing configuration for each EES instance. One or more EAS instances (e.g., such as EAS-1 710 and EAS-2 714) can register with EES instances (e.g., such as EES-1 708 and EES-2 712) and trigger EAS information sharing between EES instances (e.g., such as EES-1 708 and EES-2 712) within the EDN.

[0161] Alternatively, AC 702 can register with EEC 704 at 718 and request edge services. EEC 704 can use a service provider to obtain EDN configuration information and EES information. EEC 704 can select an EES and use the selected EES to discover EAS instances.

[0162] At 720, EEC 704 can select EAS and / or (one or more) ACR scenarios.

[0163] At 722, EEC 704 can send an EAS information provision request to the selected EES (e.g., EES-1 708).

[0164] At point 724, EES 708 can send an EAS information provision response to EEC 704. The EAS information provision response may include EAS instance information for different (e.g., preferred or required) EAS instances and registrar EES information. If the selected EAS instance is registered to a different EES, then EEC 704 can use the registrar EES information to determine where the EAS information provision request should be sent.

[0165] At point 726, EEC 704 can reselect an ACR scenario based on the service continuity capabilities of the registrar EES. EEC 704 can obtain the registrar EES profile from locally cached service provisioning results, or EEC 704 can rerun the service provisioning process. The ACR scenario selection can be re-evaluated using the registrar EES service continuity capabilities. If the registrar EES requires EEC registration, EEC 704 may need to register with the selected registrar EES.

[0166] At 728, EEC 704 can perform edge service provisioning (such as EES information provisioning) with the registrar EES (e.g., EES-2 712) of the selected EAS instance (e.g., EAS-2 714).

[0167] At 730, AC 702 can establish a service session with the selected EAS instance (e.g., EAS-2 714).

[0168] This document discloses edge service discovery using anchored EES. A WTRU may wish to discover edge services within an EDN without having to query every EES in the EDN. When backed by an EES, the WTRU can select one EES to act as the anchor EES. The WTRU can communicate with the anchor EES to obtain EAS information from other EES instances within the EDN.

[0169] Figure 8 This is a flowchart illustrating an example associated with Edge Service Discovery 800 using Anchored EES. At 814, the EES (e.g., Anchored EES 808) may send an EES registration request to ECS 806. The EES registration request may include Anchored EES capabilities. Anchored EES capabilities may include indications that the EES (e.g., Anchored EES 808) supports Anchored EES functionality.

[0170] At 816, ECS 806 can send an EES registration response to EES (e.g., anchored to EES 808).

[0171] At point 818, EAS 812 can be registered to one of the EES instances (e.g., registrar EES 810). Registrar EES 810 can share the registered EAS information with other EES instances within the same EDN.

[0172] At 820, AC 802 can register with EEC 804 and can request edge services.

[0173] At point 822, EEC 804 can send a service provisioning request to ECS 806.

[0174] At position 824, ECS 806 can send a service provisioning response to EEC 804. The service provisioning response can include the EES instance's anchoring capabilities to EES.

[0175] For example, the anchored EES capability can notify EEC 804 which EES instances can be used as anchored EES within the EDN.

[0176] At point 826, EEC 804 can select the EES used for edge service discovery. EEC 804 can consider the anchoring capabilities of the EES instance when making this selection.

[0177] For example, EEC 804 can select an EES instance that supports anchored EES functionality.

[0178] At 828, EEC 804 can send an EEC registration request to a selected EES (e.g., anchored EES 808). The EEC registration request may include an indication that the EES (e.g., anchored EES 808) has been selected as the anchored EES for requesting EEC 804.

[0179] At 830, the selected EES (e.g., anchored EES 808) can send an EEC registration response to EEC 804. The EEC registration response may include an indication that the EES (e.g., anchored EES 808) has accepted the anchored EES as a means of requesting EEC 804. Anchored EES 808 can create and maintain EEC context and EAS mappings to properly handle future requests from EEC 804.

[0180] At 832, EEC 804 may send an EAS discovery request to anchored EES 808. The EAS discovery request may include an indication that an EES (e.g., anchored EES 808) has been selected as the anchored EES for requesting EEC 804. This indication may be omitted if EEC 804 has already provided during EEC registration that an EES (e.g., anchored EES 808) has been selected as the anchored EES.

[0181] At position 834, anchoring EES 808 can send an EAS discovery response to EEC 804. The EAS discovery response can include a list of EAS instance information obtained from all EES instances in the EDN.

[0182] For example, anchoring an EES (e.g., anchoring an EES 808) can return the discovered EAS instances obtained from EAS information sharing.

[0183] One solution addresses the issue where EES could only provide EAS information to EAS instances registered to the EES. This solution also addresses the problem that when EES is allowed to provide EAS information to EAS instances registered to other EES instances, WTRU could provision selected EAS and ACR in EES instances where the selected EAS is not registered, potentially leading to service continuity failures. This solution enables EES to correctly handle service continuity provisioning for EAS instances registered to other EES instances.

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

[0185] EES can receive EEC registration requests from WTRU; where the EEC registration request may include an indication that EES has been selected as the anchor EES.

[0186] The EES can send an EEC registration response to the WTRU; the EEC registration response may include an indication that the EES accepts to become an anchored EES of the WTRU.

[0187] EES can receive EAS discovery requests from WTRU; where the EAS discovery request may include an indication that EES has been selected as the anchor EES.

[0188] EES can send an EAS discovery response to WTRU; the EAS discovery response may include an indication that EES accepts to become an anchored EES of WTRU, and may include a list of EAS information obtained from one or more EES instances within EDN.

[0189] Under the condition that the anchored EES receives an EAS information provisioning request from the WTRU, and that the selected EAS provided in the EAS information provisioning request is registered to another EES instance, the anchored EES can send an EAS agent setup request to the registrar EES; wherein the registrar EES is the EES instance where the EAS is registered; wherein the EAS agent setup request can include EAS agent configuration information; wherein the EAS agent configuration information can include the selected EAS profile, and the anchored EES address (e.g., IP address, URI, FQDN) and endpoint can receive an EAS agent setup response from the registrar EES; wherein the EAS agent setup response can include an indication that the EAS agent has been successfully established and configured, and can send an EAS agent request to the EAS agent in the registrar EES; wherein the EAS agent request can include a message to be sent to the selected EAS; wherein the message can be an ACR management event notification of type "ACR Selection".

[0190] This document discloses edge service selection and provisioning using anchored EES. After discovering edge services within the EDN, WTRU can select an EAS and can use anchored EES to select and provide ACR scenarios. Anchored EES can determine that the selected EAS is registered to a different EES and can use the registrar EES as a proxy to communicate with the selected EAS.

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

[0192] Alternatively, AC 902 can register with EEC 904 at 916 and request edge services. EEC 904 can use a service provider to obtain EDN configuration information and EES information. EEC 904 can optionally anchor to EES 908 and can use anchoring to EES 908 to discover EAS instances.

[0193] Alternatively, EEC 904 may select the EAS instance and / or (one or more) ACR scenarios for provisioning at point 918. EEC 904 may consider anchoring the service continuity capabilities of EES 908 when selecting (one or more) ACR scenarios.

[0194] At 920, EEC 904 can send an EAS information supply request to the anchored EES 908.

[0195] Anchor EES 908 can use EAS information and registrar EES information obtained from EAS information sharing to verify whether the selected EAS (e.g., EAS 912) is registered to another EES instance. If the selected EAS instance is registered to a different EES instance, then at 922, Anchor EES 908 can send an EAS proxy setup request to the registrar EES 910 of the selected EAS to establish and configure the 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 the endpoint used to handle requests proxied from EAS 912.

[0196] For example, registrar EES 910 may have already published EAS information for EAS instances registered to registrar EES 910 to the EES repository. Anchor EES 908 may have already obtained the EAS information and registrar EES information from the EES repository. Anchor EES 908 can use this information to determine that a selected EAS (e.g., EAS 912) is not registered to anchor EES 908 and trigger the establishment of an EAS proxy at registrar EES 910.

[0197] At point 924, the registrar EES 910 can send an EAS agent setup response to the anchored EES 908. The EAS agent setup response indicates whether the EAS agent has been successfully established and configured.

[0198] At 926, anchoring EES 908 can send an EAS proxy request to the EAS agent in the registrar's EES 910. The EAS proxy request can include a message to be sent to a selected EAS (e.g., EAS 912).

[0199] For example, during EAS and ACR scenario information provisioning, anchoring EES 908 can instruct "ACR Selection" ACR management event notifications to be sent to the selected EAS (e.g., EAS 912).

[0200] The EAS agent in the registrar EES 910 can send the requested message to EAS 912.

[0201] For example, an EAS agent in registrar EES 910 can send an ACR management event notification at 928 to the selected EAS (e.g., EAS 912) to provide ACR selection information to EAS 912.

[0202] The EAS agent in the registrar's EES 910 can send an EAS agent response to the anchored EES 908 at point 930. The EAS agent response can indicate whether the request has been successfully processed by the EAS agent.

[0203] At 932, anchoring EES 908 can send an EAS information provision response to EEC 904. The EAS information provision response may include the selected EAS (e.g., EAS 912) and an indication that (one or more) ACR scenarios have been accepted.

[0204] At 934, AC 902 can establish a service session with the selected EAS instance (e.g., EAS 912).

[0205] The following abbreviations and acronyms are already included.

[0206] 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 Enabler Client (EEC); Edge Enablement Layer (EEL); Edge Enabler Server (EES); Fully Qualified Domain Name (FQDN); Key performance indicators (KPIs); Notification Management Client (NMC); Notification Management Server (NMS); Quality of Service (QoS); Source Edge Application Server (S-EAS); Source Edge Enabler Server (S-EES); Technical Specification (TS); Target Edge Application Server (T-EAS); Target Edge Enabler Server (T-EES); and Uniform Resource Identifier (URI).

Claims

1. A wireless transmit / receive unit (WTRU), comprising: The processor is configured as follows: Send a discovery request to the first Edge Enabler Server (EES) instance to obtain Edge Application Server (EAS) information; Receive a discovery response from the first EES instance; wherein the discovery response indicates an EAS information list and registrar EES information for one or more EAS instances in the EAS information list; and The EAS instance is selected based on one or more of the EAS information list or the registrar EES information of one or more EAS instances, wherein the selected EAS instance is registered to a second EES instance that is different from the first EES instance.

2. The WTRU of claim 1, wherein the processor is further configured to send an EAS information provisioning request to a second EES instance, wherein the EAS information provisioning request indicates a selected EAS instance and one or more selected application context relocation (ACR) scenarios.

3. The WTRU according to claim 1 or 2, wherein the processor is further configured to select a first EES instance from a plurality of EES instances based on the EAS information sharing capability of the first EES instance.

4. The WTRU according to any one of claims 1-3, wherein the discovery request includes an indication to request EAS information from multiple EES instances.

5. The WTRU according to any one of claims 1-4, wherein the discovery request is sent provided that the EAS information sharing capability of the first EES instance indicates that the first EES instance can obtain EAS information from other EES instances within the Edge Data Network (EDN).

6. The WTRU according to any one of claims 1-5, wherein the discovery request indicates a list of one or more other EES instances from which EAS information is to be obtained.

7. The WTRU according to any one of claims 1-6, wherein the processor is further configured to receive an EAS information supply response indicating registrar EES information under the condition that one or more of the selected EAS instance or one or more selected ACR scenarios have been rejected.

8. The WTRU according to any one of claims 1-7, wherein the processor is further configured to select one or more ACR scenarios based on one or more of the EAS information list or the registrar EES information of each discovered EAS instance.

9. The WTRU of claim 8, wherein the processor is further configured to use registrar EES information to obtain a registrar EES profile; wherein the registrar EES profile is obtained from a local cache, from a discovery response, or by executing a service provisioning process using an edge configuration server (ECS).

10. The WTRU of claim 9, wherein the processor is further configured to select one or more selected ACR scenarios based on EAS information and registrar EES information and profiles.

11. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Send a discovery request to the first Edge Enabler Server (EES) instance to obtain Edge Application Server (EAS) information; Receive a discovery response from the first EES instance; wherein the discovery response indicates an EAS information list and registrar EES information for one or more EAS instances in the EAS information list; and The EAS instance is selected based on one or more of the EAS information list or the registrar EES information of one or more EAS instances, wherein the selected EAS instance is registered to a second EES instance that is different from the first EES instance.

12. The method of claim 11, further comprising sending an EAS information provisioning request to a second EES instance, wherein the EAS information provisioning request indicates a selected EAS instance and one or more selected application context relocation (ACR) scenarios.

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

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

15. The method according to any one of claims 11-14, wherein the discovery request is sent provided that the EAS information sharing capability of the first EES instance indicates that the first EES instance can obtain EAS information from other EES instances within the Edge Data Network (EDN).

16. The method of any one of claims 11-15, wherein the discovery request indicates a list of one or more other EES instances from which EAS information is to be obtained.

17. The method according to any one of claims 11-16, further comprising sending an EAS information supply response instructing the registrar EES information under the condition that one or more of the selected EAS instance or one or more selected ACR scenarios have been rejected.

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

19. The method of claim 18, further comprising using registrar EES information to obtain a registrar EES profile; wherein the registrar EES profile is obtained from a local cache, from a discovery response, or by performing a service provisioning process using an edge configuration server (ECS).

20. The method of claim 19, further comprising selecting one or more selected ACR scenarios based on EAS information and registrar EES information and profiles.

Images