Wireless transmit / receive unit (WTRU) and method performed by WTRU

Abstract

The disclosure relates to a wireless transmit / receive unit (WTRU) and a method performed by the WTRU. A WTRU, the WTRU comprising: a processor configured to: receive configuration information associated with one or more of a first network node, a second network node, and an application client (AC); determining a first network node and a second network node using the configuration information, where the second network node provides a service, and where the second network node is associated with the first network node; determining one or more application context relocation (ACR) procedures for providing continuity for the service based on the WTRU capability, the first network node capability, and the second network node capability; transmitting a selection request message to the first network node, wherein the selection request message indicates an identifier of the second network node, an edge enabler client (EEC) identifier associated with the WTRU, and the determined one or more ACR procedures; and receiving, from the first network node, a selection response message indicating the request processing status result.

Description

[0001] This application is a divisional application of a patent application for invention titled "ACR Selection and Coordination" with application number 202380034374.2, filing date March 17, 2023.

[0002] Cross - reference to related applications

[0003] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 321,329, filed on March 18, 2022, the content of which is hereby incorporated by reference in its entirety. Technical field

[0004] The present invention generally relates to the field of wireless communication. More specifically, the present invention relates to ACR selection and coordination. Background art

[0005] Mobile communication using wireless communication continues to evolve. The fifth - generation mobile communication radio access technology (RAT) can be referred to as 5G New Radio (NR). Previous (legacy) mobile communication RATs can be, for example, the fourth - generation (4G) Long - Term Evolution (LTE). Summary of the invention

[0006] Embodiments of the present invention may include a wireless transmit / receive unit (WTRU) comprising: a processor configured to: receive configuration information associated with one or more of a first network node, a second network node, and an application client (AC); use the configuration information to determine the first network node and the second network node, wherein the second network node provides a service and wherein the second network node is associated with the first network node; determine one or more application context relocation (ACR) procedures for providing continuity for the service based on WTRU capabilities, first network node capabilities, and second network node capabilities; transmit a selection request message to the first network node, wherein the selection request message indicates an identifier of the second network node, an edge - enabled client (EEC) identifier associated with the WTRU, and the determined one or more ACR procedures; and receive a selection response message from the first network node indicating a result of the request - handling status.

[0007] Another embodiment of the present invention may include a method performed by a wireless transmit / receive unit (WTRU), the method comprising: receiving configuration information associated with one or more of a first network node, a second network node, and an application client (AC); using the configuration information to determine the first network node and the second network node, wherein the second network node provides a service, and wherein the second network node is associated with the first network node; determining one or more application context relocation (ACR) procedures for providing continuity for the service based on WTRU capabilities, first network node capabilities, and second network node capabilities; transmitting a selection request message to the first network node, wherein the selection request message indicates an identifier of the second network node, an edge enablement client (EEC) identifier, and the determined one or more ACR procedures; and receiving a selection response message from the first network node indicating a request processing status. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0009] Figure 1B is illustrative of an example wireless transmit / receive unit (WTRU) that may be used within the Figure 1A illustrated communication system according to an embodiment.

[0010] Figure 1C is illustrative of an example radio access network (RAN) and an example core network (CN) that may be used within the Figure 1A illustrated communication system according to an embodiment.

[0011] Figure 1D is illustrative of another example RAN and another example CN that may be used within the Figure 1A illustrated communication system according to an embodiment.

[0012] Figure 2 shows an example of an SA6 architecture for enabling edge applications.

[0013] Figure 3 shows an example of a brief overview of application context relocation (ACR).

[0014] Figure 4 shows an example of a brief overview of application context relocation with ACR selection and ACR coordination functions.

[0015] Figure 5 shows an example of application context migration with an application context transfer (ACT) authorization token.

[0016] Figure 6 Shows an example of the ACR selection function performed by an Edge Enablement Server (EES).

[0017] Figure 7 Shows an example of the ACR selection function performed by an Edge Enablement Client (EEC).

[0018] Figure 8 Shows an example of the ACR coordination function performed by the EES.

[0019] Figure 9 Shows an example of the ACR coordination function performed by the EEC.

[0020] Figure 10 Shows an example of the ACR Selection Function (ASF) and the ACR Coordination Function (ACF) used in a combined manner. Detailed Description

[0021] Figure 1A Is a diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 can be a multi-access system that provides content such as voice, data, video, messages, broadcasts, etc. to multiple wireless users. The communication system 100 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 can employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single-Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT-Spread OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0022] As Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) can be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular telephones, personal digital assistants (PDAs), smartphones, laptop computers, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain environment), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. Any one of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0023] The communication system 100 may further include base station 114a and / or base station 114b. Each of the base stations 114a, 114b can be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b can be transceiver base stations (BTSs), Node Bs, evolved Node Bs, home Node Bs, home evolved Node Bs, gNBs, NR Node Bs, site controllers, access points (APs), wireless routers, etc. Although the base stations 114a, 114b are each depicted as a single element, it should be understood that the base stations 114a, 114b can include any number of interconnected base stations and / or network elements.

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

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

[0026] More specifically, as noted above, communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base station 114a in RAN 104 / 113 and WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117. 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).

[0027] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may use long term evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-A Pro to establish an air interface 116.

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

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

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

[0031] Figure 1AThe base station 114b therein may be, for example, a wireless router, a home Node B, a home evolved Node B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area such as a business premise, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As Figure 1A shown, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

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

[0033] CN 106 / 115 can also be used as a gateway for WTRU 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 can include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 can include a global system of interconnected computer networks and devices that use 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. The network 112 can include a wired communication network and / or a wireless communication network owned and / or operated by other service providers. For example, the network 112 can include another CN connected to one or more RANs, and the one or more RANs can employ the same RAT or a different RAT as the RAN 104 / 113.

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

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

[0036] The processor 118 can 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 decoding, 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 the processor 118 and the transceiver 120 are depicted as separate components, it should be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

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

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

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

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

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

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

[0043] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripheral devices 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, Modules, FM radio units, digital music players, media players, video game player modules, Internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. The peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geographical location sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

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

[0045] Figure 1C Is a system diagram illustrating the RAN 104 and CN 106 according to an embodiment. As noted above, the RAN 104 may communicate with the WTRU 102a, 102b, 102c via the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the CN 106.

[0046] The RAN 104 may include evolved Node Bs 160a, 160b, 160c, but it should be understood that the RAN 104 may include any number of evolved Node Bs while remaining consistent with the embodiment. Each of the evolved Node Bs 160a, 160b, 160c may include one or more transceivers for communicating with the WTRU 102a, 102b, 102c via the air interface 116. In one embodiment, the evolved Node Bs 160a, 160b, 160c may implement MIMO technology. Thus, the evolved Node B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

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

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

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

[0050] The SGW 164 may be connected to each of the evolved Node Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as anchoring the user plane during handover between evolved Node Bs, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

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

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

[0053] Although the WTRU is described as a wireless terminal in Figures 1A to 1D it is contemplated that in some representative embodiments, such a terminal can (e.g., temporarily or permanently) use a wired communication interface with a communication network.

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

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

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

[0057] High Throughput (HT) STAs can communicate using a 40 MHz wide channel, e.g., by combining the primary 20 MHz channel with an adjacent or non - adjacent 20 MHz channel to form a 40 MHz wide channel.

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

[0059] 802.11af and 802.11ah support operation modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, the channel operation bandwidth and carriers are reduced in 802.11af and 802.11ah. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter type control / machine type communication, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) certain bandwidths and / or limited bandwidths. MTC devices may include a battery with a battery life higher than a threshold (e.g., to maintain a very long battery life).

[0060] A WLAN system that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) includes a channel that can be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operation bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or restricted by the STA (which supports the minimum bandwidth operation mode) from all STAs operating in the BSS. In the example of 802.11ah, for an STA that supports (e.g., only supports) the 1 MHz mode (e.g., an MTC type device), the primary channel may be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because an STA (only supporting the 1 MHz operation mode) is transmitting to the AP, the entire available frequency band may be considered busy even if most of the frequency bands remain idle and may be available.

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

[0062] Figure 1D FIG. is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As noted above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, 102c via air interface 116. RAN 113 may also communicate with CN 115.

[0063] The RAN 113 may include gNBs 180a, 180b, 180c, but it should be understood that, while remaining consistent with the embodiments, the RAN 113 may include any number of gNBs. Each of the gNBs 180a, 180b, 180c may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c via the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to the WTRU 102a and / or receive wireless signals from the WTRU. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, the WTRU 102a may receive a coordinated transmission from the gNB 180a and the gNB 180b (and / or gNB 180c).

[0064] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a parameter set that can be extended. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of various or extendable lengths (e.g., containing different numbers of OFDM symbols and / or having an absolute time length that varies continuously).

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

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

[0067] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possibly data networks (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0068] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support for network slicing (e.g., handling different PDU sessions with different requirements), selection of a specific SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize CN support for the WTRU 102a, 102b, 102c based on the type of service utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases (such as services relying on ultra-reliable low-latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc.). The AMF 162 may provide control plane functions for handover between the RAN 113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0069] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0070] UPF 184a and 184b can be connected to one or more gNBs among gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface. The one or more gNBs can provide access to a packet-switched network (such as the Internet 110) for WTRU 102a, 102b, and 102c to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions, such as routing and forwarding packets, implementing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0071] CN 115 can facilitate communication with other networks. For example, CN 115 can include an IP gateway (such as an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 115 and the PSTN 108 or can communicate with the IP gateway. In addition, CN 115 can provide access to other networks 112 for WTRU 102a, 102b, and 102c. The other networks can include other wired networks and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU 102a, 102b, and 102c can be connected to DN 185a and 185b via UPF 184a and 184b through the N3 interface to UPF 184a and 184b and the N6 interface between UPF 184a and 184b and the local data network (DN) 185a and 185b.

[0072] In view of Figures 1A to 1D and Figures 1A to 1D In view of the corresponding descriptions, one or more or all of the functions described herein with reference to one or more of the following can be performed by one or more emulation devices (not shown): WTRU 102a-d, base stations 114a-b, evolved Node Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DNs 185a-b, and / or any other devices described herein. The emulation device(s) can be one or more devices configured to mimic one or more or all of the functions described herein. For example, the emulation device(s) can be used to test other devices and / or simulate network and / or WTRU functions.

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

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

[0075] References to timers herein can refer to time, time periods, tracking time, tracking time periods, etc. References to timer expiration herein can refer to determining that a time has occurred or that a time period has expired.

[0076] The application layer can be used to support edge services. As disclosed herein, an application layer can be provided.

[0077] An architecture can be provided for enabling one or more edge applications. Figure 2 An example of the SA6 architecture for enabling edge applications is shown.

[0078] The components of the SA6 architecture can be described with respect to Table 1.

[0079] Table 1 - SA6 Edge Enablement Layer (EEL) Entities

[0080]

[0081]

[0082] A data network (DN) and / or a local area data network (LADN) can be provided. The system can inform the WTRU of the available DNs and can provide information regarding the capabilities of the DNs. A LADN information element (IE) can be provided. The LADN information IE can be a mechanism by which the network can convey to the WTRU a data network name (DNN) and the geographical area in which such DNN can be accessed.

[0083] LADN information (e.g., LADN service area information and / or LADN DNN) may be provided by the AMF to the WTRU during a registration procedure or a WTRU configuration update procedure. For a LADN DNN configured in the AMF (e.g., each LADN DNN), the corresponding LADN service area information may include a set of tracking areas that belong to the registration area assigned by the AMF to the WTRU (e.g., the intersection of the LADN service area and the assigned registration area).

[0084] When the WTRU indicates to the AMF that it is capable of receiving LADN information via a registration request, the LADN information may be transmitted by the AMF to the WTRU.

[0085] Service continuity may be provided. For example, the embodiments disclosed herein may provide service continuity.

[0086] If the WTRU moves to a certain location (e.g., a new location), different EASs and / or EDNs may be more suitable for serving the AC in the WTRU. Such a mobility transition may result in replacing the EAS in the source EDN (S-EAS) with the EAS in the target EDN (T-EAS).

[0087] Replacing the S-EAS with the T-EAS may involve a procedure called Application Context Relocation (ACR). Five ACR procedures may be defined that follow the Figure 3 brief flow shown.

[0088] ARC may be provided. Figure 3 An example of a brief overview of ACR is shown.

[0089] The ACR detection and / or ACR decision phase may be performed by different entities according to the ACR procedures. Table 2 may present an overview of the detection entities and / or decision entities. As shown in the table, there may be multiple detection entities and / or decision entities at the same time. In other words, two or more different entities may independently detect that ACR is being used and may independently decide which procedure can be executed.

[0090] Table 2 - ACR Detection and Decision Overview

[0091]

[0092] The ACR execution phase may vary according to the ACR procedures. During the ACR execution phase, the EEL entities may exchange multiple messages shown in Table 3.

[0093] For a given AC and EAS pair, ACR procedures (e.g., two or more ACR procedures) may not be able to be executed concurrently because the order and sequence of the messages may be incompatible. An ACR (e.g., a single ACR procedure) may be executed to make the ACR successful.

[0094] Table 3 - ACR Execution Overview

[0095]

[0096] ACR post-processing may be similar for ACR procedures (e.g., all ACR procedures), as shown in Table 4.

[0097] Table 4 - ACR Post-Processing Overview

[0098]

[0099] One or more ACR procedures may be provided.

[0100] Table 5 may illustrate that the ACR procedure of "ACR performed by the EEC via the T-EES" (e.g., only the ACR procedure of "ACR performed by the EEC via the T-EES") may succeed in the case triggered by the movement of the WTRU into or out of the service area of a data network (e.g., DN or LADN). Based on the fact that the EEC can no longer communicate with the S-EES that may reside in the source LADN, when the WTRU moves out of the service area of the source LADN, other ACR procedures (e.g., all other ACR procedures) may fail.

[0101] Table 5 - Failure Cases of ACR without SCP

[0102]

[0103]

[0104] Service continuity planning (SCP) issues may be provided.

[0105] SCP may be a variant of the ACR procedure (e.g., each ACR procedure), which is designed to prepare the target EAS before the WTRU mobility involves ACR.

[0106] Service continuity planning may be defined as an edge enabler layer value-added feature that provides support for seamless service continuity, for example, when information about the planned, scheduled, and / or expected behavior is available at the EES or provided by the EEC. In service continuity planning, the application context may be replicated and / or transferred from the S-EAS to the T-EAS before the WTRU moves to the expected location.

[0107] Table 6 illustrates that ACR procedures (e.g., all ACR procedures) may fail during ACR execution and / or ACR clearing. In the case of a planned WTRU movement triggered by the inability of the EEC to communicate with the T-EES residing in the target LADN and being moved into the service area of the target LADN, ACR execution may fail. In the case of a WTRU movement triggered by the EEC no longer being able to communicate with the S-EES that may reside in the source LADN and moving out of the service area of the source LADN, ACR clearing may fail.

[0108] Table 6 - Failure Cases of ACR with SCP

[0109]

[0110]

[0111] As described herein, service continuity procedures may be provided.

[0112] ACR scenarios may not support concurrent execution. For example, if multiple ACR scenarios are used concurrently, edge enabling layer (EEL) entities (e.g., EEC, EES, and / or EAS) may detect and decide to trigger the execution of ACR procedures simultaneously. ACR procedures may not support concurrent execution, resulting in undefined behavior that may cause the service continuity of the WTRU to be unsuccessful.

[0113] In the example, using LADN use cases (e.g., all LADN use cases, such as entering or leaving), no ACR scenario can succeed. For example, a LADN may be a data network with an associated service area. The WTRU may communicate with the LADN (e.g., only when) it is inside the LADN service area. For example, an ACR scenario without an SCP may involve (e.g., require) the WTRU to communicate with the EAS / EES located in the LADN after the WTRU has left the service area, while an ACR scenario with an SCP may involve (e.g., require) the WTRU to communicate with the EAS / EES located in the LADN before the WTRU enters the service area of the LADN. Both cases may result in the failure of the ACR procedure and the unsuccessful service continuity of the WTRU.

[0114] When executing an ACR, the application context may be moved from a first entity (e.g., EES or EAS) to a second entity (e.g., EES or EAS). The security capabilities of the first entity and the second entity may be different. When selecting the ACR procedure to be executed, it may be necessary to coordinate which security procedures should be used to communicate with the second entity (e.g., the target entity), and it may be necessary to exchange security credentials (e.g., tokens, certificates, etc.) with the ACR participating entities.

[0115] If used concurrently and / or in conjunction with LADN, the ACR procedure may result in service continuity failures.

[0116] An ACR Selection Function (ASF) may be defined to select the ACR scenario to be used for service continuity. The ASF may be represented by 0, as Figure 4 shown. The output of the ASF may be a list of zero or more ACR procedures, and when multiple ACR procedures are in the list, these ACR procedures may be used to perform 1 and 2 and the selection of the ACR Coordination Function (ACF).

[0117] The list of procedures available for 1 and 2 may be referred to as the ACR-Detection-Decision list.

[0118] Multiple ACR procedures may perform 1 and 2 concurrently. Multiple ACR procedures may be used concurrently to detect that the AC and EAS may involve (e.g., require) ACR, and multiple ACR procedures may be used concurrently to decide that the AC and EAS may need ACR. As described herein, an ACR procedure (e.g., a single ACR procedure) may be allowed to proceed to the execution phase in 3.

[0119] When the ASF generates an ACR-Detection-Decision list that includes more than one ACR procedure, and when multiple ACR procedures detect and / or decide to perform ACR concurrently, a single ACR procedure may be allowed to reach the execution phase. The gating of ACR execution may be performed by the ACR Coordination Function (ACF), which may be described herein. An example of ACR selection performed by the ASF may be to inform the ACR decision entity (e.g., EEC, EES, and / or EAS) which ACR procedure may perform detection and decision. An example of ACR coordination performed by the ACF may be to allow one ACR procedure (e.g., only one ACR procedure) to reach the execution phase.

[0120] If concurrent ACR procedures are used for service continuity (e.g., multiple ACR procedures in the ACR-Detection-Decision list), the ACF may be defined to coordinate the ACR scenario execution. The ACF may be represented by 2.1, as Figure 4 shown.

[0121] Figure 4 An example showing a brief overview of application context relocation with an ACR selection function and an ACR coordination function is presented.

[0122] The ASF and / or ACF may be used for ACR, as described herein. The ASF and ACF may be used concurrently for ACR, as described herein.

[0123] The ASF can be a logical function that can be implemented in a stand-alone server or can reside in the EEC, EES, EAS, or in any other server part of the EEL or interact with the EEL.

[0124] The ACF can be a logical function that can be implemented in a stand-alone server or can reside in the EEC, EES, EAS, or in any other server part of the EEL or interact with the EEL.

[0125] The ASF can be provided.

[0126] The ACR selection function can perform one or more operations to ensure that the EEL entity is consistent in terms of the ACR procedures that will be used for the session of the AC with the EAS, where the AC resides on the WTRU and the EAS resides in the EDN (e.g., DN or LADN).

[0127] The functions of the ASF can include one or more of the following: selecting the ACR procedures that can be used for the AC and EAS pair (e.g., each AC and EAS pair) and generating an ACR-detection-decision list; selecting an ACF entity in the case where more than one ACR procedure is selected; communicating the ASF decision (e.g., the ACR-detection-decision list and / or the ACF entity) to the appropriate entity; or re-evaluating the selected ACR procedures when the selection criteria and / or inputs change.

[0128] The ACR procedures can be selected.

[0129] The ACR procedure selection can be performed by the ASF to determine the ACR-detection-decision list and the ACF entity. The procedure can result in one of the following: no ACR procedure is selected for the list, a single ACR procedure is selected for the list, or multiple ACR procedures are selected for the list.

[0130] When there is no ACR involved (e.g., not required) between the AC and its EAS counterpart or when there is no common ACR procedure supported by the involved EEL entities (e.g., AC, EEC, EES, and / or EAS), the ASF may not include an ACR procedure in the ACR-detection-decision list.

[0131] When there is a common ACR procedure (a single common ACR procedure) supported by the involved EEL entities (e.g., AC, EEC, EES, and / or EAS), the ASF may include the ACR procedure (e.g., a single ACR procedure) in the ACR-detection-decision list. In an example, if there are multiple supported common ACR procedures and if the ASF determines that it is beneficial to use the ACR procedure (e.g., a single ACR procedure), the ACR procedure (e.g., a single ACR procedure) may be included. For example, selecting the ACR procedure (e.g., a single ACR procedure) may minimize processing and / or messaging by minimizing the request for coordination (e.g., eliminating the need for coordination). For example, selecting the ACR procedure (e.g., a single ACR procedure) may avoid using an ACR procedure that may be incompatible with the source edge data network type / target edge data network type (e.g., DN and / or LADN).

[0132] When there are multiple common ACR procedures supported by the involved EEL entities (e.g., AC, EEC, EES, and / or EAS) and when the ASF determines that it is beneficial to use multiple concurrent ACR procedures, the ASF may select multiple ACR procedures. For example, it may be beneficial to select multiple ACR procedures to improve ACR detection by using multiple ACR detection entities. For example, it may be beneficial to select multiple ACR procedures to support WTRU handover, where the involved source edge data network type and / or target edge data network type (e.g., DN and / or LADN) involves the use of different ACR procedures.

[0133] The ACR procedure selection performed by the ASF may be based on the EEL participants (e.g., AC, EEC, EES, and / or EAS). The ACR capabilities may include SCP capabilities and / or the current EDN type and the surrounding EDN type (e.g., DN and / or LADN). For example, EAS service continuity support may be found in the EAS profile. EES service continuity support may be found in the EES profile. EEC service continuity support may be provided by the EEC in a registration request or an EAS discovery request, and AC service continuity support may be found in the AC profile. For example, the EDN type may be determined by the EES topology and / or geographical service area in the EES profile or the EAS topology and / or geographical service area in the EES profile.

[0134] The WTRU location (e.g., geographical and / or topological) ACR procedure selection may be based on the planned route and / or trajectory of the EEC. For example, if the EEC is hosted in a vehicle or a drone, the EEC may provide the planned route and / or trajectory to the ASF. The ASF may use this information to determine which ACR procedures may be supported at the future location of the EEC.

[0135] The ACR procedure selection can be based on the data analysis information of the WTRU hosting the EEC obtained from the Network Data Analytics Function (NWDAF). For example, the ASF can use the WTRU mobility analysis information to determine which ACR procedures can be supported at the future location of the EEC. The ASF can invoke the Nnwdaf_AnalyticsSubscription service or the Nnwdaf_AnalyticsInfo service to obtain the WTRU mobility statistics and / or predictions.

[0136] The ASF can assign a globally unique identifier to the entries (e.g., each entry) in the ACR-detection-decision list to identify the selected ACR procedure (e.g., each ACR procedure). This ACR identifier can be used for ACR management operations such as re-evaluating or terminating the ACR. The ACR identifier can be used when the active ACR (e.g., detection and decision) reports the ACR decision to the ACF.

[0137] For example, the ASF can assign a valid area and / or location to the ACR entries (e.g., each ACR entry) in the ACR-detection-decision list to narrow down the scope of the ACR procedure. The ACR detection and / or decision entity can use this valid area based on the WTRU location to decide when to start and / or stop the ACR detection and / or decision. The WTRU location can be a geographical location (e.g., geographical coordinates and / or city address) or a topological location in the network (e.g., cell identifier, Tracking Area Identifier (TAI) or Public Land Mobile Network (PLMN)). This service area capability can allow the ASF to perform ACR planning based on the WTRU location. For example, when the WTRU is in a location with a neighboring LADN, the ASF can select a specific ACR procedure compatible with the LADN, otherwise, the ASF can select a different ACR procedure. For example, when neighboring EAS / EES support different ACR procedures in the neighboring EDN, the ASF can perform ACR planning.

[0138] The ACF entity can be selected.

[0139] The ACF entity can be a node in the system and / or can be dynamically selected by the ASF. When one or more parties (e.g., each party) know the ACF, the ASF may not request to select the ACF (e.g., the ASF may not need to select the ACF).

[0140] When the ACF is dynamically selected by the ASF, the ACF entity selection can result in one of the following outcomes: no ACF entity is selected or one ACF entity is selected.

[0141] If ACR is not used or if an ACR procedure is selected (e.g., a single ACR procedure) (e.g., the ACR-detection-decision list includes 0 entries or 1 entry), the ASF may not select an ACF entity.

[0142] If the ACR-detection-decision list includes multiple ACR procedures that will be used concurrently, the ASF may select an ACF entity (e.g., one ACF entity).

[0143] The output of the ACF selection procedure may be the identifier of the ACF (e.g., the FQDN or IP address of the ACF).

[0144] A communication ASF decision may be provided.

[0145] The ACR procedure selection may be communicated to the ACR detection and decision entity. The ACR detection and decision entity may be the EEC, EES, and / or EAS. The ASF may provide the ACR-detection-decision list to the EEC, EES, and / or EAS.

[0146] For the ACR detection entity, based on receiving the ACR-detection-decision list, the ACR detection entity may initiate the ACR detection process when (e.g., only when) the selected ACR procedure authorizes the ACR detection process. If multiple ACR procedures are selected, the ACR detection entity may initiate the ACR detection process for the selected ACR procedures that authorize the ACR detection process (e.g., all selected ACR procedures). If ACR is not used or if the selected ACR procedure does not require the participation of the ACR detection entity, the detection process may not be initiated.

[0147] For the ACR decision entity, based on receiving the ACR-detection-decision list, the ACR decision entity may initiate the ACR decision process when (e.g., only when) the selected ACR procedure authorizes the ACR decision process (e.g., waiting for detection). If multiple ACR procedures are selected, the ACR decision entity may use the selected ACF entity. If ACR is not used or if the selected ACR procedure does not require the participation of the ACR decision entity, the decision process may not be initiated.

[0148] The ACF entity selection may be communicated to the ACR decision entity. The ACR decision entity may be the EEC, EES, and / or EAS.

[0149] For the ACR decision entity, based on the received ACF entity selection, the ACR decision entity can utilize the selected ACF entity to configure its ACR decision processing. If an ACF entity is selected, the ACR decision entity can inform the ACF entity of its ACR decision and may not continue to trigger the ACR execution phase until the ACR decision entity receives confirmation from the ACR coordination entity that it can continue. If an ACF entity is not selected, the ACR decision entity can continue to trigger the ACR execution phase.

[0150] The ACR-detection-decision list and / or the ACR coordination entity can be informed to the AC.

[0151] A re-evaluation of the selected ACR procedure can be provided.

[0152] For example, if the WTRU moves in the network, if the neighboring EDN ACR capabilities change, if the WTRU planned route changes, or if the ACR capabilities of the EEL participants change, the ASF can periodically re-evaluate (e.g., periodically re-evaluation is required) the ACR-detection-decision list.

[0153] When the ASF performs a re-evaluation, the ASF can generate an ACR-detection-decision list (e.g., a new ACR-detection-decision list) and can select an ACF entity in the same manner as described herein. The re-evaluated list can be the same as the initial list, can be a partially modified list, or can include a complete set of entries (e.g., new entries). The unchanged list entries can be entries with pre-existing globally unique identifiers, and the entries (e.g., new entries) can be entries with globally unique identifiers (e.g., new globally unique identifiers).

[0154] When the ASF conveys the re-evaluated ACR-detection-decision list, the recipient can react based on the received ACR-detection-decision list. For example, an ACR procedure whose identifier has been removed from the list can be stopped. An ACR procedure that has been added (e.g., a new ACR procedure) can be started. The existing ACR procedure identifier assigned to an ACR procedure (e.g., a new ACR procedure) can cause the ACR procedure to stop and another ACR procedure to start.

[0155] An ACR coordination function (ACF) can be provided.

[0156] When multiple ACR procedures have been selected for a session of an AC residing on a WTRU with an EAS residing in an EDN (e.g., DN or LADN), the ACR coordination function can perform one or more operations to prioritize the execution of the ACR procedures.

[0157] The function of the ACF can be to select an ACR procedure to execute when an ACR has been detected and / or determined for an AC and EAS pair.

[0158] Coordination of the ACR procedure can be provided.

[0159] The ACR procedure coordination performed by the ACF can result in one of the following: allowing the execution of the ACR or not allowing the execution of the ACR.

[0160] When another ACR is to be performed for a given AC and EAS pair, the ACF can block the execution of the ACR procedure. For example, when the ACR procedure (e.g., two or more ACR procedures) concurrently detects and determines that an ACR is needed, the ACF can decide to allow the execution of one of the ACR procedures and can reject the execution of the other ACR procedure(s). If the ACF determines that the ACR procedure will fail due to, for example, an unsupported WTRU movement or a planned movement as described herein, the ACF can block the execution of the ACR procedure.

[0161] When an ACR procedure is the first ACR procedure to detect and / or determine that an ACR is needed, the ACF can allow the execution of that ACR procedure. For example, if a single ACR procedure detects and / or determines the triggering of ACR execution for an AC and EAS pair, the ACF can allow the execution of that ACR procedure. In the case of using multiple ACRs concurrently, the ACF can decide to allow the execution of one ACR procedure and reject the other ACR procedures.

[0162] When reporting concurrent ACR decisions, the ACF can coordinate ACR execution based on different conditions. For example, the ACF can allow ACR execution for the first reported ACR. In this case, the ACR decision report timestamp can be used to determine the ACR procedure for ACR execution. For example, the ACF can allow ACR execution based on a preferred ACR list. In this case, the ACR procedure priority in the preferred ACR list can be used to determine the ACR procedure for ACR execution. For example, the ACF can allow ACR execution based on the source EDN type or the target EDN type (e.g., DN and / or LADN). In this case, the source EDN type or the target EDN type can be obtained from the WTRU registration information, from the EAS profile, or from the EES profile. For example, the ACF can allow ACR execution based on the WTRU location. In this case, the WTRU location can be obtained from the WTRU or from the network.

[0163] The ACR procedures performed by the ACF coordinate the ACR and SCP capabilities of EEL participants (e.g., AC, EEC, EES, and / or EAS), the source EDN type (e.g., DN or LADN), the target EDN type (e.g., DN or LADN), the WTRU location, the detection trigger (e.g., WTRU movement or planned WTRU movement), and / or the identifier of the ACR procedure that reports ACR detections and / or decisions to the ACF.

[0164] Security may be provided for the ACR.

[0165] As described herein, the ACR capabilities of entities (e.g., AC, EEC, EES, and / or EAS) may be provided to the ASF. The ACR capabilities may include a list of ACR procedures performed by the entity. The ACR capabilities may include a list of security procedures supported by the entity.

[0166] In an example, the EEC may discover the T-EAS and transmit an ACR coordination request. The ACR coordination request may indicate the identity of the T-EAS. The ACR coordination request may include the ACR capabilities of the EEC. The EES may receive the ACR coordination request and use the ACR capabilities of the EEC and the T-EAS to determine an ACR coordination response. The EES may have been configured with the ACR capabilities of the T-EAS. The EES may transmit the ACR coordination response to the EEC. The ACR coordination response may notify the EEC that an ACR procedure has been selected for execution. The ACR coordination response may trigger the entity to establish a secure connection with the target entity (e.g., T-EAS or T-EES). The ACR coordination response may provide the entity with information about the target entity. Information about the target entity may include the identity of the target entity, the security credentials that may be used when establishing security with the target entity, an indication of which procedures are supported by the target entity, and / or an indication of which security procedures may be used to establish security with the target entity. Transmitting the security credentials in the ACR coordination response may cause the EEC not to perform (e.g., not be required to perform) a second procedure to obtain security credentials from the ECS.

[0167] After determining the ACR procedure, a security procedure can be performed between entities (e.g., EES and / or EAS) in the source EDN and entities (e.g., EES and / or EAS) in the target EDN to protect the application context transfer from S-EAS to T-EAS. A security procedure can be performed between the AC and / or EEC to T-EES and T-EAS. Depending on the trust domains of the source EDN and the target EDN and the deployment scenario, the security procedure can determine whether the WTRU uses (e.g.) authentication (e.g., new authentication) and authorization in a service area (e.g., a new service area) or whether AKMA / Generic Bootstrapping Architecture (GBA) is used to re-bootstrap the security credentials to be used in the target EDN. The security procedure can generate an authorization for the AC and / or a token for the EEC to access the T-EAS.

[0168] If the ECS does not change during the ACR procedure, the EEC can establish a secure protection with the ECS via TLS with credentials (e.g., certificate-based, AKMA, and / or GBA-based) and can receive an authorization token to be used with the EES in the target EDN. Depending on the security (e.g., security requirements), WTRU authentication (e.g., new WTRU authentication) can be performed with the target EDN, and an AKMA / GBA procedure (e.g., new AKMA / GBA procedure) can be performed. If WTRU authentication (e.g., new WTRU authentication) is not used (e.g., not required), the WTRU can use the existing AKMA / GBA credentials with the ECS and / or EES in the target EDN to establish a secure connection and receive an authorization token (e.g., new authorization token) to be used with the target EES.

[0169] Figure 5 An example of application context migration with an ACT authorization token is shown.

[0170] As Figure 5 shown, the procedure for application context migration can be used for S-EAS to T-EAS (e.g., when needed, S-EES to T-EES) and one or more of the following procedures discussed below.

[0171] At 1, the EEC can establish a secure connection with the source ECS, which can be set up based on TLS with an AKMA or GBA pre-shared key. Depending on the configuration, when the AC receives an ACR selection message, re-authentication and / or AKMA / GBA can be used (e.g., required).

[0172] At 2, the AC can receive an ACR selection message, and this message can trigger the EEC to start the ACT. The AC can decide to initiate an application context migration from the S-EAS to the T-EAS. The EEC can initiate a service provisioning request to the ECS to request a token (e.g., an ACT authorization token) for T-EES authorization and authorization for the application context migration from the S-EAS to the T-EAS. The token may have been received via the ACR selection message.

[0173] At 3, the ECS can process the request and generate the requested token after authorization by the EEC. The ACT authorization token can include one or more of the following: AC ID, S-EAS ID, T-EAS ID, ECS ID, token validity time, authorized actions, etc. The ECS can transmit the token and the ACT authorization token to the AC / EEC. If the ECS changes during the ACR, the AC / EEC can establish a TLS with the target ECS, and the AC / EEC can receive an authorization token to access the T-EES / T-EAS and establish a TLS with the T-EES / T-EAS.

[0174] At 5, the AC / EEC can transmit an application context migration request to the T-EAS, and this request can include a T-EES access authorization token and an ACT authorization token. At 6, in the example, the T-EAS and the S-EAS can establish a secure connection (e.g., a TLS connection). At 7, the T-EAS can authorize the AC using the EAS access token and can transmit the ACT authorization token to the S-EAS. At 8, based on the ACT request received from the T-EAS, the S-EAS can transmit the ACT authorization token to the ECS for verification. At 9, after the ECS verifies (e.g., successfully verifies) the ACT authorization token, the ECS can respond to the S-EAS by confirmation. At 10, the S-EAS can migrate the AC application context to the T-EAS. At 11, the T-EAS can transmit an ACT completion message to the AC / EEC.

[0175] An EES for executing the ASF can be provided.

[0176] The ACF and the ASF can be logical functions, and this logical function can be part of other logical functions. Figure 6 An ACR selection function performed by the EES, for example, is shown.

[0177] Figure 6An example of the ACR selection function performed by the EES is shown. The ACR scenario selection can be performed by the EES (e.g., the first network node) for a given AC and the selected EAS (e.g., the second network node) from one or more of the supported ACR scenarios of the AC, EEC, the selected EES, and the selected EAS. The one or more supported ACR scenarios can include the ACR scenarios jointly supported by the AC, EEC, the selected EES, and the selected EAS. The EES can receive configuration information from the first network node, the second network node, and the application client. The EES can use the configuration information to determine the first network node and the second network node, and the second network node can be associated with the first network node.

[0178] One or more of the following can be applied to the ACR selection function performed by the EES: The EES can be pre-configured to perform the ASF; the AC profile can be provisioned in the EEC; or the AC profile can include an AC service continuity support information element (IE) with a list of supported and / or preferred ACR scenarios (e.g., the AC profile can specify the SCP capabilities for each supported and / or preferred ACR scenario).

[0179] One or more of the following can be applied to the ACR selection function performed by the EES.

[0180] At 1, the EEC can perform the EAS discovery procedure as described herein. The EEC can obtain a list of EASs that comply with the EEC criteria specified via the EAS discovery request. The EEC can perform EAS discovery with multiple EESs to discover EASs that may be available in different EDNs.

[0181] At 2, the EEC can select an EAS (e.g., one EAS) from the list of discovered EASs. The EEC can transmit an EAS selection request to the EES in which the selected EAS is registered. The terms "EAS selection request" and "EAS information provisioning request" can be used interchangeably.

[0182] At 3, the EEC can transmit a selection request message to the first network node, and the selection request message can request the ACR procedure from the first network node and indicate the service continuity support information associated with the EEC. The selection request can indicate security credentials, WTRU identifier, application client identifier, and / or application client profile. The selection request message can include the application client (AC) intent, and the intent of the AC can be to communicate with the second network.

[0183] The request may indicate the intention of the AC to use the selected EAS and may include one or more of the following information elements. The request may include the selected EAS ID that identifies the EAS that has been selected for use by the AC. The request may include the selected EAS endpoint (e.g., URI, FQDN, IP address, etc.) that identifies how to communicate with the selected EAS. The request may include the WTRU identifier (e.g., GPSI or identification token) that identifies the WTRU hosting the WTRU. The request may include the EEC identifier that identifies the EEC, e.g., because there may be multiple co-located EECs on a single WTRU. The request may include the EEC service continuity support that identifies the ACR procedures supported and / or preferred by the EEC, which includes SCP capabilities and the willingness of the EEC to perform ACF functionality. The request may include the security credentials resulting from the authorization of the edge computing service (e.g., successful authorization). The request may include the AC profile information, which includes AC service continuity support.

[0184] The EAS provisioning request may include an ACR scenario selection request. In the ACR scenario selection request, the EES may be informed (e.g., by the EEC) to perform ACR scenario selection. At 4, based on receiving the EAS selection request (e.g., from the EEC), the EES may continue to select an ACR procedure (e.g., select a list of ACR scenarios) that is compatible with the AC, EEC, EES, and / or EAS by using one or more of the following information: the AC service continuity support information element from the AC profile; the EEC service continuity support information element as defined in the EEC registration request or in the EAS discovery request (e.g., the defined EEC context may not include the service continuity support information and may be added); the EES service continuity support known at the EES; or the EAS service continuity support information element from the EAS profile.

[0185] SCP capabilities and / or ACR preferences can be considered in ACR selection and can be included in the service continuity support information. Since the ACF can be included in the EEC context and the EAS profile, the EES can consider the willingness of the EEC and the EAS to participate. The EES can consider one or more of the following information to select an ACR procedure: the current EDN type (e.g., DN or LADN), which can be derived from the EES topology and / or geographical service area in the EES profile or the EAS topology and / or geographical service area in the EES profile; the EDN type of the surrounding EDNs (e.g., the surrounding EESs can be obtained from the ECS), which can be derived from the EES topology and / or geographical service area in the EES profile; or the WTRU location (e.g., geographical and / or topological), which can be obtained as described herein. After establishing the ACR-detection-decision list, the EES can assign a globally unique identifier to the ACRs (e.g., each ACR) present in the list. For example, this identifier can be used for ACR management when the ACR can be re-evaluated, terminated, or when the ACR reports the detection of the ACF. The EES can assign an ACR effective area (e.g., geographical and / or topological) to the ACRs (e.g., each ACR) present in the list. This identifier can be used to enable or disable the selected ACR procedure based on the presence of the WTRU in the defined area.

[0186] At 5, the EES can send an ACR selection request to the selected EAS. In an example, if a subscription-notification model is used (e.g., if the EAS has subscribed), the EES can send an ACR selection notification to the selected EAS. The EES can determine one or more ACR procedures for providing continuity for the service based on the requested ACR procedure, the service continuity support information associated with the WTRU, the first network node, and the second network node. The one or more ACR procedures can include the requested ACR procedure. The EES can determine the provisioning information of the WTRU.

[0187] The request or notification can include one or more of the following information elements: the ACR-detection-decision list (e.g., including the globally unique identifier associated with the selected ACR procedure (e.g., each ACR procedure) and including the ACR effective area associated with the selected ACR procedure (e.g., each ACR procedure); the selected ACF identifier (e.g., FQDN, IP address, etc.); the security credentials generated by the authorization of the edge computing service (e.g., successful authorization); the AC identifier that uniquely identifies the AC; or the WTRU identifier (e.g., GPSI or identification token) that hosts the WTRU.

[0188] At 6, the EES may send an EAS selection response to the EEC. The EEC may receive a selection response message from a first network node, where the selection response message indicates one or more ACR procedures, and the ACR procedures may be supported by the WTRU and include the requested ACR procedure. The EES may send the selection response message to the WTRU, and the selection response message may indicate the determined one or more ACR procedures.

[0189] The response may include one or more information elements from the following information elements (e.g., information elements in an EAS information allocation response): ACR-detection-decision list (e.g., for each ACR in the list (e.g., each ACR) includes a globally unique identifier and for each ACR in the list (e.g., each ACR) includes the effective area to which the ACR procedure applies (such as geographical and / or topological)). The ACR-detection-decision list may be referred to as an ACR scenario list, as described herein. The selected ACR procedure list may not include an ACR procedure or may include one or more ACR procedures that the WTRU can support. The detection-decision list may include the requested ACR procedure.

[0190] One or more of the following may be applied to the ACR selection function performed by the EES. At 7a, based on receiving an EAS selection response, if the provided ACR-detection-decision list includes one or more ACR procedures that use (e.g., require) ACR detection at the EEC, the EEC may start ACR detection. The EEC may use the selected ACR scenario list to determine whether the EEC should perform ACT detection and / or ACR decision. Otherwise, the EEC may not perform ACR detection. The EEC may store the globally unique identifier associated with its ACR procedure for future ACR management operations, such as ACR termination requests and / or reporting ACR detection to the ACF. If the EAS selection response includes an ACR valid area, the EEC may verify whether the WTRU is in the valid area before starting ACR detection. Otherwise, the EEC may not start ACR detection until the WTRU enters the valid area and may stop ACR detection if the WTRU leaves the valid area. At 7b, after performing ACR selection, if the provided ACR-detection-decision list includes one or more ACR procedures that use (e.g., require) ACR detection at the EES, the EES may start ACR detection. The EES may use the selected ACR scenario list to determine whether the EEC should perform ACT detection and / or ACR decision. Otherwise, the EES may not perform ACR detection. The EES may store the globally unique identifier associated with its ACR procedure for future ACR management operations, such as ACR termination requests and / or reporting ACR detection to the ACF. If an ACR valid area is used, the EES may verify whether the WTRU is in the valid area before starting ACR detection. Otherwise, the EES may not start ACR detection until the WTRU enters the valid area and may stop ACR detection if the WTRU leaves the valid area. At 7c, based on receiving an ACR selection request and / or notification, if the provided ACR-detection-decision list includes one or more ACR procedures that use (e.g., require) ACR detection at the EAS, the EAS may start ACR detection. The EAS may use the selected ACR scenario list to determine whether the EEC should perform ACT detection and / or ACR decision. Otherwise, the EAS may not perform ACR detection. The EAS may store the globally unique identifier associated with its ACR procedure for future ACR management operations, such as ACR termination requests and / or reporting ACR detection to the ACF. If the ACR selection request includes an ACR valid area, the EAS may verify whether the WTRU is in the valid area before starting ACR detection. Otherwise, the EAS may not start ACR detection until the WTRU enters the valid area and may stop ACR detection if the WTRU leaves the valid area.

[0191] The EEC may perform ASF.

[0192] ACF and ASF can be logical functions, which can be part of other logical functions. Figure 7 An example of the ACR selection function performed by the EEC, for example, is shown.

[0193] Figure 7 An example of the ACR selection function performed by the EEC is shown.

[0194] One or more of the following can be applied to the ACR selection function performed by the EEC. The EEC can be preconfigured to perform ASF. An AC profile can be deployed in the EEC. The AC profile can include an AC service continuity support IE having a list of supported and / or preferred ACR scenarios (e.g., the AC profile can specify SCP capabilities for the supported and / or preferred ACR scenarios).

[0195] One or more of the following can be applied to the ACR selection function performed by the EEC. At 1, the EEC can perform the EAS discovery procedure as described herein. The EEC can receive configuration information from the EES (e.g., a first network node), the EAS (e.g., a second network node), and the application client. The EEC can use the configuration information to determine the first network node and the second network node, and the second network node can provide services. The second network node can register with the first network node (e.g., be associated with the first network node).

[0196] Thus, the EEC can obtain a list of EASs that meet the EEC criteria specified by the EAS discovery request. The EEC can perform EAS discovery with multiple EESs to discover EASs that may be available in different EDNs. At 2, the EEC can select an EAS (e.g., one EAS) from the list of discovered EASs. The EEC can select an ACR procedure that is compatible with the AC, EEC, EES, and / or EAS by using one or more of the following information: the AC service continuity support information element from the AC profile; the EEC service continuity support known at the EEC; the EES service continuity support information element from the EES profile; or the EAS service continuity support information element from the EAS profile. The SCP capabilities and / or ACR preferences can be considered in the ACR selection and included in the service continuity support information. The selection of the ACR procedure (e.g., scenario) can be performed by the EEC for the application client (AC) and the EAS selected from the ACR procedures jointly supported by the AC, EEC, the selected EES, and the selected EAS. The application of the ACR procedure for service continuity can be determined based on the capabilities of the WTRU, the EES (e.g., the first network node) capabilities, and the EAS (e.g., the second network node) capabilities. The ACR procedure can be determined by an ACR-detection-decision list. The detection-decision list can include the determined ACR procedure, and the determined ACR procedure can be compatible with the EEC (e.g., the WTRU), the application client (AC) of the WTRU, the first network node, and the second network node. The determined ACR procedure can be determined based on the service continuity support information of the AC, WTRU, first network node, and second network node.

[0197] The EEC may consider the willingness of the EES and EAS to participate as an ACF included in the EES profile and / or the EAS profile. The EEC may consider one or more of the following information to select an ACR procedure: the current EDN type (e.g., DN or LADN), which may be derived from the EES topology and / or geographical service area in the EES profile or the EAS topology and / or geographical service area in the EES profile; the EDN type of the surrounding EDNs (e.g., the surrounding EESs can be obtained from the ECS), which may be derived from the EES topology and / or geographical service area in the EES profile; or the WTRU location known at the terminal (e.g., geographical and / or topological). After establishing the ACR-detection-decision list, the EEC may assign a globally unique identifier to the ACRs (e.g., each ACR) present in the list. For example, this identifier may be used for ACR management when the ACR can be re-evaluated, terminated, or when the ACR reports the detection of an ACF. The EEC may assign an ACR effective area (e.g., geographical and / or topological) to the ACRs (e.g., each ACR) present in the list. This identifier may be used to enable or disable the selected ACR procedure based on the presence of the WTRU in the defined area.

[0198] At 3, the EEC may transmit an EAS selection request (e.g., ACR scenario selection announcement) to the EES registered with the selected EAS. This request may indicate the AC intent. The EAS selection request may inform the EES of the EAS that has been selected by the EEC and may provide the EES with a list of the selected ACR scenarios. The EEC may transmit an EAS information selection request (also referred to herein as a provisioning request). The ACR selection request may include a list of ACR scenarios selected by the EEC, the EEC security credentials, the selected EAS ID, the selected EAS endpoint, the EEC ID, and the AC ID. The selection request message may request the provision of information for a second network node, request one or more application context relocation (ACR) procedures, and indicate the second network node identifier, the WTRU identifier, and the security credentials. The selection request may include a second network endpoint identifier, and this second network endpoint identifier may identify how the device communicates with the second network.

[0199] The request may indicate an AC intent to use the selected EAS (e.g., an intent to communicate with the EAS (e.g., a second network node)), and may include one or more of the following information elements: a selected EAS ID identifying the EAS that has been selected for use by the AC; a selected EAS endpoint (e.g., a URI, FQDN, IP address, etc.) identifying how to communicate with the selected EAS; an ACR-detection-decision list including a globally unique identifier associated with the selected ACR procedure (e.g., each selected ACR procedure) and including an ACR valid region associated with the selected ACR procedure (e.g., each selected ACR procedure); a selected ACF identifier (e.g., FQDN, IP address, etc.); a WTRU identifier (e.g., a GPSI or an identification token) identifying the WTRU hosting the WTRU; an EEC identifier identifying the EEC when there may be multiple EECs co-located on a single WTRU; an EEC service continuity support identifying the ACR procedures supported and / or preferred by the EEC, including SCP capabilities; an EEC service continuity support identifying the ACR procedures supported by the EEC, including SCP capabilities; security credentials resulting from an authorization for edge computing services (e.g., a successful authorization); or AC profile information including AC service continuity support. The ACR-detection-decision list may include zero or more ACR procedures. The capabilities of the first network node may include service continuity support information of the first network node, and the capabilities of the second network node may include service continuity support information of the second network node. At 4, the EES may transmit an ACR selection request to the selected EAS. In an example, if a subscription-notification model is used (e.g., if the EAS has subscribed and if the EES permits ACR scenario selection based on the EEC), the EES may (e.g., upon receipt of a request from the EEC) transmit an ACR selection notification to the selected EAS. The EES may use the identifier of the second network node to determine that the second network node has subscribed to receive the selection notification. The EES may use the WTRU identifier and the security credentials to determine that the EES is authorized to communicate with the second network node. When the WTRU is authorized to communicate with the second network node and the second network node has subscribed to receive the selection notification, the EES may transmit a notification message to the second network node. The notification message may indicate the requested ACR procedure.

[0200] The ACR selection can inform the EAS of the selected list of ACR scenarios for the AC used with the EAS. If an ACR selection occurs, the selection notification can include the selected list of ACR scenarios, the AC ID, and the WTRU ID. Upon receiving the notification, the EAS can determine whether the EAS should perform ACR detection and / or make an ACR decision for a (e.g., specific) AC (AC ID, WTRU ID). The EES can transmit the selection notification to a second network node on the condition that the second network node has subscribed to the notification.

[0201] The request and / or notification can include one or more of the following information elements: an ACR-detection-decision list, including a globally unique identifier associated with the selected ACR procedure (e.g., each selected ACR procedure) and an ACR valid region associated with the selected ACR procedure (e.g., each selected ACR procedure); security credentials resulting from the authorization of the edge computing service (e.g., successful authorization); an AC identifier identifying the AC; or a WTRU identifier hosting the WTRU (e.g., GPSI or identification token). At 5, the EES can transmit an EAS selection response to the EEC. The EAS selection response and the EAS information provisioning response can be used interchangeably herein. The selection response can include provisioning information for the second network node, and the selection response message can indicate a success status.

[0202] One or more of the following can be applied to the ACR selection function performed by the EEC. At 6a, after performing the ACR selection, if the provided ACR-detection-decision list includes one or more ACR procedures that use (e.g., require) ACR detection at the EEC, the EEC can start ACR detection. In an example, the EEC can use the selected list of ACR scenarios to determine whether the EEC should perform ACR detection and / or make an ACR decision. ACR can be detected on the condition that one of the determined ACR procedures includes an ACR procedure having ACR detection performed at the WTRU, EES, and / or EAS.

[0203] Otherwise, the EEC may not perform ACR detection. The EEC may store a globally unique identifier associated with its ACR procedures for future ACR management operations, such as ACR termination requests and / or reporting ACR detection to the ACF. If an ACR active region is used, the EEC may verify whether the WTRU is within the active region before starting ACR detection. Otherwise, the EEC may not start ACR detection until the WTRU enters the active region and may stop ACR detection if the WTRU leaves the active region. At 6b, based on receiving an EAS selection request, if the provided ACR-detection-decision list includes one or more ACR procedures that use (e.g., require) ACR detection at the EES, the EES may start ACR detection. Otherwise, the EES may not perform ACR detection. The EES may store a globally unique identifier associated with its ACR procedures for future ACR management operations, such as ACR termination requests and / or reporting ACR detection to the ACF. If the EAS selection request includes an ACR active region, the EES may verify whether the WTRU is within the active region before starting ACR detection. Otherwise, the EES may not start ACR detection until the WTRU enters the active region and may stop ACR detection if the WTRU leaves the active region. At 6c, based on receiving an ACR selection request and / or notification, if the provided ACR-detection-decision list includes one or more ACR procedures that use (e.g., require) ACR detection at the EAS, the EAS may start ACR detection. Otherwise, the EAS may not perform ACR detection. The EAS may store a globally unique identifier associated with its ACR procedures for future ACR management operations, such as ACR termination requests and / or reporting ACR detection to the ACF. If the ACR selection request includes an ACR active region, the EAS may verify whether the WTRU is within the active region before starting ACR detection. Otherwise, the EAS may not start ACR detection until the WTRU enters the active region and may stop ACR detection if the WTRU leaves the active region.

[0204] An EES that performs the ACF may be provided.

[0205] The ACF and the ASF may be logical functions that may be part of other logical functions. Figure 8 An example of an ACR coordination function performed by the EES is shown.

[0206] Figure 8 An example of an ACR coordination function performed by the EES is shown.

[0207] One or more of the following may be applied to the ACR coordination function performed by the EES. The ASF may include two or more ACR procedures in the ACR-detection-decision. The ASF may select the EES as the ACF entity.

[0208] One or more of the following can be applied to the ACR coordination function performed by the EES. At 1a, the ASF can choose to use (e.g., require) the EEC to perform the ACR procedure for ACR detection and decision-making. The ASF can choose the EES as the ACF entity. Based on the received ACR selection, the EEC can configure the EES as the ACR coordinator. At 1b, the ASF can choose to use (e.g., require) the EAS to perform the ACR procedure for ACR detection and decision-making. In the example, the ASF can choose the EES as the ACF entity. Based on the received ACR selection, the EAS can configure the EES as the ACR coordinator. At 2a, the EEC can decide to use (e.g., need) ACR and can transmit an ACR coordination request to the EES. The request can include one or more of the following information elements: a requester identifier (e.g., EECID) that identifies the EEC; a unique identifier assigned by the EEC and that can identify the ACR coordination request; or an ACR procedure identifier (e.g., provided in the ACR-detection-decision list) that identifies the ACR procedure for performing detection and decision-making. At 2b, the EAS can (e.g., concurrently) decide to use (e.g., need) ACR and can transmit an ACR coordination request to the EES. The request can include one or more of the following information elements: a requester identifier (e.g., EASID) that identifies the EAS; a unique identifier assigned by the EAS and that can identify the ACR coordination request; or an ACR procedure identifier (e.g., provided in the ACR-detection-decision list) that identifies the ACR procedure for performing detection and decision-making. At 3, based on receiving an ACR coordination request (e.g., from a second network node), the EES can evaluate which ACR procedures are allowed to be performed and can select one (e.g., only one) ACR procedure to perform. The first network node can transmit an ACR event notification to the second network node, and the event notification can indicate that the ACR event has started. The first network node can transmit the ACR event notification to the second network node based on the selected ACR procedure determined from the one or more determined ACR procedures.

[0209] The ACR selection algorithm may select an ACR procedure based on, for example, one or more of the following: ACR coordination request timestamp; a preferred list of ACR procedures; source EDN type (e.g., DN or LADN); target EDN type (e.g., DN or LADN); or WTRU location. After selecting an ACR coordination request, the EES may transmit an ACR coordination response to the parties transmitting the ACR coordination request (e.g., all parties). The response may include a decision to enter the ACR execution phase (e.g., true or false), the ACR globally unique identifier of the ACR entering the execution phase, and / or the ACR coordination request identifier received in the corresponding request. At 4a, based on the received coordination response, the EEC may verify that the ACR identifier selected to proceed to the execution phase matches its own ACR identifier, that the decision is affirmative, and / or that the ACR coordination request identifier matches the identifier provided in the request. If the response is affirmative, the ACR identifier may match the EEC ACR and the ACR coordination request identifier matches, and the EEC may proceed to the ACR execution phase. Otherwise, the EEC may not proceed to ACR execution. At 4b, based on the received coordination response, the EAS may verify that the ACR identifier selected to proceed to the execution phase matches its own ACR identifier, that the decision is affirmative, and / or that the ACR coordination request identifier matches the identifier provided in the request. If the response is affirmative, the ACR identifier may match the EEC ACR and the ACR coordination request identifier matches, and the EEC may proceed to the ACR execution phase. Otherwise, the EEC may not proceed to ACR execution. In an example, the response may be negative, and the selected ACR identifier may not be the identifier that the EAS is executing. In this case, the EAS may not enter the ACR execution phase. At 5, in an example, the response may be affirmative, the selected ACR identifier matches the EEC's ACR, and the ACR coordination identifier received in the response matches the identifier provided in the request. In this case, the EEC may enter the ACR execution phase according to the selected ACR procedure.

[0210] An EEC for performing ACF may be provided.

[0211] ACF and ASF may be logical functions, and the logical functions may be part of other logical functions. Figure 9 An example of an ACR coordination function performed by the EEC is shown.

[0212] Figure 9 An example of an ACR coordination function performed by the EEC is shown.

[0213] One or more of the following may be applied to the ACR coordination function performed by the EEC. The ASF has included two or more ACR procedures in the ACR-detection-decision, or the ASF has selected the EEC as the ACF entity.

[0214] One or more of the following may be applied to the ACR coordination function performed by the EEC. At 1a, the ASF may choose to use (e.g., require) the EEC to perform the ACR procedures for ACR detection and decision-making. The ASF may choose the EEC as the ACF. Based on receiving the ACR selection information, the EEC may configure the EEC as the ACR coordinator. At 1b, the ASF may choose to use (e.g., require) the EES to perform the ACR procedures for ACR detection and decision-making. The ASF may choose the EEC as the ACF. Based on receiving the ACR selection information, the EES may configure the EEC as the ACR coordinator. At 2a, the EEC may decide to use (e.g., need) the ACR and may transmit an ACR coordination request to the EEC. The request may include one or more of the following information elements: a requester identifier that identifies the EEC (e.g., EECID); a unique identifier assigned by the EEC and that may identify the ACR coordination request; or an ACR procedure identifier that identifies the ACR procedure for performing the detection and decision-making (e.g., the identifier is provided in the ACR-detection-decision list). In the example, the EEC may convey the ACR decision internally to the ACF. At 2b, the EES may (e.g., concurrently) decide to use (e.g., need) the ACR and may transmit an ACR coordination request to the EEC. The request may include one or more of the following information elements: a requester identifier that identifies the EES (e.g., EESID); a unique identifier assigned by the EES and that may identify the ACR coordination request; or an ACR procedure identifier that identifies the ACR procedure for performing the detection and decision-making (e.g., the identifier is provided in the ACR-detection-decision list). At 3, based on receiving the ACR coordination request, the EEC may evaluate which ACR procedures are allowed to be performed and may select one (e.g., only one) ACR procedure to perform. The ACR selection algorithm may select the ACR procedure based on, for example, one or more of the following: the ACR coordination request timestamp; a preferred list of ACR procedures; the source EDN type (e.g., DN or LADN); the target EDN type (e.g., DN or LADN); or the WTRU location. After selecting the ACR coordination request, the EEC may transmit an ACR coordination response to the parties that transmitted the ACR coordination request (e.g., all parties). The response may include a decision to enter the ACR execution phase (e.g., true or false), the ACR globally unique identifier of the ACR entering the execution phase, and / or the ACR coordination request identifier received in the corresponding request. At 4a, based on receiving the coordination response, the EEC may verify that the ACR identifier selected to proceed to the execution phase matches its own ACR identifier, that the decision is affirmative, and / or that the ACR coordination request identifier matches the identifier provided in the request. If the response is affirmative and the ACR identifier can match the EEC ACR, then the ACR coordination may match the requested identifier match, and the EEC may proceed to the ACR execution phase.Otherwise, the EEC may not proceed to ACR execution. In the example, the response may be negative, and the selected ACR identifier may not be the identifier that the EEC is executing. In this case, the EEC may not enter the ACR execution phase. At 4b, based on receiving a coordination response, the EES may verify that the ACR identifier selected to proceed to the ACR execution phase matches its own ACR identifier, the decision is affirmative, and / or the ACR coordination request identifier matches the identifier provided in the request. If the response is affirmative, the ACR identifier may match the EES ACR and the ACR coordination request identifier matches, and the EES may proceed to the ACR execution phase. Otherwise, the EEC may not proceed to ACR execution. At 5, in the example, the response may be affirmative, the selected ACR identifier may match the ACR of the EES, and the ACR coordination identifier received in the response matches the identifier provided in the request. In this case, the EES may enter the ACR execution phase according to the selected ACR procedure.

[0215] The combined use of ASF and ACF may be provided.

[0216] ACF and ASF may be logical functions, which may be part of other logical functions.

[0217] Figure 10 An example of the combined use of the ACR selection function, e.g., performed by the EEC as described herein, and the ACR coordination function, e.g., performed by the EES as described herein, is shown. Figure 10 An example of the combined use of ASF and ACF is shown.

[0218] One or more of the following may be applied to the ASF and ACF used in a combined manner. At 1, the EEC may perform an EAS discovery procedure. Thus, the EEC may obtain a list of EASs that meet the EEC criteria specified in the EAS discovery request. The EEC may perform EAS discovery with multiple EESs to discover EASs that may be available in different EDNs. At 2, the EEC may select an EAS (e.g., one EAS) from the list of discovered EASs. The EEC may select an ACR procedure that follows the procedures described herein. At 3, the EEC may transmit an EAS selection request to the EES in which the selected EAS is registered. The request may indicate the intention to use the selected EAS by the AC and may include an ACR-detection-decision list and an ACF identification. In an example, the EEC may decide to include an ACR procedure (e.g., two ACR procedures) in the ACR-detection-decision list. The first selected ACR procedure may use (e.g., require) the EEC to perform ACR detection and decision. The second selected ACR procedure may use (e.g., require) the EAS to perform ACR detection and decision. In an example, the EEC may select the EES as the ACR coordination function. At 4, the EES may transmit an ACR selection request to the selected EAS. The EES may evaluate the provided ACR-detection-decision list and may infer that the included ACR procedure does not use (e.g., does not require) the EES to perform ACR detection. In this case, the ACR detection process may not be started. Since the EES has been selected to provide ACR coordination, if ACR coordination processing is used (e.g., required), the EES may initiate the ACR coordination processing. At 5, the EES may transmit an EAS selection response to the EEC. At 6a, for example, after performing ACR selection, the EEC may identify that one of the ACR procedures included in the ACR-detection-decision list uses (e.g., requires) the EEC to perform ACR detection at the EEC and may start the ACR detection and decision process. At 6b, based on receiving the ACR selection request, the EAS may identify that one of the ACR procedures included in the ACR-detection-decision list uses (e.g., requires) the EAS to perform ACR detection at the EAS and may initiate the ACR detection and decision process. When the WTRU moves, the ACR detection at the EEC and the EAS may detect the WTRU mobility, and both the EEC and the EAS may decide that context relocation needs to be applied. At 7a, the EEC may transmit an ACR coordination request to the EES selected as the ACR coordination function described herein. At 7b, the EAS may transmit an ACR coordination request to the EES selected as the ACR coordination function described herein. At 8, based on receiving the ACR coordination request, the EES may decide which ACR procedure may proceed to the execution phase. In an example, the EES may select the EEC to perform the ACR procedure execution and may reject the EAS from performing the ACR procedure.At 9A, based on the received coordination response, the EEC may verify the ACR identifier, execution decision, and / or ACR request identifier. The EEC may proceed to the ACR procedure execution phase based on the ACR coordination request response. At 9B, based on the received coordination response, the EAS may verify the ACR identifier, execution decision, and / or ACR request identifier. The EAS may not proceed to the ACR procedure execution phase based on the ACR coordination request response. At 10, based on the received positive response, the EEC may initiate ACR execution, which migrates the AC context stored at the source EAS to the target EAS.

[0219] Systems, methods, and tools for application context relocation (ACR) selection and / or coordination are disclosed herein. A wireless transmit / receive unit (WTRU) may receive configuration information regarding one or more of a first network node (e.g., an edge enabling server (EES)), a second network node (e.g., an edge application server (EAS)), and an application client (AC). The WTRU may use the configuration information to determine the first network node and the second network node. The second network node may provide a service, and the second network node may be associated with the first network node. The WTRU may determine one or more ACR procedures for providing continuity for the service based on WTRU capabilities, first network node capabilities, and second network node capabilities. The WTRU may transmit a selection request message to the first network node, and the selection request message may indicate the identifier of the second network node, the WTRU identifier, and the one or more determined ACR procedures. The WTRU may receive a selection response message from the first network node indicating the request processing status.

[0220] The first network node may be an edge enabling server (EES), and the second network node may be an edge application server (EAS). The WTRU may further determine a list based on service continuity capability information associated with the WTRU, the first network node, and the second network node. The list may include the one or more determined ACR procedures, and the one or more determined ACR procedures may be compatible with one or more of the WTRU, the WTRU's application client (AC), the WTRU's edge enabling client (EEC), the first network node, or the second network node.

[0221] The WTRU may determine that the one or more determined ACR procedures are determined based on service continuity support information of an application client (AC) associated with the WTRU, the WTRU, the EEC, the first network node, or the second network node. The WTRU may detect ACR subject to using the one or more determined ACR procedures.

[0222] The present disclosure relates to systems, methods, and tools for ACR selection and / or coordination. A first network node may receive a selection request message from a wireless transmit / receive unit (WTRU), where the selection request message indicates one or more application context relocation (ACR) procedures, a second network node identifier, a WTRU identifier, and security credentials. The first network node may use the identifier of the second network node to determine that the second network node has subscribed to receive selection notifications. The first network node may use the WTRU identifier and the security credentials to determine that the WTRU is authorized to communicate with the second network node. The first network node may transmit a notification message to the second network node, and the notification message may indicate the one or more requested ACR procedures. The first network node may transmit a selection response message to the WTRU indicating the status of the request processing.

[0223] The first network node may be an edge enabling server (EES), and the second network node may be an edge application server (EAS). The second network node may register with the first network node. The selection request message may include an application client (AC) intent, and the AC intent may be to communicate with the second network.

[0224] The first network node may detect an ACR if at least one of the one or more requested ACR procedures includes an ACR procedure for detecting the need for an ACR at the first network node.

[0225] The first network node may detect an ACR if at least one of the one or more requested ACR procedures includes an ACR procedure for detecting the need for an ACR at the second network node.

[0226] The present disclosure relates to systems, methods, and tools for ACR selection and / or coordination. A WTRU may receive configuration information about one or more of a first network node, a second network node, and an application client. The WTRU may use the configuration information to determine the first network node and the second network node, and the second network node may be associated with the first network node. The WTRU may transmit a selection request message to the first network node. The selection request message may indicate a request for an application context relocation (ACR) procedure from the first network node, and may indicate service continuity support information associated with the WTRU. The WTRU may receive a selection response message from the first network node, and the selection response message may indicate one or more ACR procedures. The one or more ACR procedures may be supported by the WTRU.

[0227] The first network node may be an Edge Enablement Server (EES), and the second network node may be an Edge Application Server (EAS). The selection request may indicate at least one of security credentials, a WTRU identifier, an application client identifier, or an application client profile.

[0228] The selection request message further indicates an Application Client (AC) intent, and the AC intent may be to communicate with the second network. The selection response may include a list, and the list may include one or more ACR procedures supported by the WTRU.

[0229] The WTRU may detect an ACR in at least one ACR procedure received in the selection response, where the ACR procedure includes a condition for detecting an ACR that requires ACR at the WTRU.

[0230] Systems, methods, and tools for ACR selection and / or coordination are disclosed herein. A first network node may receive a selection request message from a Wireless Transmit / Receive Unit (WTRU). The selection request message may request a selection of an Application Context Relocation (ACR) procedure and may indicate service continuity capability information associated with the WTRU. The first network node may determine one or more ACR procedures for providing continuity of service based on service continuity capability information associated with the WTRU, the first network node, and the second network node. The first network node may further determine a detection-decision list based on the one or more ACR procedures, and the detection-decision list may include the one or more ACR procedures determined. The one or more ACR procedures determined may be compatible with one or more of the WTRU, the WTRU's Application Client (AC), the WTRU's Edge Enablement Client (EEC), the first network node, or the second network node. The first network node may transmit a selection response message to the WTRU, and the selection response message may indicate the one or more ACR procedures determined.

[0231] The first network node may be an Edge Enablement Server (EES), and the second network node may be an Edge Application Server (EAS). The first network node may use the one or more ACR procedures to detect an ACR. The selection response may include a list, and the list may include one or more ACR procedures supported by the WTRU. The first network node may transmit a selection notification to the second network node under the condition that the second network node has subscribed to the notification. The service continuity support information may at least indicate the capabilities of the first network node, the capabilities of the second network node, and / or the capabilities of the WTRU.

[0232] The present disclosure relates to systems, methods, and tools for ACR selection and / or coordination. A WTRU may detect a need to apply context relocation (ACR). The WTRU may transmit an ACR coordination request to a first network node when the WTRU detects a condition that requires ACR. The WTRU may receive an ACR coordination request response, and based on the ACR coordination response, the WTRU may determine whether to perform the ACR. The WTRU may receive an ACR coordination notification indicating that the WTRU stop ACR detection when the WTRU does not determine a need for ACR.

[0233] The first network node may be an edge enabling server (EES). When it is determined that the WTRU or a second network node has requested ACR, the WTRU may transmit an ACR coordination request to the second network node.

[0234] The present disclosure relates to systems, methods, and tools for ACR selection and / or coordination. A first network node may detect whether a need to apply context relocation (ACR) exists. The first network node may transmit a first notification to one or more of a wireless transmit receive unit (WTRU) or a second network node when the first network node detects a condition that requires ACR. The first network node may stop ACR detection when the first network node does not detect a need for ACR and when the first network node receives a first ACR coordination request. The first network node may transmit a notification to the WTRU and / or the second network node, and the notification may indicate that ACR detection has stopped. The first network node may transmit an ACR coordination response indicating that ACR is permitted to one or more of the WTRU or the second network node. The first network node may indicate that ACR is not permitted to one or more of the WTRU or the second network node when the first network node receives a second ACR coordination request.

[0235] The first network node may be an edge enabling server (EES), and the second network node may be an edge application server (EAS). The first ACR coordination request may be received from one or more of the WTRU or the second network node.

[0236] The present disclosure relates to systems, methods, and tools for Application Context Relocation (ACR) selection and / or coordination. An ACR Selection Function (ASF) can be used to select, communicate, and / or manage ACR procedures for service continuity between an edge application server and an application client on a WTRU (Wireless Transmit / Receive Unit). An entity (e.g., EEC or EES) can act as the ASF. Acting as the ASF can include one or more of the following: selecting an ACR procedure that can be used for an AC and EAS pair and generating an ACR-detection-decision list (e.g., an ACR list, ACR identifier, and / or ACR valid region); selecting an ACF entity in the case where more than one ACR procedure is selected; communicating and / or transmitting an ASF decision (e.g., an ACR-detection-decision list and / or an ACF entity identifier) to other entities (e.g., EEC, EES, and / or EAS); or re-evaluating the selected ACR procedure when the selection criteria and / or inputs (e.g., WTRU location, WTRU planned route, WTRU mobility analysis, neighboring EDN ACR capabilities) change.

[0237] When an ACR procedure (e.g., a concurrent ACR procedure) is used for service continuity between an edge application server and an application client on a WTRU, an ACR Coordination Function (ACF) can be used to gate the execution of the ACR. An entity (e.g., EEC or EES) can act as the ACF. Acting as the ACR Coordination Function (ACF) can include one or more of the following: receiving a request from an entity (e.g., EEC, EES, and / or EAS). The request can indicate that the ACR is being used (e.g., is required) and can request permission to execute the ACR procedure; or transmitting a response to the requesting entity to indicate whether the ACR procedure can be executed.

[0238] The present disclosure relates to systems, methods, and tools for application context relocation (ACR) selection and / or coordination. For example, a method may be provided that may be executed by a processor (e.g., the processor may be configured to execute the method). And the processor may be associated with a device such as a wireless transmit / receive unit (WTRU). Configuration information associated with one or more of a first network node, a second network node, and an application client (AC) may be received. The configuration information may be used to determine the first network node and the second network node. The second network node may provide a service and may be associated with the first network node. One or more application context relocation (ACR) procedures for providing continuity for the service may be determined. These procedures may be based on WTRU capabilities, first network node capabilities, and second network node capabilities. A selection request message may be transmitted to the first network node. The selection request message indicates an identifier of the second network node, a WTRU identifier, and the determined one or more ACR procedures. A selection response message may be received from the first network node. The message may indicate a request processing status result.

[0239] In an example, the first network node may be an edge enabling server (EES). The second network node is an edge application server (EAS).

[0240] In an example, a list may be determined based on service continuity capability information associated with the WTRU, the first network node, and the second network node. It may include the determined one or more ACR procedures, and these procedures may be compatible with one or more of the WTRU, the AC, the edge enabling client (EEC) of the WTRU, the first network node, or the second network node.

[0241] In an example, the determined one or more ACR procedures may also be based on service continuity support information of the AC, the WTRU, the EEC, the first network node, or the second network node.

[0242] In an example, ACR may be detected subject to using the determined one or more ACR procedures.

[0243] The present disclosure relates to systems, methods, and tools for application context relocation (ACR) selection and / or coordination. For example, a method may be provided that may be executed by a processor (e.g., the processor may be configured to execute the method). And the processor may be associated with a device such as a first network node. A selection request message may be received from a WTRU. The selection request message may indicate one or more ACR procedures, a second network node identifier, and a WTRU identifier. The second network node identifier may be used to determine that the second network node has subscribed to receive selection notifications. The WTRU identifier may be used to determine that the WTRU is authorized to communicate with the second network node. A notification message may be transmitted to the second network node, the notification message may indicate the one or more requested ACR procedures. A selection response message indicating a request processing status result may be transmitted to the WTRU.

[0244] In an example, the first network node may be an edge enabling server (EES), and the second network node may be an edge application server (EAS).

[0245] In an example, the second network node may register with the first network node.

[0246] In an example, the selection request message may further include an application client (AC) intent. The AC intent may be to communicate with the second network node.

[0247] In an example, ACR may be detected under the condition that at least one of the one or more requested ACR procedures includes an indication that the first network node will perform ACR detection.

[0248] In an example, ACR may be detected under the condition that at least one of the one or more requested ACR procedures includes an indication that the second network node will perform ACR detection.

[0249] Systems, methods, and tools for application context relocation (ACR) selection and / or coordination are disclosed herein. For example, a method may be provided that may be executed by a processor (e.g., the processor may be configured to execute the method). And the processor may be associated with a device such as a wireless transmit / receive unit (WTRU). Configuration information associated with at least an application client (AC) may be received. The configuration information may be used to determine a first network node and a second network node. The second network node may be associated with the first network node. A selection request message may be transmitted to the first network node. The selection request message may indicate a request for an application context relocation (ACR) procedure from the first network node. The selection request message may indicate service continuity support information associated with the WTRU. A selection response message may be received from the first network node. The selection response message may indicate one or more ACR procedures that may be supported by the WTRU.

[0250] In an example, the first network node may be an edge enabler server (EES). The second network node may be an edge application server (EAS).

[0251] In an example, the selection request message may indicate at least one of security credentials, a WTRU identifier, an AC identifier, or an AC profile.

[0252] In an example, the selection request message may indicate an AC intent. The AC intent may be to communicate with the second network node.

[0253] In an example, the selection response message may include a capabilities list. The list may include the one or more ACR procedures that may be supported by the WTRU.

[0254] In an example, ACR may be detected. At least one ACR procedure received in the selection response message may include conditions for ACR detection for example in the event of ACR detection at the WTRU.

[0255] The present disclosure relates to systems, methods, and tools for application context relocation (ACR) selection and / or coordination. For example, a method may be provided that may be executed by a processor (e.g., the processor may be configured to execute the method). And the processor may be associated with a device such as a first network node. A selection request message may be received from a wireless transmit / receive unit (WTRU). The selection request message may request a selection of an application context relocation (ACR) procedure and may indicate service continuity capability information associated with the WTRU. One or more ACR procedures for providing service continuity may be selected based on the service continuity capability information associated with the WTRU, the first network node, and a second network node. A list may be determined based on the selected one or more ACR procedures. The list may at least include the selected one or more ACR procedures. The selected one or more ACR procedures may be compatible with one or more of the WTRU, an application client (AC) of the WTRU, an edge enabling client (EEC) of the WTRU, the first network node, or the second network node. A selection response message indicating the list may be transmitted to the WTRU.

[0256] In an example, the first network node may be an edge enabling server (EES), and the second network node may be an edge application server (EAS).

[0257] In an example, ACR may be detected on the condition that the list may include an indication that the second network node will perform ACR detection.

[0258] In an example, a selection notification may be transmitted to the second network node on the condition that the second network node has subscribed to the notification.

[0259] In an example, the service continuity capability information may at least indicate the capability of the first network node, the capability of the second network node, or the capability of the WTRU.

[0260] The present disclosure relates to systems, methods, and tools for application context relocation (ACR) selection and / or coordination. For example, a method may be provided that may be executed by a processor (e.g., the processor may be configured to execute the method). And the processor may be associated with a device such as a wireless transmit / receive unit (WTRU). When an application context relocation (ACR) event is detected, a first ACR coordination message may be transmitted to a first network node. The ACR event may be detected according to an ACR procedure. A second ACR coordination message may be received from the first network node. An ACR execution message may be generated based on the second ACR coordination message. The ACR execution message may be generated according to the ACR procedure. The ACR execution message may be transmitted to at least one of the first network node or the second network node.

[0261] In an example, the first ACR coordination message may be an ACR coordination request. The second ACR coordination message may be an ACR coordination response message.

[0262] In an example, the second ACR coordination message may be at least one of an ACR coordination notification message or an ACR coordination response message.

[0263] In an example, the second ACR coordination message may indicate that the ACR execution is to be performed by the WTRU.

[0264] In an example, the ACR event may be detected.

[0265] In an example, the ACR event may be detected under the condition that the ACR procedure indicates a procedure for detecting ACR at the WTRU.

[0266] In an example, a selection response message may be received from the first network node. The selection response message may indicate the ACR procedure.

[0267] In an example, the first network node may be a first edge enabling server (EES). The second network node may be a second EES or an edge configuration server (ECS).

[0268] Systems, methods, and tools for application context relocation (ACR) selection and / or coordination are disclosed herein. For example, a method may be provided that may be executed by a processor (e.g., the processor may be configured to execute the method). And the processor may be associated with a device such as a first network node. A first application context relocation (ACR) coordination message may be received from at least one of a wireless transmit / receive unit (WTRU) or a second network node. An entity for performing the ACR procedure may be determined. The entity may be one of the first network node, the second network node, or the WTRU. A first coordination decision may be determined based on the determined entity and the identity of the WTRU. A second coordination decision may be determined based on the determined entity and the identity of the second network node. A second ACR coordination message may be transmitted to the WTRU. The second ACR coordination message may indicate the first coordination decision. A third ACR coordination message may be transmitted to the second network node. The third ACR coordination message may indicate the second coordination decision.

[0269] In an example, the first coordination decision may indicate that the WTRU may be the ACR execution entity. The second coordination decision may indicate that the second network node will wait for the ACR execution.

[0270] In an example, the first coordination decision may indicate that the WTRU will wait for the ACR execution. The second coordination decision may indicate that the second network node is the ACR execution entity.

[0271] In an example, the first coordination decision may indicate that the WTRU will wait for the ACR to be executed. The second coordination decision may indicate that the second network node will wait for the ACR to be executed.

[0272] In an example, an ACR event may be detected.

[0273] In an example, the ACR event may be detected under conditions where the ACR procedure may indicate a procedure for detecting the ACR at the first network node.

[0274] In an example, the first network node may be a first Edge-Enabled Server (EES). The second network node may be at least one of a second EES, an Edge Application Server (EAS), or an Edge Configuration Server (ECS).

[0275] Although the above features and elements are described in specific combinations, each feature or element may be used alone without the other features and elements of the preferred embodiment, or in various combinations with or without other features and elements.

[0276] Although the specific implementations described herein may consider 3GPP specific protocols, it should be understood that the specific implementations described herein are not limited to such scenarios and may be applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR), or 5G specific protocols, it should be understood that the solutions described herein are not limited to this scenario and are also applicable to other wireless systems.

[0277] The processes described above may be implemented in a computer program, software, and / or firmware combined with a computer-readable medium for execution by a computer and / or a processor. Examples of computer-readable media include, but are not limited to, electronic signals (sent via wired or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, internal hard disks and removable disks), magneto-optical media, and optical media (such as compact disc (CD)-ROM disks and / or digital versatile discs (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, a terminal, a base station, an RNC, and / or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), the WTRU comprising: a processor configured to: receive configuration information associated with one or more of a first network node, a second network node, and an application client (AC); use the configuration information to determine the first network node and the second network node, wherein the second network node provides a service and wherein the second network node is associated with the first network node; determine one or more application context relocation (ACR) procedures for providing continuity for the service based on WTRU capabilities, first network node capabilities, and second network node capabilities; transmit a selection request message to the first network node, wherein the selection request message indicates an identifier of the second network node, an edge enablement client (EEC) identifier associated with the WTRU, and the determined one or more ACR procedures; and receive a selection response message from the first network node indicating a request processing status result.

2. The WTRU according to claim 1, wherein the first network node is an edge enablement server (EES) and wherein the second network node is an edge application server (EAS).

3. The WTRU according to claim 1, wherein the processor is further configured to determine a list based on service continuity capability information associated with the WTRU, the first network node, and the second network node, wherein the list includes the determined one or more ACR procedures, and wherein the determined one or more ACR procedures are compatible with one or more of the WTRU, the AC, the WTRU's EEC, the first network node, or the second network node.

4. The WTRU according to claim 1, wherein the determined one or more ACR procedures are further based on service continuity support information of the AC, the WTRU, the EEC, the first network node, or the second network node.

5. The WTRU according to claim 1, wherein the processor is further configured to detect ACR subject to using the determined one or more ACR procedures.

6. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: receiving configuration information associated with one or more of a first network node, a second network node, and an application client (AC); using the configuration information to determine the first network node and the second network node, wherein the second network node provides a service and wherein the second network node is associated with the first network node; determining one or more application context relocation (ACR) procedures for providing continuity for the service based on WTRU capabilities, first network node capabilities, and second network node capabilities; transmitting a selection request message to the first network node, wherein the selection request message indicates an identifier of the second network node, an edge enablement client (EEC) identifier, and the determined one or more ACR procedures; and Receive a selection response message indicating a request processing status from the first network node.

7. The method according to claim 6, wherein the first network node is an Edge Enablement Server (EES), and wherein the second network node is an Edge Application Server (EAS).

8. The method according to claim 6, wherein the method further comprises determining a list based on service continuity capability information associated with the WTRU, the first network node, and the second network node, wherein the list comprises one or more determined ACR procedures, and wherein the one or more determined ACR procedures are compatible with one or more of the WTRU, the AC, the EEC of the WTRU, the first network node, or the second network node.

9. The method according to claim 6, wherein the one or more determined ACR procedures are further based on service continuity support information of the AC, the WTRU, the EEC, the first network node, or the second network node.

10. The method according to claim 6, wherein the method further comprises detecting ACR subject to the condition of using the one or more determined ACR procedures.

Images