Detecting and executing application context relocation using ACI

Abstract

A Wireless Transceiver Unit (WTRU) may be configured to perform edge application server (EAS) discovery procedures for a user session. Based on the EAS discovery procedures, the WTRU may be configured to determine that there are no available target EAS (T-EAS) instances for the user session. The WTRU may be configured to determine whether the user session supports ACR to a cloud application server (CAS) using Application Context Relocation (ACR) configuration information (ACI). The WTRU may be configured to establish a connection with the CAS based on the ACI. The WTRU may be configured to send notifications to one or more ACR entities indicating that ACR to the CAS has been initiated. The WTRU may be configured to retrieve CAS details using the ACI.

Description

Background Art

[0001] Cross-reference of related applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 457,956, filed Apr. 7, 2023, the content of which is hereby incorporated by reference in its entirety.

[0002] Background technology The application layer can be used to support edge services. An application client (AC) can be a user application that exists on a WTRU that communicates with an EAS. A WTRU can use one or more (e.g., several) ACs simultaneously.

[0003] An Edge Application Server (EAS) can be an application server that exists in an Edge Data Network (EDN). An EAS can be a software server that runs on general-purpose hardware located at the edge and / or provides services to an AC. In the context of examples of mobility and / or relocation, a source EAS (S-EAS) can be an instance of an EAS that is at an initial location (e.g., before mobility / relocation occurs) and / or services an AC. A target EAS (T-EAS) can be an instance of an EAS that is at a destination location (e.g., after mobility and / or relocation has occurred) and / or services an AC. It is possible to have one or more (e.g., multiple) EAS instances per EDN. One or more (e.g., each) EDNs can include different sets of different types of EAS instances (e.g., different EAS IDs). An EAS can service one or more AC instances that exist on different WTRUs.

[0004] An Edge Enabler Client (EEC) can provide edge support to one or more AC instances on a WTRU. There can be one or more EECs per WTRU. One or more (e.g., each) AC can use only one EEC (e.g., just one).

[0005] An Edge Enabler Server (EES) can provide one or more support functions included by the EAS and / or EEC. In the context of the mobility and / or relocation example, the source EES (S-EES) may be the EES used before the mobility and / or relocation occurs, and / or the target EES (T-EES) may be the EES used after the mobility / relocation occurs. It is possible to have one or more EES instances per EDN (e.g., per DNN). It is possible to have one or more (e.g., multiple) EDN instances in a network.

[0006] An Edge Configuration Server (ECS) can provide one or more support functions for EEC and / or EES to discover one or more EES instances that provide a specific EAS. It is possible to have one or more ECS instances for a network.

[0007] A Notification Management Client (NMC) can provide one or more support functions for an EEC to create a notification channel between the NMC and the Notification Management Server (NMS) to receive one or more notifications from the ECS and / or EES. One or more (e.g., each) EEC can use one NMC (e.g., only one).

[0008] One or more service continuity procedures may be included in the EEL to migrate the application context from S-EAS to T-EAS. Context migrations may be triggered, for example, by WTRU movement and by one or more non-mobility events (e.g., EAS server maintenance, overload, etc.). The objective of service continuity may be to minimize edge service interruptions to AC running on the WTRU.

[0009] Application service continuity, including context relocation, can be specified by the EEL in one or more (e.g., five) different application context relocation (ACR) scenarios. One or more (e.g., each) scenario may include one or more (e.g., four) different phases, namely discovery, decision, execution, and / or post-execution. One or more ACR scenarios may specify one or more different EEL entities (e.g., EEC, EES, EAS) (e.g., discovery entity and / or decision-making entity) for the discovery and / or decision (e.g., decision) phase, and one or more different sets of interactions between one or more EEL entities for the execution phase.

[0010] A user session may be represented by a logical connection between the AC of a WTRU and an application server (AS) on an edge node (e.g., EAS) and / or an AS on a cloud node (e.g., CAS). Application data may be exchanged between the AC and the AS via the logical connection. The AC and / or EEC of a WTRU can discover one or more EDNs where edge services are available using one or more services from the edge enablement layer (EEL), establish connectivity with one or more EDNs, discover one or more EAS instances within an EDN, select one or more EAS instances, and / or configure one or more EEL parameters (e.g., ACR, traffic impact, etc.) related to the user session between the AC and one or more EASs. The AC can connect the selected EAS and / or initiate the exchange of user application data with the selected EAS. [Overview of the Initiative]

[0011] Systems, methods, and apparatus described herein enable application context migration between an edge application server (EAS) and a cloud application server (CAS). Cloud relocation information (CRI) may include application layer service continuity capabilities, requirements, and / or information included by the Edge Enabler Client (EEC) and / or EAS for Application Context Relocation (ACR) scenario selection. ACR configuration information (ACI) may include ACR discovery and / or execution configurations required by the EEC and / or Edge Enabler Server (EES) and / or EAS for ACR discovery and / or execution for the cloud (e.g., derived from CRI). The procedures described herein may include functionality for providing CRI from the application layer to the EEC and / or EES, functionality for selecting ACR scenarios using CRI, and / or functionality for distributing ACI to ACR detection and / or execution entities (e.g., EEC and / or EES and / or EAS). The procedures described herein may also include functionality for configuring ACR detection and / or ACR execution in the EEC and / or EES and / or EAS to detect the need for ACR to the CAS and / or migrate the application context to the CAS.

[0012] Systems, methods, and apparatus described herein relate to the selection of application context relocation scenarios (e.g., edge cloud) based on cloud relocation information (CRI) provided by an application client (AC).

[0013] The wireless transmit-receive unit (WTRU) may be configured to perform an EAS discovery procedure for a user session. The WTRU may be configured to determine, based on the EAS discovery procedure, that there are no target EAS (T-EAS) instances available for the user session. The WTRU may be configured to determine whether the user session supports ACR to the CAS using ACI. The WTRU may be configured to establish a connection with the CAS based on ACI. The WTRU may be configured to send a notification to one or more ACR entities informing them that ACR to the CAS has been initiated.

[0014] The WTRU may be configured to obtain CAS details using ACI. The WTRU may be configured to initiate the migration of the user session context from EAS to CAS based on ACI. The WTRU may be configured to perform DNS resolution for CAS based on ACI. The WTRU may be configured to determine that there are no T-EAS instances available for a user session based on one or more of the following: an ACR trigger in ACI, or the WTRU moving to a location where the T-EAS instance does not meet the requirements associated with the user session. A change in the WTRU's location triggers the need to change EAS. ACI may include CRI indicating CAS information, application layer capabilities, or application layer requirements, wherein CAS information includes an Internet Protocol (IP) address, a Fully Qualified Domain Name (FQDN), a Universal Resource Identifier (URI), a Data Network Name (DNN), a Data Network Access Identifier (DNAI), or Single-Network Slice Selection Assistance Information (S-NSSAI) to reach the CAS. [Brief explanation of the drawing]

[0015] [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that may be used in the communication system shown in Figure 1A, according to one embodiment. [Figure 1C]This is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 1D] This is a system diagram showing further exemplary RAN and further exemplary CN that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 2] This is a system diagram of an exemplary architecture for enabling edge applications. [Figure 3] This figure shows an illustrative high-level overview of Application Context Relocation (ACR). [Figure 4] This is a flowchart of an ACR configuration provided by an exemplary edge enabler client (EEC) with cloud relocation information (CRI) provided by an application client (AC). [Figure 5] This is a flowchart of ACR scenarios selected by one or more exemplary EECs with CRI provided by the Edge Application Server (EAS). [Figure 6] This is a flowchart of an ACR scenario selected by one or more exemplary edge enabler servers (EES) with CRI provided by the EAS. [Figure 7] This is an exemplary flowchart of ACR detection, ACR execution, and / or ACR scenario reselection using ACI. [Modes for carrying out the invention]

[0016] Figure 1A shows an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the 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 filtering OFDM, and filter bank multicarrier (FBMC).

[0017] As shown in Figure 1A, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and 102d, RAN 104 / 113, CN 106 / 115, the Public Switched Telephone Network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRU102a, 102b, 102c, and 102d may all be referred to as “stations” and / or “STAs” and may be configured to transmit and / or receive wireless signals, and may include user equipment (UEs), mobile stations, fixed or mobile subscriber units, subscriber-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial context and / or automated processing chain context), consumer electronics devices, and devices operating on commercial wireless networks and / or industrial wireless networks. Any of WTRU102a, 102b, 102c, and 102d may be referred to interchangeably with WTRU.

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

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

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

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

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

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

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

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

[0026] The base station 114b in Figure 1A may be, for example, a wireless router, Home Node B, Home eNode B, or access point, and any suitable RAT can be used to facilitate wireless connectivity in local areas such as workplaces, homes, vehicles, campuses, industrial facilities, air corridors (for use by drones, for example), and roads. In one embodiment, the base station 114b and WTRU 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and WTRU 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base stations 114b and WTRUs 102c, 102d can establish picocells or femtocells using cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not be required to access the internet 110 via CN 106 / 115.

[0027] RAN104 / 113 can communicate with CN106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 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, and mobility requirements. CN106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 / 113 and / or CN106 / 115 may communicate directly or indirectly with other RANs using the same RAT or a different RAT as RAN104 / 113. For example, in addition to being connected to RAN104 / 113, which may be using NR radio technology, CN106 / 115 may also be communicating with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0028] CN106 / 115 can also function as a gateway for WTRU102a, 102b, 102c, 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing conventional telephone services (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) in the TCP / IP Internet Protocol Suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs that can use the same RAT as RAN104 / 113 or a different RAT.

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

[0030] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any subcombinations of the aforementioned elements while maintaining consistency with the embodiment.

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

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

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

[0034] The transceiver 120 may be configured to modulate the signal to be transmitted by the transmit / receive element 122 and to demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

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

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

[0037] The processor 118 may also be coupled to a GPS chipset 136 which can be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or instead of, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its position based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any suitable positioning method while maintaining consistency with the embodiments.

[0038] The processor 118 may be further 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 modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. Peripheral 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, compass sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

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

[0040] Figure 1C is a system diagram showing RAN104 and CN106 according to an embodiment. As described above, RAN104 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using E-UTRA wireless technology. RAN104 can also communicate with CN106.

[0041] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B while maintaining consistency with the embodiment. Each eNode-B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, eNode-B160a, 160b, and 160c may implement MIMO technology. Thus, eNode-B160a may, for example, use multiple antennas to transmit a wireless signal to and / or receive a wireless signal from WTRU102a.

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

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

[0044] The MME162 can be connected to each of the eNode-B162a, 162b, and 162c within RAN104 via the S1 interface and can function as a control node. For example, the MME162 can be responsible for authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 can provide control plane functionality for switching between RAN104 and other RANs (not shown) using other radio technologies such as GSM and / or WCDMA.

[0045] The SGW164 can be connected to each of the eNode B160a, 160b, and 160c within RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions such as anchoring the user plane during eNode B handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0046] SGW164 may be connected to PGW166, which can provide WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, thereby facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0047] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to circuit-switched networks such as PSTN108, thereby facilitating communication between WTRU102a, 102b, and 102c and conventional land-line communication devices. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 can provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0048] Although the WTRU is described as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface with a communication network (for example, temporarily or permanently).

[0049] In a typical embodiment, the other network 112 may be a WLAN.

[0050] In Infrastructure Basic Service Set (BSS) mode, a WLAN may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interfaces with a distribution system (DS) or another type of wired / wireless network that carries traffic entering and / or leaving the BSS. Traffic originating from outside the BSS to the STA may arrive through the AP and be delivered to the STA. Traffic originating from the STA to destinations outside the BSS may be sent to the AP to be delivered to their respective destinations. Traffic between STAs within the BSS may be sent through the AP; for example, a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS is considered and / or may be called peer-to-peer traffic. Peer-to-peer traffic may be sent between a source STA and a destination STA (e.g., directly between them) using a Direct Link Setup (DLS). In certain representative embodiments, the DLS may be an 802.11e DLS or an 802.11z Tunnel DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have access points (APs), and STAs within or using IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may also be referred to herein as the “ad-hoc” communication mode.

[0051] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be of a fixed width (e.g., a 20 MHz bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS, which can be used by STAs to establish a connection with the AP. In certain typical embodiments, carrier sensing multiple access (CSMA / CA) with collision avoidance may be implemented, for example, in an 802.11 system. In the case of CSMA / CA, an STA, including the AP (e.g., any STA), may sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that STA may backoff. A single STA (e.g., only one station) may transmit at any given time within a given BSS.

[0052] A high-throughput (HT) STA may use a 40MHz wide channel for communication, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0053] Ultra-high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz, and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. 160MHz channels can be formed by combining eight consecutive 20MHz channels or two discontinuous 80MHz channels, which may be called an 80+80 configuration. In the 80+80 configuration, after channel coding, data can be passed through a segment parser that can split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing can be performed separately for each stream. The streams can be mapped onto two 80MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of a receiving STA, the operation described above for the 80+80 configuration can be reversed, and the combined data can be sent to a media access control (MAC).

[0054] Sub-1GHz operating modes are supported by 802.11af and 802.11ah. The bandwidth and carrier on which the channel operates are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine-type communications, such as MTC devices in a macro coverage area. MTC devices may have limited capabilities, including support for specific bandwidths and / or limited bandwidths (e.g., support only for those bandwidths). MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

[0055] 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 the primary channel. The primary channel may have a bandwidth equal to the common maximum operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the mode operating at the minimum bandwidth among all STAs operating in the BSS. In the 802.11ah example, even if the AP and other STAs in the BSS support modes operating at 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidths, the primary channel may be 1MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only supports) the 1MHz mode. Carrier discovery settings and / or network allocation vector (NAV) settings may depend on the status of the primary channel. For example, if the primary channel is busy with an STA (which only supports a mode operating at 1MHz) transmitting to an AP, the entire available frequency band may be considered busy, even though a large portion of the frequency band remains idle and may be available.

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

[0057] Figure 1D is a system diagram showing RAN113 and CN115 according to an embodiment. As described above, RAN113 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using NR radio technology. RAN113 can also communicate with CN115.

[0058] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with the embodiment. Each of the gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, the gNB180a, 180b, and 180c may implement MIMO technology. For example, the gNB180a and 180b may utilize beamforming to transmit signals to and / or receive signals from the gNB102a, 102b, and 102c. Therefore, gNB180a can, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from WTRU102a. In embodiments, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a can transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In embodiments, gNB180a, 180b, and 180c may implement coordinated multipoint (CoMP) technology. For example, WTRU102a can receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0059] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with scalable neurology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different wireless transmission spectral portions. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or sustaining varying absolute times).

[0060] The gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with the gNB180a, 180b, and 180c without accessing other RANs (e.g., eNode-B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can use one or more of the gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with the gNB180a, 180b, and 180c using signals within an unauthorized band. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with / connect to gNB180a, 180b, and 180c, while also communicating with / connecting to other RANs such as eNode-B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement the DC principle to communicate substantially simultaneously with one or more gNB180a, 180b, and 180c, and one or more eNode-B160a, 160b, and 160c. In a non-standalone configuration, eNode-B160a, 160b, and 160c can act as mobility anchors for WTRU102a, 102b, and 102c, while gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

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

[0062] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally, a Data Network (DN)185a, 185b. Although each of the aforementioned elements is shown as part of the CN115, it will be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0063] AMF182a and 182b can be connected to one or more of gNB180a, 180b, and 180c within RAN113 via the N2 interface and can act as control nodes. For example, AMF182a and 182b can be responsible for user authentication of WTRU102a, 102b, and 102c, support for network slicing (e.g., handling different PDU sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of NAS signaling, mobility management, etc. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service being utilized. For example, different network slices may be established for different use cases, such as services relying on ultra-high reliability low latency (URLLC) access, services relying on extended massive mobile broadband (eMBB) access, services for machine-type communications (MTC) access, and / or similar. The AMF162 can provide control plane functionality for switching between RAN113 and other RANs (not shown) using other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0064] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0065] UPF184a and 184b may be connected to one or more of gNB180a, 180b, and 180c in RAN113 via the N3 interface, which can provide WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0066] CN115 can facilitate communication with other networks. For example, CN115 may include, or can communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN115 and PSTN108. Furthermore, CN115 can provide WTRU102a,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, WTRU102a,102b,102c may be connected to the local data network (DN) 185a,185b via an N3 interface to UPF184a,184b and an N6 interface between UPF184a,184b and DN185a,185b.

[0067] In the diagrams of Figures 1A to 1D, and the corresponding descriptions of Figures 1A to 1D, one or more or all of the functions described herein with respect to one or more of the WTRU102a to d, base stations 114a to b, eNode-B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to ab, UPF184a to b, SMF183a to b, DN185a to b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or to simulate network and / or WTRU functions.

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

[0069] One or more emulation devices can perform one or more functions, including all of the above, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test scenario in a test laboratory and / or 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 (e.g., which may include one or more antennas) can be used by the emulation device to transmit and / or receive data.

[0070] The terms ACR scenario and ACR procedure may be used interchangeably as described herein.

[0071] A WTRU can be configured to run an application layer to support one or more edge services.

[0072] Figure 2 shows a system diagram of an exemplary architecture 200 (e.g., a high-level architecture) for enabling edge applications. One or more components of the architecture are described herein.

[0073] An Application Client (AC) can be a user application residing on a WTRU that communicates with the EAS. A WTRU can use one or more (e.g., several) ACs simultaneously.

[0074] An Edge Application Server (EAS) can be an application server residing in an Edge Data Network (EDN). An EAS can be a software server running on general-purpose hardware located at the edge and / or serving ACs. In the context of the mobility and / or relocation example, the Source EAS (S-EAS) can be an instance of the EAS serving the AC at the initial location (e.g., before mobility / relocation occurs). The Target EAS (T-EAS) can be an instance of the EAS serving the AC at the destination location (e.g., after mobility and / or relocation occurs). There can be one or more (e.g., multiple) EAS instances per EDN. One or more (e.g., each) EDN may contain different sets of different types of EAS instances (e.g., different EASIDs). An EAS can serve one or more AC instances that may reside on different WTRUs.

[0075] An Edge Enabler Client (EEC) can provide edge support to one or more AC instances on a WTRU. It is possible to have one or more EECs per WTRU. One or more (e.g., each) AC can use only one EEC (e.g., just one).

[0076] An Edge Enabler Server (EES) can provide one or more supporting functions included by the EAS and / or EEC. In the context of the mobility and / or relocation example, the source EES (S-EES) may be the EES used before the mobility and / or relocation occurs, and / or the target EES (T-EES) may be the EES used after the mobility / relocation occurs. It is possible to have one or more EES instances per EDN (e.g., per DNN). It is possible to have one or more (e.g., multiple) EDN instances in a network.

[0077] An Edge Configuration Server (ECS) can provide one or more support functions for EEC and / or EES to discover one or more EES instances that provide a specific EAS. It is possible to have one or more ECS instances for a network.

[0078] A Notification Management Client (NMC) can provide one or more supporting functions for an EEC to generate a notification channel between the NMC and the Notification Management Server (NMS) to receive one or more notifications from the ECS and / or EES. One or more (e.g., each) EEC may use one NMC (e.g., only one).

[0079] A Notification Management Client (NMS) can provide one or more support functions for the ECS and / or EES to send one or more notifications to the EEC via a notification channel established between the NMC and the NMS. It is possible for a network to have one or more NMSs.

[0080] The systems, methods, and apparatus described herein can provide service continuity. One or more service continuity procedures may be included in the EEL to migrate the application context from S-EAS to T-EAS. Context migration may be triggered, for example, by WTRU movement and by one or more non-mobility events (e.g., EAS server maintenance, overload, etc.). Service continuity can reduce and / or minimize edge service interruptions to ACs operating on WTRUs.

[0081] Application service continuity, including context relocation, can be specified by the Application Context Relocation (EEL) in one or more (e.g., five) different Application Context Relocation (ACR) scenarios. One or more (e.g., each) scenario may include one or more (e.g., four) different phases, namely discovery, decision, execution, and / or post-execution. One or more ACR scenarios may specify one or more different sets of interactions between one or more EEL entities for discovery and / or decision (e.g., EEC, EES, EAS), (e.g., decision) phases (e.g., discovery entities and / or decision-making entities), and / or for the execution phase.

[0082] Figure 3 provides a high-level overview of an exemplary ACR procedure 300. A detection entity can monitor the location and / or movement of the WTRU and / or inform a decision-making entity. The decision-making entity can determine whether an ACR is included (e.g., requested) and / or instruct an execution entity to perform the ACR. The execution entity can perform one or more ACR procedures as described herein (e.g., as described in the continuity of service scenario) to migrate the application context from S-EAS to T-EAS. When the ACR execution is complete, for example, an ACR cleanup may be performed. For example, in 302, a detection entity (e.g., EEC, EES, or EAS) can detect that an ACR may be required. The detection entity can inform one or more decision-making entities (e.g., EEC, EES, or EAS) that an ACR is required. In 304, the decision-making entity can decide whether an ACR is required, for example, based on what it has been informed by the detection entity. In 306, an executing entity (e.g., an EEC, EES, or EAS) may perform an ACR. In 308, an executing entity may perform one or more post-ACR actions as described herein.

[0083] The systems, methods, and apparatus described herein may relate to user sessions. A user session may be represented by a logical connection between the AC of a WTRU and an application server (AS) at an edge node (e.g., EAS) and / or an AS at a cloud node (e.g., CAS). Application data may be exchanged between the AC and the AS via the logical connection. The AC and / or EEC of a WTRU may discover one or more EDNs where edge services are available using one or more services from the Edge Enablement Layer (EEL), establish connectivity with one or more EDNs, discover one or more EAS instances within an EDN, select one or more EAS instances, and / or configure one or more EEL parameters (e.g., ACR, traffic impact, etc.) related to the user session between the AC and one or more EASs. The AC may connect the selected EAS and / or initiate the exchange of user application data with the selected EAS.

[0084] The Edge Enablement Service Layer can support application context relocation between one or more edge application servers. One or more system hardenings can provide application services in one or more areas where edge coverage is unavailable. One or more hardenings may include support for service continuity for AC during switching between edge and cloud application servers (CAS).

[0085] To migrate application contexts from EAS to CAS, the EEC and / or S-EES can know if CAS is supported and / or have CAS information (e.g., IP address, FQDN, URI, DN information) to perform the migration. In one or more ACR scenarios where the AC and / or S-EAS select target application servers, the AC and / or S-EAS may have pre-configured CAS capabilities and / or information. The AC and / or S-EAS can use the pre-configured CAS information when initiating ACR to CAS. In one or more ACR scenarios where the EEC and / or S-EES select target application servers, the EEC and / or S-EES may not have CAS capabilities or CAS information to initiate ACR to CAS. For example, one or more (e.g., specific) ACR procedures may not support service continuity from EAS to CAS. The EEC and / or S-EES may not have CAS capabilities or CAS information to select ACR scenarios according to CAS requirements and / or to initiate ACR to CAS.

[0086] Application context migration to CAS may be triggered when edge coverage is unavailable (e.g., EAS discovery cannot find available EES and / or EAS). CAS migration may not be permitted for some applications (e.g., edge-native applications). Furthermore, CAS migration may be triggered based on one or more factors (e.g., service contract, cost, etc.) that differ from existing ACR discovery and / or decision criteria. EEL may be unaware of these one or more application layer constraints for application context migration between the edge and the cloud. For example, one or more ACR procedures between the edge and the cloud may be unaware of and / or fail to detect constraints related to migrating edge application contexts to the cloud.

[0087] One or more system procedures for migrating an edge application context from one EAS to a second EAS may not apply when migrating an edge application context from one EAS to a CAS. One or more system procedures may be insufficient because they may not enable the detection and / or discovery of one or more available cloud servers and / or the detection of one or more events that trigger migration to a cloud server.

[0088] The systems, methods, and apparatus described herein relate to supporting application context migration (e.g., one or more enhancements to 3GPP EEL) between edge and cloud application servers. A cloud application server (CAS) may refer to an application server deployed in a different data network (DN) than the edge data network (EDN) where the edge application server (EAS) is deployed. Migrating context between the CAS and the EAS may involve migration from a first DN to a second DN. Provisioning of application layer service continuity capabilities, requirements, and / or information may be provided in the EEC and / or EES. The EEC and / or EES can use the provisioned information to select ACR scenarios for user sessions and / or configure one or more ACR discovery triggers and / or ACR execution behaviors, thereby enabling application context migration between the edge and one or more cloud application servers.

[0089] Systems, methods, and apparatus are described herein with respect to Cloud Relocation Information (CRI). One or more EEL service continuity capabilities, requirements, and / or information may be provided by the application layer, for example, to enable ACR scenario selection and / or configuration for contextual migration from EAS to CAS. ACR configuration information (ACI) may be derived from the CRI. ACI may be used to configure ACR discovery and / or execution for migration from EAS to CAS.

[0090] The system, method, and apparatus may be configured with respect to the selection of one or more application context relocation (ACR) procedures for the cloud. One or more issues may be addressed regarding the possibility that one or more edge enablement layer (EEL) participants (e.g., edge enabler clients (EEC), edge enabler servers (EES), edge application servers (EAS), and / or edge configuration servers (ECS)) may not have adequate (e.g., requested) information to determine whether application context relocation (ACR) with the cloud is possible and / or how ACR may be performed. When migrating to a target edge data network (EDN), for example, this information may be provided by one or more EEL participants. When migrating to the cloud, information may be missing (e.g., when the application context can be migrated to the cloud, how one or more available cloud application servers are discovered, under what circumstances ACR can be performed against the cloud, what ACR procedures may be used to support ACR against the cloud, etc.). The systems, methods, and apparatus described herein relate to provisioning Cloud Relocation Information (CRI) in one or more EEL participants, and / or deriving and / or determining (e.g., making decisions) an "ACR configuration".

[0091] A WTRU (e.g., an EEC) can determine the ACR configuration for cloud relocation. The WTRU can determine the Cloud Relocation Information (CRI). The CRI may be pre-configured in the EEC and / or provided by the AC. The CRI may indicate the AC's cloud migration capability, information about one or more cloud servers, one or more conditions for relocating to the cloud, and / or configuration information for one or more ACR procedures. Provided that the cloud migration capability indicated by the CRI indicates that the AC can migrate to the cloud application server, the WTRU can perform one or more of the following: The WTRU can send a service provisioning request to the ECS. The service provisioning request may include the CRI, e.g., the determined CRI (e.g., if it is obtained by the EEC). The WTRU can receive a service provisioning response from the ECS. The service provisioning response may include one or more EES instances that can support cloud relocation. The WTRU can send an EAS discovery request to the EES. The EAS discovery request may include the determined CRI (e.g., if it is obtained by the EEC). The WTRU may receive an EAS discovery response from the EES. The EAS discovery response may include one or more EAS instances that can support cloud relocation. The EAS discovery response may include the determined CRI (e.g., if it is obtained by the EES). For example, if the EEC does not have a pre-provisioned CRI and has not received a CRI from the AC (e.g., the EEC may receive a CRI from the EES in the EAS discovery procedure), the EAS discovery response may include the determined CRI.

[0092] A WTRU can select EAS instances and / or one or more ACR scenarios, for example, based on cloud migration capabilities. A WTRU can determine ACR configuration information (ACI) based on one or more ACR capabilities of application clients (ACs), one or more ACR capabilities of EECs, one or more ACR capabilities of EESs, one or more ACR capabilities of EASs, and / or determined CRIs. A WTRU can send an EAS information provisioning request to the EES. The EAS information provisioning request may include the selected EAS instances, one or more ACR scenarios, and / or determined ACIs. A WTRU can receive an EAS information provisioning response from the EES. The EAS information provisioning response may include an indication that the selected EAS instances, one or more ACR scenarios, and / or determined ACIs have been accepted. A WTRU can then initiate the ACR discovery process based on the determined ACIs.

[0093] Furthermore, the EES may receive the CRI from the EAS. The EES may provide the CRI to the EEC (for example, as shown in Figure 5). When the EES receives the CRI from the EAS, the EEC may delegate the ACR scenario selection to the EES. For example, the EES may determine the ACI when the EEC delegates the ACR scenario selection to the EES.

[0094] One or more EEL service continuity capabilities may include an indication that service continuity is required, a list of supported ACR scenarios, and / or a list of preferred ACR scenarios. EEL service continuity capabilities may be provided by AC, EAS, EEC, and / or EES. Service continuity capabilities can be used during ACR scenario selection to determine one or more ACR procedures that may be used for service continuity of user sessions between AC and EAS.

[0095] To enable application context migration between the edge and one or more cloud application servers, one or more enhancements to service continuity capabilities and / or one or more enhancements to one or more ACR management procedures (e.g., ACR scenario selection and / or ACR execution) may be provided.

[0096] One or more service continuity capabilities provided by the application layer may be enhanced with Cloud Relocation Information (CRI). CRI may include CAS information (e.g., IP address, FQDN, URI, DNN, DNAI, SNSSAI) for CAS discovery and / or establishing a user session with the CAS. Furthermore, CRI may include one or more application layer capabilities and / or requirements for application context migration between the edge and one or more cloud application servers. For example, CRI may include whether the application is eligible to be moved to the cloud, one or more Key Performance Indicator (KPI) requirements for migration to the cloud, one or more service areas for migration to the cloud, one or more edge service SLA thresholds (e.g., edge usage limits) for migration to the cloud, time for migration to the cloud, supported cloud service providers, supported application service providers, CAS provisioning modes to specify how the EEL can obtain CAS information (e.g., application layer provisioning and / or EEL determined), and / or one or more other requirements.

[0097] CAS information may be provisioned in the EEL to inform the EEC and / or EES about CAS connectivity. CAS information may also be used in the EEL to inform the EEC and / or EES how to obtain additional CAS information, such as CAS endpoints (e.g., IP addresses, FQDNs, URIs, etc.).

[0098] One or more CRI capabilities and / or requirements may be provisioned in the EEL to inform the EEC and / or EES about application layer capabilities and / or requirements for application context migration between the edge and one or more cloud application servers. One or more CRI capabilities and / or requirements may be used by the EEC and / or EES to select one or more ACR scenarios that fit the cloud migration. One or more CRI capabilities and / or requirements may be used by the EEC and / or EES to discover ACR and / or derive and / or configure one or more ACR execution rules in the EEC, EES, and / or EAS.

[0099] EEC and / or EES can use provisioned CRI to derive ACR Configuration Information (ACI). The ACI may include configurations for selected ACR scenarios. The configurations may include ACR discovery configurations to trigger migration to the cloud, ACR execution configurations, and / or information (e.g., arbitrary) from the CRI. The ACR discovery configurations may include ACR discovery priorities and / or discovery trigger criteria such as edge service KPI thresholds, SLA thresholds (e.g., edge usage limits), time, and / or edge and / or cloud service areas. The ACR execution configurations may include one or more actions to take when T-EAS is unavailable during ACR, one or more actions to take when ACR is triggered by discovery criteria from the ACR discovery configuration (e.g., ignore discovered EAS), and / or one or more ACR steps to be skipped during migration to the cloud.

[0100] ACI can be used to configure ACR detection and / or ACR execution behavior in EEC, EES, and / or EAS. For example, EEC, EES, and / or EAS can configure one or more detection triggers and / or ACR execution rules to identify and / or execute migrations to CAS.

[0101] ACR can be selected and / or configured for the cloud. EEC can receive CRI from AC. EEC can use CRI for ACR scenario selection. EEC can derive and / or distribute ACI to EES (e.g., and / or indirectly to EAS) for ACR scenario configuration. When EEC selects an ACR scenario for a user session and / or receives CRI from AC, EEC can use the CRI to determine the ACI for the selected ACR scenario and / or provide the determined ACI to EES and / or selected EAS.

[0102] Figure 4 shows an exemplary ACR configuration procedure 400 provided by the EEC when the CRI is provided by the AC402. As a prerequisite, the AC402 may have generated and / or received CRIs. For example, the CRIs may be pre-provisioned to the AC402 and / or received from the application server. The CRIs may include CAS information, the cloud migration capability of the application context, one or more conditions for relocation to the cloud, configurations for the ACR procedure, application layer capabilities associated with ACR to the cloud, and / or application layer requirements associated with ACR to the cloud.

[0103] In 420, AC402 can register with EEC404, for example, using the edge-5 interface. AC402 may include a CRI in its registration request to inform EEC404 about application layer capabilities and / or requirements for ACR to the cloud, and / or CAS information. For example, EEC404 can obtain the CRI associated with AC402 in 420. Based on the CRI, EEC404 can determine whether the user session supports ACR to the CAS. Alternatively, AC402 may receive a CRI from an application server (AS), which may be running, for example, in the cloud. Interaction between AC402 and the AS may occur at the application layer.

[0104] In 422, EEC404 can perform one or more service provisioning procedures with ECS406 to obtain EDN configuration information and / or a list of available EESs. EEC404 can send a service provisioning request to ECS406. The service provisioning request may include a CRI and indicate to ECS406 that EEC404 wants to discover an EES (e.g., only) that supports ACR scenarios conforming to ACR to CAS. ECS406 can send a service provisioning response to EEC404. Upon receiving the service provisioning response, EEC404 can use the CRI capabilities and / or requirements to select an EES (e.g., EES408) that supports ACR between the edge and the cloud application server. For example, if the CRI indicates a request to support ACR to CAS, EEC404 can select an EES (e.g., EES408) that supports ACR scenarios conforming to ACR to CAS. For example, if CRI indicates a request for application layer CAS resolution in AC402, EEC404 can select an EES (e.g., EES408) that supports the ACR scenario in which EEC404 and / or AC402 determine the target EAS.

[0105] In 424, EEC404 may perform one or more EAS discovery procedures for a user session to obtain, for example, a list of one or more available EAS instances in a selected EES408. An EAS discovery request may include a CRI. EES408 may consider the CRI as a discovery filter and provide one or more EAS instances in the EAS discovery response that satisfy the CRI capability and / or requirements.

[0106] In 426, upon receiving an EAS discovery response, EEC404 can, for example, select an EAS instance from the list of discovered EAS instances provided in the response. In 426, EEC404 can select one or more ACR scenarios to be used to provide service continuity to user sessions (for example, according to the cloud migration capabilities of AC402 and / or CRI). For example, the cloud migration capabilities of AC402, EEC404, selected EAS408, and / or selected EAS410 may be considered while selecting an ACR scenario. For example, EEC404 can select one or more ACR scenarios for user sessions based on CRI in 426. EEC404 can select an EAS (e.g., EAS410) and / or ACR scenario that meets the CRI requirements, taking into account the CRI capabilities and / or requirements for EAS selection and / or ACR scenario selection. EEC404 can determine, based on the EAS discovery performed in 424, that there are no target EAS (T-EAS) instances available for the user session. For example, if CRI indicates a request to support application context migration to CAS and / or CAS resolution in EAS (e.g., EAS410), EEC404 can select one or more ACR scenarios in EAS408 and / or EAS (e.g., EAS410) that determine the target EAS.

[0107] EEC404 can derive an ACI for a selected ACR scenario based on the CRI capabilities and / or requirements provided to one or more (e.g., each) selected EAS instances. The ACI may include ACR discovery and / or ACR execution configurations for EEC404, EES408, and / or EAS (e.g., EAS410). For example, if the CRI capabilities and / or requirements indicate that the CAS relocation will be within a specific service area, EEC404 may include one or more (e.g., several) ACR discovery triggers in the ACI based on the WTRU location and / or the need to monitor the WTRU location. For example, if the CRI capabilities and / or requirements indicate CAS resolution in AC402, EEC404 may include one or more (e.g., several) ACR execution rules in the ACI so that the CAS can be resolved in AC402 when T-EAS is not discovered and / or is unavailable.

[0108] In 428, EEC404 can send an EAS information provisioning request to EES408. The EAS information provisioning request may include an ACI associated with the CRI (e.g., derived from CRI capabilities and / or requirements). EES408 can use the ACI provided in the EAS information provisioning request to determine whether ACR detection can be performed in EES408 and / or configure ACR processing according to the provided ACI.

[0109] In 426, if EAS selection selects one or more (e.g., multiple) EAS instances based on AC requirements, for example, EEC404 may provision ACIs in EES408 and / or EAS (e.g., EAS410, etc.) by sending one or more (e.g., multiple) EAS information provisioning requests to the same and / or one or more different EESs, and / or by sending a single EAS information provisioning request containing ACIs for one or more (e.g., multiple) user sessions.

[0110] In 430, EES408 can send an ACR management event to a selected EAS410. The ACR management event may include an ACI derived from CRI capability and / or requirements. Using the ACI provided in the ACR management event, EAS410 can determine whether ACR detection can be performed in EAS410 and / or configure ACR processing according to the provided ACI.

[0111] In 432, EES408 can send an EAS information provisioning response to EEC404. For example, EEC404 can receive an EAS information provisioning response from EES408. The EAS information provisioning response may include the status of the EAS provisioning request (e.g., a result indicating whether the ACI was properly provisioned).

[0112] In 434A, EEC404 can configure ACR detection and ACR execution according to the selected ACR scenario and / or ACI. EEC404 can configure ACR detection and ACR execution at any time after receiving the EAS information provisioning response from EES408.

[0113] In 434B, EES408 can configure ACR detection and / or ACR execution according to one or more ACR scenarios and / or ACIs selected as described herein. EES408 can configure ACR detection and / or ACR execution after sending an EAS information provisioning response to EEC404 (for example, at any time).

[0114] In 434C, EAS410 can configure ACR detection and / or ACR execution according to the selected ACR scenario and / or ACI as described herein. EAS410 can configure ACR detection and / or ACR execution after receiving an ACR management event from EAS408 (for example, at any time).

[0115] The EEC can select one or more ACR scenarios using the CRI provided by the EAS. If the EEC selects an ACR scenario for a user session and / or the EAS provides the CRI, the EEC can use the CRI to derive an ACI in the ACR scenario selection and / or provision the ACI in the EES and / or selected EAS instances to configure the ACR procedure performed in the EES and / or EAS.

[0116] Figure 5 shows an exemplary procedure 500 for an ACR scenario selected by the EEC with a CRI provided by EAS508. As a prerequisite for the exemplary procedure for an ACR scenario selected by the EEC with a CRI provided by EAS508, EAS508 may be generating and / or obtaining a CRI. For example, the CRI may be pre-provisioned within EAS508 and / or obtained from an application server.

[0117] In 520, EAS508 can register with EES506. EAS508 may include a CRI in its registration request to inform EES506 of one or more application layer capabilities and / or one or more requirements for application context migration to the cloud, and / or to provide CAS information to EEL.

[0118] In 522, EEC502 can perform one or more service provisioning procedures with ECS504 to obtain, for example, EDN configuration information and / or a list of one or more available EES instances.

[0119] In step 524, EEC502 may perform one or more EAS discovery procedures to obtain, for example, a list of one or more available EAS instances in the selected EES506. For example, EEC502 may send an EAS discovery request to EES506 in step 524.

[0120] In 526, EES506 can send an EAS discovery response to EEC502. The EAS discovery response may contain a list of one or more discovered EAS instances and / or contain CRIs for one or more (e.g., each) EAS instances.

[0121] In 528, upon receiving an EAS discovery response, EEC502 may, for example, select one or more EAS instances and / or one or more ACR scenarios to be used for service continuity of user sessions. EEC502 may consider one or more CRI capabilities and / or one or more requirements provided to one or more (e.g., each) EAS instances in order to select one or more EAS instances and / or one or more ACR scenarios to support ACR between the edge and the cloud application server. For example, if the CRI indicates a request to support application context migration to CAS and / or CAS resolution in AC, EEC502 may, in 528, select one or more ACR scenarios for EEC502 and / or AC to determine T-EAS.

[0122] EEC502 can derive an ACI for selected ACR scenarios based on one or more CRI capabilities and / or requirements provided to one or more (e.g., each) selected EAS instances. The ACI may include ACR discovery and / or ACR execution configurations for EEC502, EES506, and / or EAS508. For example, if one or more CRI capabilities and / or requirements indicate that a CAS relocation is required within a particular service area, EEC502 may include one or more (e.g., several) ACR discovery triggers based on WTRU location in the ACI. For example, if one or more CRI capabilities and / or requirements indicate that a CAS relocation is required within a particular service area, EEC502 may include a request for monitoring WTRU location in the ACI. For example, if one or more CRI capabilities and requirements indicate CAS resolution in AC, EEC502 may include one or more (e.g., several) ACR execution rules in the ACI that can resolve CAS in AC when T-EAS is not discovered and / or unavailable.

[0123] EEC502 can provision ACI in EES and / or EAS to configure ACR discovery and / or execution. In 530, EEC502 can send an EAS information provisioning request (e.g., including ACI) to EES506. In 532, EES506 can send an ACR management event (e.g., including ACI) to EAS508. In 534, EES506 can send an EAS information provisioning response to EEC502.

[0124] In 536A, EEC502 can configure ACR detection and / or ACR execution according to the selected ACR scenario and / or ACI as described herein. EEC502 can configure ACR detection and / or ACR execution after receiving an EAS information provisioning response from EES506 (for example, at any time).

[0125] In 536B, EES506 can configure ACR detection and / or ACR execution according to one or more ACR scenarios and / or ACIs selected as described herein. EES506 can configure ACR detection and / or ACR execution after sending an EAS information provisioning response to EEC502 (for example, at any time).

[0126] In 536C, EAS508 can configure ACR detection and / or ACR execution according to the ACR scenario and / or ACI selected as described herein. EAS508 can configure ACR detection and / or ACR execution after receiving an ACR management event from EAS506 (for example, at any time).

[0127] The EES may be configured to select one or more ACR scenarios using CRI provided by the EAS. The EES can receive CRI from the EAS. The EES can use CRI for ACR scenario selection. The EES can derive and / or distribute ACI to the EEC and / or EAS for ACR scenario configuration.

[0128] If EES selects one or more ACR scenarios for a user session and / or EAS provides a CRI, EES can use the CRI to derive an ACI in one or more ACR scenario selections and / or provision an ACI in the EEC and / or one or more selected EAS instances to configure the ACR procedures to be performed in the EEC and / or EAS.

[0129] Figure 6 shows an exemplary procedure 600 for an ACR scenario selected in EES with a CRI provided by EAS608. As a prerequisite, for example, EAS608 may have a generated and / or obtained CRI. For example, the CRI may be pre-provisioned in EAS608 and / or obtained from an application server.

[0130] In 620, EAS608 can register with EES606. EAS608 may include a CRI in its registration request to inform EES606 about one or more application layer capabilities and / or requirements for application context migration to the cloud, and / or to provide CAS information to EEL.

[0131] In 622, EEC602 can perform one or more service provisioning procedures with ECS604 to obtain, for example, EDN configuration information and a list of one or more available EES instances.

[0132] In step 624, EEC602 can perform one or more EAS discovery procedures with the selected EES606 to obtain a list of one or more available EAS instances. Upon receiving the EAS discovery response, EEC602 can, for example, select one or more EAS instances for the user session.

[0133] In 626, EEC602 may send an EAS information provisioning request to EES606. The EAS information provisioning request may indicate that EES606 desires to select one or more EAS instances (if not selected, for example, as described herein) and / or may select one or more ACR scenarios for a user session.

[0134] In 628, upon receiving an EAS information provisioning request, EES606 may, for example, select one or more EAS instances and / or one or more ACR scenarios, thereby used for service continuity of user sessions. EES606 may select one or more EAS instances and / or one or more ACR scenarios that support ACR between the edge and one or more cloud application servers, taking into account one or more CRI capabilities and / or requirements obtained during EAS registration. For example, if CRI indicates a request to support application context migration to CAS and / or CAS resolution in AC, EES606 may, in 628, select one or more ACR scenarios in which EEC602 and / or AC determine the target EAS.

[0135] EES606 can derive an ACI for selected ACR scenarios based on one or more CRI capabilities and / or requirements provided to each selected EAS instance. The ACI may include ACR discovery and / or ACR execution configurations for EEC602, EES606, and / or EAS608. For example, if one or more CRI capabilities and / or requirements indicate that a CAS relocation will be within a specific service area, EEC602 may include one or more (e.g., several) ACR discovery triggers in the ACI based on the WTRU location and / or the need to monitor the WTRU location. For example, if one or more CRI capabilities and / or requirements indicate CAS resolution in AC, EEC602 may include one or more (e.g., several) ACR execution rules in the ACI so that CAS can be resolved in AC when T-EAS has not been discovered and / or is unavailable.

[0136] In 630, EES606 can send an ACR management event to the selected EAS608. The ACR management event may include an ACI to inform EAS608 how to configure the ACR process according to the provided ACI.

[0137] In 632, EES606 may send an EAS information provisioning response to EEC602. The EAS information provisioning response may include an ACI to inform EEC602 how to configure the ACR processing according to the provided ACI.

[0138] In 634A, EEC602 may configure ACR detection and / or ACR execution according to one or more ACR scenarios and / or ACIs selected as described herein. EEC602 may configure ACR detection and / or ACR execution after receiving an EAS information provisioning response from EES606 (for example, at any time).

[0139] In 634B, EES606 can configure ACR detection and / or ACR execution according to one or more ACR scenarios and / or ACIs selected as described herein. EES606 can configure ACR detection and / or ACR execution after sending an EAS information provisioning response to EEC602 (for example, at any time).

[0140] In 634C, EAS608 can configure ACR detection and / or ACR execution according to one or more ACR scenarios and / or ACIs selected as described herein. EAS608 can configure ACR detection and / or ACR execution after receiving an ACR management event from EAS606 (for example, at any time).

[0141] ACR can be configured, discovered, and / or executed for the cloud. One or more ACR procedures may expect EEL support in the source and / or target edge data networks (e.g., both). Therefore, supporting ACR to a cloud with insufficient (e.g., none) EEL support may involve ACR procedure configurations that alter the behavior of one or more ACR procedures for cloud migration. An ACR configuration may be distributed to one or more ACR discovery entities and / or one or more ACR execution entities (e.g., EEC, EES, EAS, etc.). An ACR configuration may be used by one or more ACR discovery entities and / or one or more execution entities.

[0142] A WTRU (e.g., an EEC) can perform one or more of the following actions to configure and / or perform ACR for cloud relocation: The WTRU can select one or more ACR scenarios to perform service continuity for the AC of the discovered WTRU and / or EAS. ACR scenario selection is obtained based on ACI information and / or the service continuity capabilities of the AC, EEC, EES, and / or EAS. The WTRU can send an EAS information provisioning request to the EES. The EAS information provisioning request may indicate the selected ACR scenario and / or provide ACI information. The WTRU can receive an EAS information provisioning response indicating that the provisioned information has been accepted by the EES. Provided the selected ACR scenario requests ACR discovery in the EEC and / or the ACI demonstrates the ability to perform ACR with the cloud, the WTRU may include information about the cloud server and / or include one or more conditions for migration to the cloud (e.g., ACR discovery conditions). The WTRU can initiate ACR discovery in the EEC. The detection criteria may include detecting that an ACR is requested based on one or more conditions and / or triggers provided in the ACI. With the ACR condition detected, the WTRU can evaluate whether an ACR to the cloud is requested. For example, the WTRU may detect whether a target EAS is available and / or evaluate one or more cloud migration rules provided in the ACI.

[0143] When the need for ACR is detected, for example, the WTRU can determine, based on ACI, whether an ACR to the cloud is required (e.g., whether no T-EAS is available and / or whether one or more other cloud migration rules have been triggered). The WTRU can send an ACR request to the EES indicating that a migration to the cloud is required (e.g., if one of the ACR conditions is met and / or if one or more of the triggers are received or identified). When a cloud migration rule is triggered and / or the ACR conditions are met, the WTRU can send an ACR request to the EES. The ACR request may indicate that a migration to the cloud is required. Furthermore, or alternatively, selected ACR scenarios may require ACR detection in the EES and / or EAS.

[0144] EEC, EES, and / or EAS can use ACI for ACR scenario configuration. ACI can be used during ACR discovery and / or ACR execution to enable application context migration between edge and cloud application servers. WTRU can use ACI to perform ACR discovery and / or execution. After ACI provisioning, for example, EEC, EES, and / or EAS can have enough information to configure ACR discovery triggers to initiate ACR to the cloud, and EEC, EES, and EAS also have enough information to determine the actions required during ACR execution to migrate application context between edge and cloud application servers.

[0145] Figure 7 shows an exemplary ACR discovery, ACR execution, and / or ACR scenario reselection 700 using ACI. For example, one or more responsibilities may be distributed between the application layer 702 and the EEC, EES, and / or EAS 704 for configuring, discovering, and / or executing ACR for the cloud, and / or ACR scenario reselection using ACI.

[0146] In 720, the application layer 702 may provision CRIs in the EEC and / or EES. CRIs may be associated with the application context. Furthermore, or otherwise, in 720, CRIs may be pre-provisioned in the EEC and / or EAS. For example, the EEC can obtain CRIs associated with the application context. The EEC and / or EES may select the EAS and / or one or more ACR scenarios for a user session. The EEC and / or EAS may derive ACIs from CRIs and / or distribute ACIs to one or more ACR discovery entities (e.g., EEC, EES, and / or EAS) and / or ACR execution entities (e.g., EEC, EES, and / or EAS).

[0147] In 722, one or more ACR detection entities 704 may receive an ACI from the EEC and / or EES. The ACI may include a CRI indicating CAS information, application layer capabilities, and / or application layer requirements. The CAS information may include an IP address, FQDN, URI, DNN, DNAI, and / or SNSSAI for reaching the CAS. In 724, one or more ACR detection entities 704 may use the ACI to configure ACR detection and / or ACR execution rules. One or more ACR detection entities 704 (e.g., the EEC, EES, and / or EAS) may use the ACI to determine whether a user session supports ACR to the CAS. One or more configured detection triggers may include triggers from ACR detection criteria in the ACI. For example, an ACR detection criterion might require that the EEC and / or EES monitor the WTRU location and / or trigger an application context migration to the CAS if the WTRU moves to a location where CAS connectivity is preferable and / or edge connectivity is unacceptable for the application. For example, the detection criterion might require that one or more ACR detection entities trigger an application context migration to the CAS based on one or more SLA thresholds, such as reaching an edge service KPI and / or edge usage limit.

[0148] In 726, one or more ACR detection entities 704 can detect an ACR request in accordance with ACI detection triggers configured for ACR with the cloud and / or decide to proceed with an ACR execution. For example, one or more ACR detection entities 704 can determine that one or more of the ACI detection triggers may be triggered. For example, here, a change in the location of a WTRU (e.g., EEC) may trigger a need to modify the EAS.

[0149] In 728, one or more ACR execution entities may perform one or more EAS discovery procedures and / or fail to find a T-EAS instance available for the user session. For example, in 728, a WTRU (e.g., an EEC) may perform an EAS discovery procedure for a user session. For example, a WTRU may navigate to a location where no target EDN, EES, and / or EAS exist that meet the user session requirements.

[0150] If ACR is triggered using ACR discovery criteria from ACI, for example, the ACR run configuration from ACI may require that the EAS discovery procedure be skipped (e.g., entirely) and / or that the T-EAS obtained from EAS discovery be ignored. For example, if the ACR discovery configuration from ACI indicates that a cloud relocation is requested within a specified service area, for example, a WTRU entering this service area may trigger an ACR run for a user session, and / or the ACR run configuration from ACI may require that the ACR run entity skip T-EAS discovery and / or (e.g., immediately) proceed with the ACR to the cloud.

[0151] A WTRU (e.g., an EEC) may determine, based on the EAS discovery procedure, that there are no available target EAS (T-EAS) instances for the user session. For example, a WTRU may determine that there are no available T-EAS instances for the user session based on one or more of the following: an ACR trigger in the ACI, or the WTRU moving to a location where the T-EAS instance does not meet the requirements associated with the user session. If EAS discovery does not return any available T-EAS instances, and / or the user session and / or the triggered ACR scenario do not support application context migration to the CAS, the ACR scenario execution may terminate and / or start an ACR cleanup. One or more ACR execution entities may use their provisioned CRI capabilities to determine whether the user session supports context migration to the CAS.

[0152] In 730, the EEC, EES, and / or EAS can obtain one or more CAS details (e.g., CAS IP address, DNN, and / or DNAI) to establish connectivity with the CAS. CAS details can be obtained using the ACI. CAS endpoint information may be included in the ACI and / or may include the EEC, EES, and / or EAS to obtain CAS endpoint information by performing endpoint resolution procedures. The EEC, EES, and / or EAS can use the CAS resolution mode from the ACI to determine whether the CAS endpoint information can be resolved by the EEC, EES, and / or EAS (e.g., respectively) and / or by the application layer. When CAS endpoint resolution is performed by the EEC, EES, and / or EAS, for example, the EEC, EES, and / or EAS can perform DNS resolution using the CAS FQDN and / or URI from the CAS information in the ACI. For example, the EEC can perform DNS resolution for the CAS based on the ACI. If CAS endpoint resolution is configured to be performed at the application layer, for example, the EEC, EES, and / or EAS can notify an application that CAS resolution is included at the application layer by calling an endpoint provided by an application that may be subscribed to the EEC, EES, and / or EAS. The notification may include CAS endpoint information to be resolved and / or ACI information (e.g., any) for the user session to migrate to the cloud. The application can provide this information to the EEC, EES, and / or EAS by resolving the CAS endpoint information and / or by using one or more CRI provisioning steps in the notification response. Furthermore, or alternatively, the application may decide that a different CAS endpoint may be used (e.g., instead).

[0153] When the selected target is CAS, for example, the selecting entity (e.g., EEC, EES, and / or EAS) can inform one or more other ACR execution entities about a decision to migrate the application context to CAS. This can be achieved using one or more (e.g., enhanced) ACR procedures that include a CAS profile. The CAS profile may include CAS information and / or may be similar to an EAS profile that has an indication that the profile is for CAS. For example, the CAS profile may be included in a target information notification sent from S-EES to EEC. For example, the CAS profile may be included in a selected target EAS declaration request sent from S-EAS to EES.

[0154] In 732, an ACR execution may migrate a user session context between the edge and one or more cloud application servers based, for example, on the ACR execution configuration and / or CAS information available in the ACI. A WTRU (e.g., an application context on the EEC) can establish a connection with the CAS based on the ACI. The WTRU (e.g., the EEC) can initiate the migration of the user session context from the EAS to the CAS based on the ACI. Once the migration is complete, in 734, for example, one or more ACR scenario cleanup procedures may be executed. During ACR cleanup, the EEC, EES, and / or EAS 704 may determine that one or more (e.g., specific) procedures may be skipped if the ACR target is the CAS (e.g., a CAS profile may be used to determine that the target is the CAS).

[0155] In 736, the EEC and / or EES may be (re)evaluated to determine whether the selected ACR scenarios should be updated. One or more CRI capabilities and / or requirements may be used to determine which one or more ACR scenarios to select. One or more selected ACR scenarios may be modified and / or provisioned to the EEC, EES, and / or EAS704. For example, after migrating the application context from EAS to CAS, one or more selected ACR scenarios may be limited to, for example, ACR scenarios run in the EEC via T-EES, as these scenarios may not depend on the EES, which may not be available in the cloud environment.

Claims

1. A wireless transceiver unit (WTRU), Perform the edge application server (EAS) discovery procedure for user sessions. Based on the EAS discovery procedure described above, it is determined that there are no available target EAS (T-EAS) instances for the user session. Using Application Context Relocation (ACR) Configuration Information (ACI), it is determined whether the user session supports ACR for the Cloud Application Server (CAS). Based on the ACI, a connection with the CAS is established. Send a notification to one or more ACR entities indicating that ACR has been initiated for the CAS. Processor configured in such a way A WTRU characterized by having the following features.

2. The WTRU according to claim 1, further characterized in that the processor is configured to acquire CAS details using the ACI.

3. The WTRU according to claim 1 or 2, further characterized in that the processor is configured to initiate the transfer of the user session context from the EAS to the CAS based on the ACI.

4. The WTRU according to any one of claims 1 to 3, wherein the processor is further configured to perform DNS resolution for the CAS based on the ACI.

5. The WTRU according to any one of claims 1 to 4, wherein the processor is configured to determine that there are no T-EAS instances available for the user session based on one or more of the following: an ACR trigger in the ACI, or the WTRU moving to a location where there are no T-EAS instances that meet the requirements associated with the user session.

6. The WTRU according to any one of claims 1 to 5, characterized in that a change in the location of the WTRU triggers the need to change the EAS.

7. The WTRU according to any one of claims 1 to 6, wherein the ACI includes CAS information, application layer capabilities, or cloud relocation information (CRI) indicating application layer requirements, and the CAS information includes an Internet Protocol (IP) address, a fully qualified domain name (FQDN), a universal resource identifier (URI), a data network name (DNN), a data network access identifier (DNAI), or single network slice selection assistance information (S-NSSAI) for reaching the CAS.

8. A method performed by a wireless transceiver unit (WTRU), Perform the Edge Application Server (EAS) discovery procedure for user sessions, Based on the EAS discovery procedure described above, it is determined that there are no available target EAS (T-EAS) instances for the user session. Using Application Context Relocation (ACR) Configuration Information (ACI), it is determined whether the user session supports ACR for the Cloud Application Server (CAS), To establish a connection with the CAS based on ACI, Sending a notification to one or more ACR entities indicating that ACR has been initiated for the CAS. A method characterized by comprising:

9. The method according to the 8th, further comprising obtaining CAS details using the ACI.

10. The method according to 8 or 9, further comprising initiating the transfer of the user session context from the EAS to the CAS based on the ACI.

11. The method according to any one of claims 8 to 10, further comprising performing DNS resolution for the CAS based on the ACI.

12. The method according to any one of claims 8 to 11, further comprising determining that there are no T-EAS instances available for the user session based on one or more of the following: an ACR trigger in the ACI, or the WTRU moving to a location where there are no T-EAS instances that meet the requirements associated with the user session.

13. The method according to any one of claims 8 to 12, characterized in that a change in the location of the WTRU triggers the need to change the EAS.

14. The method according to any one of claims 8 to 12, wherein the ACI includes CAS information, application layer capabilities, or cloud relocation information (CRI) indicating application layer requirements, and the CAS information includes an Internet Protocol (IP) address, a fully qualified domain name (FQDN), a universal resource identifier (URI), a data network name (DNN), a data network access identifier (DNAI), or single network slice selection assistance information (S-NSSAI) for reaching the CAS.

15. Network node, The Wireless Transceiver Unit (WTRU) receives Application Context Relocation (ACR) configuration information (ACI) associated with the target cloud application server (CAS). Perform the edge application server (EAS) discovery procedure for user sessions. Based on the EAS discovery procedure described above, it is determined that there are no available target EAS (T-EAS) instances for the user session. Determine whether the user session supports ACR for the target CAS, Using the ACI, identify the CAS details for establishing a connection with the target's CAS. Send a notification to one or more ACR entities indicating that ACR is required for the target CAS. Processor configured in such a way A network node characterized by having the following features.

16. The network node according to claim 15, wherein the processor is further configured to transfer the user session context from the EAS to the target CAS based on the CAS details.

17. The network node according to claim 15 or 16, wherein the processor is further configured to perform DNS resolution for the target CAS based on the ACI.

18. The network node according to any one of claims 15 to 17, wherein the processor is configured to determine that there are no T-EAS instances available for the user session based on one or more of the following: an ACR trigger in the ACI, or the WTRU moving to a location where there are no T-EAS instances that meet the requirements associated with the user session.

19. The network node according to any one of claims 15 to 18, characterized in that a change in the location of the WTRU triggers the need to change the EAS.

20. The network node according to any one of claims 15 to 19, wherein the ACI includes CAS information, application layer capabilities, or cloud relocation information (CRI) indicating application layer requirements, and the CAS information includes an Internet Protocol (IP) address, a fully qualified domain name (FQDN), a universal resource identifier (URI), a data network name (DNN), a data network access identifier (DNAI), or single network slice selection assistance information (S-NSSAI) for reaching the CAS.

Images