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

To provide one or more techniques associated with the use of non-registrar EES for EAS discovery operations.SOLUTION: 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 an EAS instance based on one or more of the list of EAS information or the registrar EES information for the one or more EAS instances. A second EES instance of the plurality of EES instances may be the registrar EES of the selected EAS instance.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 466,372, filed May 15, 2023, the entire contents of which are incorporated herein by reference in their entirety. [Background technology]

[0002] A cellular communication system edge-enabled service layer may 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., a registrar EES). Discovery of a common EAS for a group of Application Clients (ACs) may require discovery of the EAS (e.g., by communicating with an EES that is not the EAS's registrar EES). Thus, a cellular communication system may be configured to support EAS discovery using an EES other than, for example, a registrar EES.

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

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

[0005] In a second instance, certain edge service discovery procedures may provide EAS information about discovered EAS instances registered with the EES processing the request. For example, if the EES can return EAS information from an EAS registered with another EES instance, the WTRU may not be able to determine the EES with which the EAS is registered and may not be able to indicate EAS and Application Context Relocation (ACR) scenario selection in the registrar EES. A service continuity procedure failure may occur. Therefore, an edge-enabled service layer of a cellular communication system may be used to enable the WTRU to obtain the registrar EES information needed to correctly indicate the EAS and ACR scenario selection in the EES in which the selected EAS is registered. Additionally or alternatively, the edge-enabled service layer of a cellular communication system may be used to enable the EES to correctly handle service continuity for an EAS registered in another EES. Summary of the Invention

[0006] 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 an EAS instance based on one or more of the list of EAS information or the registrar EES information for the one or more EAS instances, and a second EES instance of the multiple EES instances may be the registrar EES of the selected EAS instance.

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

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

[0009] [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an example wireless transmit receive unit (WTRU) that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 1C] 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 2] FIG. 1 is a system diagram illustrating an example SA6 architecture for enabling edge applications. [Figure 3] 1 is a flow diagram illustrating a high-level overview of application context relocation (ACR). [Figure 4]1 is a flow diagram illustrating edge application server (EAS) information sharing using an edge enabler server (EES) repository. [Figure 5] 1 is a flow diagram illustrating an embodiment associated with distributed EAS information sharing. [Figure 6] 10 is a flow diagram illustrating an embodiment associated with edge service discovery and selection using registrar EES information. [Figure 7] 10 is a flow diagram illustrating an embodiment associated with edge service provisioning using registrar EES information. [Figure 8] 10 is a flow diagram illustrating an embodiment associated with edge service discovery using an anchor EES. [Figure 9] 1 is a flow diagram illustrating an embodiment associated with edge service selection and provisioning using an anchor EES. DETAILED DESCRIPTION OF THE INVENTION

[0010] 1A is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. Communication system 100 may enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

[0011] 1A, communications system 100 may include wireless transmit receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. As examples, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a "station" and / or "STA," may be configured to transmit and / or receive wireless signals and may include user equipment (WTRUs), mobile stations, fixed or mobile subscriber units, subscription-based units, paging, mobile 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, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., for remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain contexts), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a WTRU.

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

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

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

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

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

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

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

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

[0020] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 through the CN 106 / 115.

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

[0022] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP Internet protocol suite. The network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may use the same RAT as the RAN 104 / 113 or a different RAT.

[0023] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links.) For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a, which may employ a cellular-based wireless technology, and a base station 114b, which may employ an IEEE 802.2 wireless technology.

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

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

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

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

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

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

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

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

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

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

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

[0035] The RAN 104 may include eNodeBs 160a, 160b, and 160c, although it will be understood that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In an embodiment, the eNodeBs 160a, 160b, and 160c may implement MIMO technology. Thus, the eNodeB 160a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

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

[0037] 1C 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 illustrated as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0038] The MME 162 may be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

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

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

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

[0042] Although the WTRU is depicted in FIGS. 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments, such a terminal may use a wired communication interface (e.g., temporary or permanent) with the communication network.

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

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

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

[0046] High Throughput (HT) STAs may use 40 MHz wide channels for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

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

[0048] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah may support meter-type control / machine-type communications, such as MTC devices within macro coverage areas. MTC devices may have limited capabilities, including support for (e.g., only for) certain specific and / or limited bandwidths. MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0049] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be configured and / or limited by the STAs among all STAs operating in the BSS that support the minimum bandwidth operating mode. In an 802.11ah embodiment, the primary channel can be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) configuration can depend on the status of the primary channel. For example, if the primary channel is busy due to a STA (that only supports 1 MHz mode of operation) transmitting to the AP, the entire available frequency band may be considered busy even though most of the frequency band may remain inactive and available for use.

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

[0051] 1D is a system diagram illustrating the RAN 113 and the CN 115, according to one embodiment. As noted above, the RAN 113 may use NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also communicate with the CN 115.

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

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

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

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

[0056] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements is illustrated 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 the CN operator.

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

[0058] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 115 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 115 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions, such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0059] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks such as the Internet 110 to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policy, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

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

[0061] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-ab, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

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

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

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

[0065] Common terms applicable to the disclosed embodiments are defined: Registrar EES may refer to an EES instance where an EAS instance is registered.

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

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

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

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

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

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

[0072] 2 is a system diagram illustrating an example SA6 architecture 200 for enabling edge applications. As shown in FIG. 2, 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).

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

[0074] An EAS can be an application server residing in an Edge Data Network (EDN). Typically, it can be a software server running on commodity hardware located at the edge and serving the AC. In the context of the mobility / relocation use case, the Source-EAS (S-EAS) is the instance of the EAS at the initial location, serving the AC before mobility / relocation occurs. The Target-EAS (T-EAS) is an instance of an EAS at a destination location that serves an AC after mobility / relocation occurs. There may be multiple EAS instances per EDN. Each EDN may contain a different set of EAS instances of different types (e.g., different EASIDs). An EAS may serve one or more AC instances that may reside on different WTRUs.

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

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

[0077] An ECS may provide support for discovering the EES instance that an EEC or EES provides for a particular EAS. There may be one or more ECSs for a network.

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

[0079] The NMS may provide support functions for the ECS or EES to send notifications to the EEC via a notification channel created between the NMC and the NMS. There may be one or more NMSs for a network.

[0080] Service continuity procedures for transferring application context from the S-EAS to the T-EAS may be defined in the Edge Enablement Layer (EEL). For example, context transfer may be triggered by a WTRU movement and / or a non-mobility event, such as EAS server maintenance, overload, etc. Service continuity may be used to minimize edge service interruptions to the AC running on the WTRU.

[0081] Figure 3 is a flow diagram 300 illustrating a high-level overview of Application Context Relocation (ACR). Service continuity for applications requiring context relocation can be specified by the EEL in five different Application Context Relocation (ACR) scenarios. Each scenario can consist of one or more (e.g., four) different phases, including detection, decision, execution, and post-execution. An ACR scenario can specify different EEL entities (e.g., EEC, EES, EAS) for the detection and decision phases (e.g., detection entity and decision-making entity). A different set of interactions between the EEL entities can be defined for the execution phase.

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

[0083] EAS information sharing capabilities and configurations are disclosed herein. Sharing EAS information between EES instances in an EDN requires that an EAS information sharing participant provide an EAS information sharing capability, which may allow for the determination of the EAS information sharing configuration to be applied. An EAS information sharing participant is an EES.

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

[0085] The EAS information sharing configuration may include a selected sharing method, one or more repository addresses (eg, IP addresses, URIs, FQDNs) and endpoints, and a list of registered EAS information sharing EES instances.

[0086] In a centralized EAS information sharing configuration, when supported, EES instances deployed in an EDN may share registered EAS information. A centralized approach may be used to share EAS information between EES instances. A repository function may be added to one or more EESs so that during EES registration, a registrar EES instance may receive information about an EES repository to use to share EAS information. An EES instance may publish EAS information to an EES repository and retrieve updated EAS information from an EES repository. When multiple EES repositories are configured in an EDN, they may synchronize data to provide consistent EAS information.

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

[0088] At 410, EES-1 404 may 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 an indication that it can be an EAS information repository for the EDN.

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

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

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

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

[0093] For example, ECS 402 may indicate that the repository is to be used for EAS information sharing and may include EES-1 repository connectivity information in the EAS information sharing configuration.

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

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

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

[0097] For example, if the repository contains EAS information about an EAS instance registered with EES-1 404, the EAS information search response may include the EAS profile of the registered EAS instance and the EAS profile of EES-1 404.

[0098] At 422, the EAS 408 may perform an EAS registration procedure with the EES-2 406.

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

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

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

[0102] Although not shown in FIG. 4, an EES-1 repository (eg, EES-1 404) may notify subscribed EES instances from the same EDN about changes to the EAS information repository.

[0103] In a distributed EAS information sharing configuration, when supported, EES instances deployed within an EDN may share registered EAS information. A distributed approach may be used to share EAS information between EES instances. An EES instance obtains a list of EESs within the same EDN and publishes EAS information updates to one or more EESs from this list.

[0104] 5 is a flow diagram 500 illustrating an embodiment associated with distributed EAS information sharing. At 512, EES-1 504 may send an EES registration request to ECS 502. The EES registration request may include EAS information sharing capabilities.

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

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

[0107] For example, ECS 502 may determine that distributed EAS information sharing should be used and may add EES-1 504 to the list of EES instances in the EDN that should share EAS information.

[0108] At 516, an EAS (such as EAS-1 506) may perform an EAS registration procedure with EES-1 504. EES-1 504 may use the provisioned EAS information sharing configuration to determine whether an EAS information update is required.

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

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

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

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

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

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

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

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

[0117] For example, ECS 502 may notify EES-1 504 that EES-2 508 is now available for EAS information sharing.

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

[0119] At 526, the EAS (e.g., EAS-2 510) may perform an EAS registration procedure with EES-2 508. EES-2 508 may use the provisioned EAS information sharing configuration to determine if an EAS information update is required.

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

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

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

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

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

[0125] 6 is a flow diagram 600 illustrating an embodiment associated with edge service discovery and selection using registrar EES information. At 614, an EES instance in the EDN (e.g., EES 608, registrar EES 610) may register with ECS 606. An EAS instance in the EDN (e.g., EAS 612) may register with an EES (e.g., registrar EES 610). EES 608 may receive EAS information from an EAS information update notification sent by another EES (e.g., registrar EES 610).

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

[0127] Additionally or alternatively, the AC 602 may register with the EEC 604 and request edge services, at 616 .

[0128] At 618, the EEC 604 may send a service provisioning request to the ECS 606.

[0129] At 620, the ECS 606 may send a service provisioning response to the EEC 604. The service provisioning response may include the EAS information sharing capabilities of the EES instance.

[0130] For example, the EAS information capability may inform the EEC 604 about which EES instances can be used to obtain EAS information from all EES instances in the EDN.

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

[0132] For example, the EEC 604 may prefer to select an EES instance from an EDN in which EAS information sharing is supported.

[0133] At 626, the EEC 604 may send a discovery request (e.g., an EAS discovery request) to a selected EES (e.g., the 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 for which EAS information is requested, or may include an indication that EAS information is requested from multiple (e.g., all) EES instances in the EDN. The discovery request may include an indication that EAS information is being requested from multiple EES instances. The EEC 604 may send 626 the discovery request on the condition that the EAS information sharing capabilities of the selected EES (e.g., EES 608) indicate that the selected EES (e.g., EES 608) is capable of obtaining EAS information from other EES instances in the EDN.

[0134] The EES 608 may determine EAS information and registrar EES information for EAS instances registered with other EES instances. For example, the EES 608 may determine the EAS information and registrar EES information based on an EAS information sharing configuration associated with the EES 608. The EAS information sharing configuration associated with the 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 to share the EAS information. Upon receiving a discovery request (e.g., an EAS discovery request), the EES 608 may obtain the EAS information and registrar EES information for the requested EES instance. The EES 608 may obtain the EAS information and registrar EES information from a local cache of EAS information sharing results or by sending an EAS information search request to an EES repository. The EES 608 may store the EAS information and registrar EES information for EAS instances registered with other EES instances. The registrar EES information may include a unique EES identifier, an EES profile, and / or other information specific to the registrar EES instance.

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

[0136] For example, if the EES608 processing the EAS discovery request does not have a registered EAS instance but has received EAS instance information from another EES instance, the EES608 processing the request may provide the EAS profile of the EAS instance, as well as its registrar EES information, in the EAS discovery response.

[0137] At 630, the EEC 604 may select an EAS instance (e.g., EAS 612) and / or an ACR scenario for provisioning. The EEC 604 may consider EAS information and registrar EES information from each discovered EAS while making the selection. This information enables the EEC 604 to make a more informed selection within the EDN. For example, at 630, the EEC 604 may select an EAS instance based on the list of EAS information and / or registrar information for one or more EAS instances. The EEC 604 may select an EAS instance at 630 that has a registrar EES 610 that is different from the EES instance selected at 624 (e.g., EES 608). The EEC 604 may select one or more ACR scenarios at 630 based on one or more of the list of EAS information or the registrar EES information for each discovered EAS instance. For example, the EEC 604 may select 630 one or more ACR scenarios according to the EAS information, the registrar EES information, and / or the registrar EES profile.

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

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

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

[0141] At 632, the EEC 604 may perform one or more edge service provisioning procedures (e.g., EAS information provisioning, etc.) with the registrar EES 610 of the selected EAS instance (e.g., EAS 612). For example, the EEC 604 may send an EAS information provisioning request to the registrar EES 610 at 632. The EAS information provisioning request may indicate the selected EAS instance (e.g., EAS 612) and one or more ACR scenarios. The EEC 604 may receive an EAS information provisioning response at 632 indicating the registrar EES information, with the condition that the selected EAS instance (e.g., EAS 612) and / or one or more selected ACR scenarios are denied. Additionally or alternatively, the EES 608 may send the EAS information request to the repository, for example, when the EAS information sharing configuration indicates that the EES 608 supports EAS information sharing with the repository. The EES 608 may receive the EAS information response from the repository. The EAS information response may include EAS information and registrar EES information about EAS instances registered with other EES instances among the multiple EES instances.

[0142] At 634, the AC 602 may establish a service session with the selected EAS instance (eg, the EAS 612).

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

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

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

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

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

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

[0149] 7 is a flow diagram 700 illustrating an embodiment associated with edge service provisioning using registrar EES information. At 716, one or more EES instances (e.g., EES-1 708 and EES-2 712, etc.) in the EDN may register with the ECS 706. The EES registration request may include the EAS information sharing capabilities of the EES instances (e.g., EES-1 708 and EES-2 712, etc.). The ECS 706 may use the EAS information sharing capabilities to determine the EAS information sharing configuration for each EES instance. One or more EAS instances (e.g., EAS-1 710 and EAS-2 714, etc.) may register with the EES instances (e.g., EES-1 708 and EES-2 712, etc.), which may trigger EAS information sharing between the EES instances (e.g., EES-1 708 and EES-2 712, etc.) in the EDN.

[0150] Additionally or alternatively, the AC 702 may register with the EEC 704 and request edge services at 718. The EEC 704 may obtain EDN configuration information and EES information using a service provisioning procedure. The EEC 704 may select an EES and use the selected EES to discover an EAS instance.

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

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

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

[0154] At 726, the EEC 704 may reselect an ACR scenario according to the service continuity capabilities of the registrar EES. The EEC 704 may obtain a registrar EES profile from a locally cached service provisioning result, or the EEC 704 may perform the service provisioning procedure again. The ACR scenario selection may be reevaluated using the registrar EES service continuity capabilities. The EEC 704 may need to register with the selected registrar EES if the registrar EES requires EEC registration.

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

[0156] At 730, the AC 702 may establish a service session with the selected EAS instance (eg, EAS-2 714).

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

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

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

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

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

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

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

[0164] For example, the anchor EES capabilities may inform the EEC 804 about which EES instances can be used as anchor EESs within the EDN.

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

[0166] For example, the EEC 804 may select an EES instance that supports anchor EES functionality.

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

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

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

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

[0171] For example, an anchor EES (e.g., anchor EES 808) may return discovered EAS instances obtained from an EAS information share.

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

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

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

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

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

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

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

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

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

[0181] Additionally or alternatively, the AC 902 may register with the EEC 904 and request edge services at 916. The EEC 904 may obtain EDN configuration information and EES information using service provisioning procedures. The EEC 904 may select an anchor EES 908 and use the anchor EES 908 to discover an EAS instance.

[0182] Additionally or alternatively, the EEC 904 may select an EAS instance and / or an ACR scenario for provisioning, at 918. The EEC 904 may consider the service continuity capabilities of the anchor EES 908 while selecting the ACR scenario.

[0183] At 920, the EEC 904 may send an EAS information provisioning request to the anchor EES 908.

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

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

[0186] At 924, the registrar EES 910 may send an EAS proxy setup response to the anchor EES 908. The EAS proxy setup response may indicate whether the EAS proxy was successfully established and configured.

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

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

[0189] The EAS proxy in the registrar EES 910 may send the requested message to the EAS 912 .

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

[0191] The EAS proxy in the registrar EES 910 may send 930 an EAS proxy response to the anchor EES 908. The EAS proxy response may indicate whether the request was successfully processed by the EAS proxy.

[0192] The anchor EES 908 may send an EAS information provisioning response to the EEC 904 at 932. The EAS information provisioning response may include the selected EAS (e.g., EAS 912) and an indication that the ACR scenario is accepted.

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

[0194] The following abbreviations and acronyms are included: Application Client (AC), Application Context Relocation (ACR), Data Network (DN), Data Network Name (DNN), Edge Application Server (EAS), Edge Configuration Server (ECS), Edge Data Network (EDN), Edge 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 Universal Resource Identifier (URI).

Claims

1. 1. A wireless transmit receive unit (WTRU), comprising: Sending a discovery request to a first Edge Enabler Server (EES) to obtain Edge Application Server (EAS) information; receiving a discovery response from the first EES, the discovery response including a list of discovered EASs, the list including EAS information for each of the discovered EASs, the EAS information of the discovered EASs including registrar EES information based on which the discovered EAS is registered with a second EES, and the EAS information of the discovered EASs further including an EAS profile on condition that the discovered EAS is instantiated; selecting an EAS from the list of discovered EASs; 1. A WTRU comprising: a processor configured to execute:

2. The processor:

10. The WTRU of claim 1, further configured to: transmit an EAS information provisioning request, the EAS information provisioning request indicating the selected EAS and one or more Application Context Relocation (ACR) scenarios.

3. The processor: The WTRU of claim 2 , further configured to receive an EAS information provisioning response from the second EAS.

4. The WTRU of claim 1 , wherein the discovery response indicates ACR scenarios supported by one or more EASs in the list of EAS information.

5. The WTRU of claim 1 , wherein the discovery request includes an indication that EAS information is being requested from multiple EESs.

6. The WTRU of claim 1 , wherein the selected EAS is selected based on the EAS information.

7. The WTRU of claim 1 , wherein the selected EAS is registered with a third EES that is different from the first EES.

8. 2. The WTRU of claim 1, wherein the discovery request is transmitted on the condition that the EAS information sharing capability of the first EES indicates that the first EES can obtain EAS information from other EESs in an edge data network (EDN).

9. The processor:

10. The WTRU of claim 1, further configured to: perform selecting one or more ACR scenarios based on one or more of the list of EAS information and registrar EAS information for each discovered EAS.

10. The processor: obtaining a registrar EES profile using the registrar EES information, wherein the registrar EES profile is obtained from a local cache, from the discovery response, or by performing a service provisioning procedure at an Edge Configuration Server (ECS), and the one or more selected ACR scenarios are selected according to the EAS information and the registrar EES information and profile; The WTRU of claim 9 further configured to perform:

11. 1. A method performed by a wireless transmit receive unit (WTRU), comprising: Sending a discovery request to a first Edge Enabler Server (EES) to obtain Edge Application Server (EAS) information; receiving a discovery response from the first EES, the discovery response including a list of discovered EASs, the list including EAS information for each of the discovered EASs, the EAS information of the discovered EASs including registrar EES information based on which the discovered EAS is registered with a second EES, and the EAS information of the discovered EASs further including an EAS profile on condition that the discovered EAS is instantiated; selecting an EAS from the list of discovered EASs; A method comprising:

12. 12. The method of claim 11, further comprising: sending an EAS information provisioning request, the EAS information provisioning request indicating the selected EAS and one or more Application Context Relocation (ACR) scenarios.

13. The method of claim 12 , further comprising receiving an EAS information provisioning response from the second EES.

14. The method of claim 11 , wherein the discovery response indicates ACR scenarios supported by one or more EASs in the list of EAS information.

15. The method of claim 11 , wherein the discovery request includes an indication that EAS information is being requested from multiple EESs.

16. The method of claim 11 , wherein the selected EAS is selected based on the EAS information.

17. The method of claim 11 , wherein the selected EAS is registered with a third EES that is different from the first EES.

18. 12. The method of claim 11, wherein the discovery request is sent on the condition that the EAS information sharing capability of the first EES indicates that the first EES can obtain EAS information from other EESs within an edge data network (EDN).

19. 12. The method of claim 11, further comprising selecting one or more ACR scenarios based on one or more of the list of EAS information and registrar EAS information for each discovered EAS.

20. obtaining a registrar EES profile using the registrar EES information, wherein the registrar EES profile is obtained from a local cache, from the discovery response, or by performing a service provisioning procedure at an Edge Configuration Server (ECS), and the one or more selected ACR scenarios are selected according to the EAS information and the registrar EES information and profile; 20. The method of claim 19, further comprising:

Images