WO2025024689A1

WO2025024689A1 - Authorization of application context relocation from edge data network (edn) to cloud

Info

Publication number: WO2025024689A1
Application number: PCT/US2024/039591
Authority: WO
Inventors: Zhibi Wang; Michel Roy; Kevin Di Lallo; Taimoor ABBAS
Original assignee: InterDigital Patent Holdings Inc
Current assignee: InterDigital Patent Holdings Inc
Priority date: 2023-07-26
Filing date: 2024-07-25
Publication date: 2025-01-30
Anticipated expiration: 2026-01-26

Abstract

A wireless transmit receive unit (WTRU) may send a first message to an edge configuration server (ECS). The first message may include a request for the ECS to issue a first authorization token. The first authorization token may be associated with transfer of an application context to a cloud application server. The WTRU may receive a second message from the ECS. The second message may include the first authorization token from the ECS and/or a validity duration of the first authorization token. The WTRU may send the first authorization token to a cloud enabler server (CES). The first authorization token may be used to indicate that the CES is authorized to accept WTRU related information. The WTRU may receive an application context relocation (ACR) response from the CES. The ACR response may indicate whether a context push operation was successful.

Description

AUTHORIZATION OF APPLICATION CONTEXT RELOCATION FROM EDGE DATA NETWORK (EDN) TO CLOUD

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001]This application claims the benefit of U.S. Provisional Patent Application No. 63/515,719 filed on July 26, 2023, the entire contents of which are incorporated herein by reference.

BACKGROUND

[0002] Edge computing is a distributed computing paradigm that may bring computation and/or data storage closer to the sources of data. This is expected to improve response times and/or save bandwidth. Edge computing is an architecture, a topology, and/or location-sensitive form of distributed computing. The edge application layer may enable applications to run on the edge.

SUMMARY

[0003] A wireless transmit/receive unit (WTRU) may send a first message to an edge configuration server (ECS). The first message may include a request for the ECS to issue a first authorization token. The first authorization token may be associated with transfer of an application context to a cloud authorization server. The WTRU may receive a second message from the ECS. The second message may include the first authorization token from the ECS and/or a validity duration of the first authorization token. The WTRU may send the first authorization token to a cloud enabler server (CES). The first authorization token may be used to indicate that the CES is authorized to accept WTRU related information. The WTRU may receive an application context relocation (ACR) response from the CES. The ACR response may indicate whether a context push operation was successful.

[0004] The WTRU may send the first authorization token to the CES via an edge enablement server (EES). The authorization token may indicate that the EES is authorized to transfer the WTRU related information to the CES.

[0005] The WTRU may send a notification to an application context indicating that the ACR has been completed. The first message may indicate the application context to be transferred to the CAS.

[0006] The first message further may include one or more of CES fully qualified domain name (FQDN), cloud authorization server FQDN, indication of user consent, indication of service continuity to the cloud authorization server, WTRU identification, application client (AC) identification, edge enablement server (EES) instance identification, edge application server (EAS) identification, and/or ECS instance identification.

[0007] The WTRU may receive an indication from an application context to perform ACR. The WTRU may receive a third message from the cloud authorization server comprising a second authorization token from the cloud authorization server. The WTRU may send the second authorization token to the CES to indicate that the WTRU consents to send the WTRU related information to the CES.

[0008] The WTRU may send the second authorization token to the CES via an edge enablement server (EES). The WTRU may include a WTRU identifier or application client (AC) identifier used by the CES to initiate the context push operation.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.

[0010] FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0011] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0012] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0013] FIG. 2 illustrates an architecture for enabling cloud application with edge applications. [0014] FIG. 3 illustrates a high-level overview of application context relocation (ACR).

[0015] FIG. 4 is an example push edge enabler client (EEC) context from the edge (e.g., from an edge data network (EDN)) to the cloud when ACR is EEC initiated.

[0016] FIG. 5 is an example push EEC context from the cloud to edge when ACR is EEC initiated.

[0017] FIG. 6A is an example EAS-ECS interaction with the cloud authorization server.

[0018] FIG. 6B is another example EAS-ECS interaction with the cloud authorization server.

[0019] FIG. 7 is an alternative mechanism of pushing EEC context from the edge (e.g., from an EDN) to the cloud when ACR is EEC initiated. DETAILED DESCRIPTION

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

[0021] As shown in FIG. 1A, the communications system 100 may comprise wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104/113, a CN 106/115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and/or a “STA”, may be configured to transmit and/or receive wireless signals and may comprise a user equipment (WTRU), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a headmounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a WTRU. The terms WTRU and user equipment (UE) may be used interchangeable herein. [0022] The communications systems 100 may also comprise a base station 114a and/or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106/115, the Internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may comprise any number of interconnected base stations and/or network elements.

[0023] The base station 114a may be part of the RAN 104/113, which may also comprise other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may comprise three transceivers, e.g., one for each sector of the cell. In an embodiment, the 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 desired spatial directions.

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

[0025] More specifically, as noted above, the communications 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, and the like. For example, the base station 114a in the RAN 104/113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA). WCDMA may comprise communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may comprise High-Speed Downlink (DL) Packet Access (HSDPA) and/or High-Speed UL Packet Access (HSUPA).

[0026] 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 establish the air interface 116 using Long Term Evolution (LTE) and/or LTE- Advanced (LTE-A) and/or LTE-Advanced Pro (LTE-A Pro).

[0027] 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 establish the air interface 116 using New Radio (NR).

[0028] 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, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., a eNB and a gNB).

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

[0030] The base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. 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 yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellularbased RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106/115. [0031] The RAN 104/113 may be in communication 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 varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106/115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104/113 and/or the CN 106/115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104/113 or a different RAT. For example, in addition to being connected to the RAN 104/113, which may be utilizing a NR radio technology, the CN 106/115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

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

[0035] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0036] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In an embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals. [0037] Although the transmit/receive element 122 is depicted in FIG. 1 B as a single element, the WTRU 102 may comprise any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may comprise two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0038] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may comprise multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11 , for example. [0039] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may comprise random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may comprise a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0040] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the 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 comprise one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

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

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

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

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

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

[0046] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0047] The CN 106 shown in FIG. 1C may comprise a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator. [0048] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve 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 particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA.

[0049] The SGW 164 may be connected to each of the eNode 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 user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0050] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. [0051] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may comprise, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may comprise other wired and/or wireless networks that are owned and/or operated by other service providers.

[0052] Although the WTRU is described in FIGS. 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network. [0053] In representative embodiments, the other network 112 may be a WLAN.

[0054] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication. [0055] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in in 802.11 systems. For CSMA/CA, the STAs (e.g., every ST A), including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0056] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

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

[0058] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11 ah relative to those used in 802.11 n, and 802.11ac. 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 Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths. The MTC devices may comprise a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0059] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11 ah, comprise a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0060] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code. [0061] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0062] The RAN 113 may comprise gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may comprise any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each comprise one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a. 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, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).

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

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

[0065] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

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

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

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

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

[0070] The CN 115 may facilitate communications with other networks. For example, the CN 115 may comprise, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may comprise other wired and/or wireless networks that are owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b. [0071] In view of Figures 1A-1 D, and the corresponding description of Figures 1A-1D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.

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

[0073] The one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e.g., which may comprise one or more antennas) may be used by the emulation devices to transmit and/or receive data.

[0074] Herein described are systems and/or methods for application context relocation. A wireless transmit/receive unit (WTRU) may enter an area without edge coverage (e.g., an area without EDN services availability). The WTRU may allow service continuity to a cloud. The WTRU may request a cloud service continuity (CSC) token from an edge configuration server (ECS). The WTRU may receive from the ECS a CSC token. The WTRU may request service continuity to the cloud. The request may comprise the CSC token indicating that an edge enabler server (EES) is authorized to transfer WTRU-related information to the cloud. The WTRU may authorize service continuity to the cloud.

[0075] The WTRU may indicate, to the EES, to send the CSC token to a cloud enabler server. The authorization may comprise sending the CSC token to a cloud enabler server (CES) to indicate that the CES is authorized. The requesting may comprise providing one or more of the following: a cloud enabler server (CES) fully qualified domain name (FQDN), a could authorization server FQDN, an indication of user consent, an indication of service continuity to the cloud, a WTRU identification, an application client (AC) identification, an EES instance identification, an ECS identification, and/or an edge application server (EAS) instance identification.

[0076] Described herein are solutions useful in application context transfer (ACT) procedures from the edge (e.g., from an EDN) data network (EDN) to cloud when there is no coverage when a WTRU is performing mobility from EDN to cloud or from cloud to the EDN.

[0077] When the WTRU enters an area without edge coverage (e.g., an area without EDN services availability), the edge enabler client (EEC), EES, and/or EAS may trigger service continuity. The WTRU (e.g., AC and/or EEC) may allow service continuity to cloud. The AC may provide a CES/ cloud authorization server fully qualified domain names (FQDNs). The WTRU may request the CSC token from the edge (e.g., from an EDN) configuration server (ECS) (e.g., the mobile network operator (MNO) edge authorization server), and may provide the CES FQDN, cloud authorization server FQDN, indication of user consent, indication of service continuity to the cloud, WTRU identification, AC identification, EES instance identification, ECS identification, and/or EAS instance identification.

[0078] The ECS may negotiate access authorization to CES with the cloud authorization server. The ECS may formulate CSC token with claims and/or scope for service continuity authorization, including information provided in the request and CES access authorization. The ECS may send the CSC token to the WTRU. The WTRU may authorize service continuity to the cloud by sending the CSC token to the CES, indicating that the CES is authorized to accept WTRU related information. The CES may validate the CSC token for the application context transfer and CES access authorization. The WTRU may authorize and request service continuity to the cloud to the EES. The request may comprise the CSC token indicating that the EES is authorized to transfer WTRU related information to the cloud. The EES may validate the CSC token. The EES may use the CSC token to initiate an EEC context transfer to the CES. [0079] Described herein are procedures that enable an edge enabler client (EEC) to authorize the transfer of specific instances of context from a source edge enabler server (S-EES) to a target cloud enabler server (T-CES). These procedures may ensure that context information associated with the EEC is only sent to a T-CES authorized to receive the context and/or the S- EES is authorized to access the T-CES in the cloud.

[0080] Herein described are solutions regarding application context transfer (ACT) procedures from the edge (e.g., from an EDN) data network (EDN) to cloud. The solutions further consider when a WTRU is mobile and/or moves from cloud to EDN and there is no coverage.

[0081] Herein discussed are the use of tokens to authorize a transfer for an edge enablement client (EEC) context from a source edge enabler server (S-EES)/source edge application server (S-EAS) to a target cloud enabler server (T-CES)/target cloud authorization server (T-cloud authorization server), or vice versa. The token may be an OAuth 2.0 Access Token. An authorization server in EDN and an authorization server in the cloud may collaborate to generate the token. Additionally or alternatively, a token issued by one or both of the authorization servers may be exchanged with a security token service (STS) server for a token that the S-EES may use. The S-EES may use the STS so the T-CES may authorize the S-EES in the cloud for the access authorization and/or application context relocation (ACR) authorization. The servers may be an ECS for EDN and/or a cloud authorization server. In a scenario where the token is an OAuth 2.0 Access Token, the servers (e.g., ECS and/or cloud authorization server) that collaborate to generate the token may also be called authorization servers. The CES and cloud authorization server are both cloud servers. The CES and cloud authorization server may be combined and/or referred to more generally as a cloud server. [0082] Discussed herein is a description of how an EEC may authorize the transfer of context information from a mobile network operator (MNO) edge domain (e.g., S-EES/S-EAS) to a target cloud domain (e.g., T-CES/T-cloud authorization server), or vice versa. Authorization is a type of consent. Described herein is how a WTRU (e.g., EEC or AC) may provide consent to transfer of user contextual information from a S-EES/S-EAS to a T-CES/T- cloud authorization server, or vice versa. Since an EEC or AC is a type of user application (e.g., an application controlled by a human), this type of consent may be called user consent.

[0083] In the 3rd Generation Partnership Project (3GPP) standard, the ACT may refer to application context. However, the description herein focuses on EEC context transfer between EES and/or CES. This description applies to both the application context transmission and the EEC context relocation. Therefore, a generic terminology of ACR procedure is used in this description for both procedures.

[0084] FIG. 2 illustrates a SA6 architecture 200 for enabling cloud application with edge applications. The SA6 architecture is defined in 3GPP TS 23.558 V18.3.0 (2023-6) “Architecture for enabling Edge Applications” and an example of the high-level architecture is shown in FIG. 2. Disclosed herein are examples of application layers for supporting edge services.

[0085] The main components of the SA6 Architecture are described below. Residing on a WTRU 202 is an application client (AC) 204. that the AC may communicate with an edge application server (EAS) 206. A WTRU may use one or more ACs 204 concurrently. An edge application server EAS 206 is an application server resident in an edge data network (EDN) 208. An EDN 208 may be a software server executing on generic hardware located at the edge and providing a service to the AC 204. An EDN may be a decentralized DN located within the MNO’s network in proximity to WTRUs. In the context of a mobility and/or relocation use case, the source-EAS (S-EAS) may be an instance of an EAS 206 in an initial location and serving the AC 204 before mobility/relocation happens. The target-EAS (T-EAS) may be an instance of an EAS 206 in a destination location and/or serving the AC 204 after mobility and/or relocation has happened. There may be one or more EAS 206 instances per EDN 208. Each EDN 208 may contain a different set of EAS 206 instances of different types (e.g., different EAS IDs); an EAS 206 may serve one or more AC 204 instances that may reside on different WTRUs 202.

[0086] An edge enabler client (EEC) 210 provides edge support to the AC 204 instances on the WTRU 202. There may be one or more EEC 210 per WTRU 202. Each AC 204 may use only one EEC. An edge enabler server (EES) 212 may provide supporting functions needed by EAS 206 and EEC 210. In the context of a mobility and/or relocation use case, the source-EES (S- EES) is the EES 212 used before mobility and/or relocation happens. The target-CES (T-CES) is the CES 214 used after mobility and/or relocation has happened. There may be one or more EES 212 instance per EDN 208 (or per data network name (DNN)). There may be multiple EDN 208 instances in the network. An edge configuration server (ECS) 216 may provide supporting functions for an EEC 210 or EES 212 to discover EES 212 instances providing a certain EAS 206. There may be one or more ECS 216 for the network. A CES 214 may provide supporting functions needed for a cloud application server (CAS) 218. The CES 214 is part of the edge enablement layer (EEL) 220 and does not have service area restriction. The CES 214 may facilitate service continuity between the EAS 206 and the cloud application server 218. A cloud application server 218 is the application server resident in the cloud performing the server functions. The AC 204 may connect to the cloud application server 218 to avail the services of the application.

[0087] FIG. 3 illustrates a high-level overview 300 of application context relocation (ACR). 3GPP TS 23.558 V18.3.0 (2023-6) “Architecture for enabling Edge Applications” defines service continuity procedures in the EEL for transferring an application context from a S-EAS to a T- cloud authorization server. The context transfer may be triggered for example by WTRU movement as well as non-mobility events such as, e.g., EAS server maintenance, overload, etc. The purpose of service continuity is to minimize edge service interruption to the ACs executing on the WTRU.

[0088] Service continuity for applications requiring context relocation specified by the EEL may be composed of 4 different phases: detection, decision, execution, and/or post-execution. ACR scenarios may specify different EEL entities (e.g., EEC, EES, and/or EAS) for the detection and/or decision phases (e.g., a detection entity and a decision-making entity), and different sets of interactions between EEL entities for the execution phase.

[0089] At 304, as specified in 3GPP TS 23.558 V18.3.0 (2023-6) “Architecture for enabling Edge Applications,” the detection entity monitors WTRU location and/or movement and informs the decision-making entity. At 308, the decision-making entity then may determine whether to employ an ACR. At 308, if deploying the ACR, the decision-making entity may then command the execution entity to perform ACR. At 312, the execution entity may then run the ACR procedures defined in the service continuity scenarios to transfer the application context from the S-EAS to the T-cloud authorization server. At 316, when ACR execution completes, ACR cleanup may then be performed.

[0090] Under Rel-17 service continuity, when a WTRU may move to a new location, a different EAS, EES, and/or EDN may be more suitable for serving the WTRU. Under Rel-18 service continuity: when no EAS, EES, and/or EDN are available in the destination area, the cloud application server (CAS) and/or the CES may result in EEC context and/or ACR to the cloud. The inverse operation may also be possible when a WTRU enters an edge coverage (e.g., an area without EDN services availability) area again. Edge computing elements and the cloud may be in different trust domains. Cross-domain access authorization and/or service continuity consent may be coordinated. A collaboration between the authorization servers in these domains may be needed. Service continuity from and/or to the cloud may involve context relocation to servers in a location with different jurisdiction laws, rules, and/or policies. The WTRU may decide SA6 Rel-18 service continuity to the cloud. The WTRU may decides whether to move to the cloud. The WTRU may provide the cloud information to the EEL. [0091] An EEC and/or AC are applications hosted on a WTRU. An EEC context is information related to the EEC and/or AC that is hosted in the network. An EES at the edge and/or a CES in the cloud may host the EEC context information. EEC context may comprise sensitive information such as the WTRU identity, WTRU location, a list of associated AC profiles, service session context information, and/or other information. The EEC context information may be relocated from a S-EES and/or S-CES to a T-EES and/or T-CES during ACR procedures. [0092] EEL enhancements are desired so that an EEC may authorize and/or consent to the transfer of the EEC context from the S-EES to the T-CES during mobility from the edge (e.g., from an EDN) to the cloud. Edge and the cloud may belong to different trust domains and/or may be operated by different domain owners. Different authorization servers may be responsible for the authorization within each domain. The ACR from edge to the cloud or from cloud to the edge (e.g., to the EDN) may require authorization from authorization servers of both domains. The authorization may comprise a specific transfer operation. The specific transfer operation may be part of a specific ACR procedure. Further, the WTRU may decide to transfer a service from the edge (e.g., from an EDN) to the cloud. In other words, the WTRU (e.g., EEC and/or AC) may separately (e.g., individually) decide and/or authorize all EEC context transfers from a S-EES to a T-CES corresponding to the WTRU, EEC, and/or AC should be separately even if the WTRU is not involved in the selection of the T-CES or in the EEC context transfer.

[0093] During the EEC context relocation from the S-EES in the edge to the T-CES in the cloud, the S-EES is the EEC context holder and the EEC client is the information owner. Therefore, the EEC may authorize information transfer from the S-EES to the T-CES. In this case, the ECS may play the role of authorization server for the ACR procedure and/or issue the authorization token. The authorization server in the cloud may be responsible for the access authorization to the T-CES by the entity outside the cloud infrastructure, (e.g., the S-EES) and the authorization of the T-CES to receive the EEC context. Hence, the two authorization servers ECS and cloud authorization server may collaborate to successfully allow execution of the procedure of ACR from the edge (e.g., from an EDN) to the cloud.

[0094] Based on this decision, it may be understood that mechanisms enabling cross-domain communication (e.g., application programming interface (API) access) authorization between EES/EAS and CES/CAS may be undefined. In additional examples, mechanisms enabling cross-domain user (e.g., WTRU, AC, and/or EEC) consent to transfer context information (e.g., WTRU ID, WTRU location, etc.) across domains (e.g., mobile network operator (MNO) and/or cloud) may be undefined. In additional examples, mechanisms for enabling collaboration between an MNO edge authorization server and/or a cloud authorization server may be undefined.

[0095] Further described herein is the authorization of ACR between edge and cloud using tokens negotiated between the ECS and the cloud authorization server.

[0096] Example solutions described herein are each useful in application context transfer (ACT) procedures resulting from WTRU mobility. The ACT may be from EDN to the cloud when there is no edge coverage (e.g., an area without EDN services availability) or from cloud to EDN.

[0097] The WTRU may enter an area without edge coverage (e.g., an area without EDN services availability), and the EEC, EES, and/or EAS may trigger service continuity. The WTRU (e.g., AC and/or EEC) may allow service continuity to cloud and the AC provides a CES fully qualified domain name (FQDN). The WTRU may request the cloud service continuity (CSC) token from the ECS (e.g., the MNO EAS), and may provide the CES FQDN, cloud authorization server FQDN, indication of user consent, indication of service continuity to the cloud, WTRU identification, AC identification, EES instance identification, ECS identification, and/or EAS instance identification. The ECS may negotiate access authorization to CES with the cloud authorization server. The ECS may formulate CSC token with claims and/or scope for service continuity authorization, including information provided in the request and/or CES access authorization. The ECS may send the CSC token to the WTRU.

[0098] The WTRU may authorize service continuity to the cloud by sending the CSC token to the CES to indicate that the CES may be authorized to accept WTRU related information. The CES may validate the CSC token for the application context transfer and/or CES access authorization. The WTRU may then authorize and/or request service continuity to the cloud to the EES. The request may comprise the CSC token indicating that the EES may be authorized to transfer WTRU related information to the cloud. The EES may validate the CSC token. The EES may uses the CSC token to initiate an EEC context transfer to the CES. If the WTRU did not send the CSC token to the CES at 316 of FIG. 3, and/or if the WTRU indicates to the EES to send the CSC token to the CES, then the EES may comprise the CSC token in the EEC context transfer request sent to the CES to indicate to the CES that CES is allowed to receive the WTRU related information. [0099] FIG. 4 is an example 400 push EEC context from the edge (e.g., from an EDN) to the cloud when ACR is EEC initiated. FIG. 4 illustrates an example procedure for EEC authorization of EEC context transfer in a scenario where an AC starts an ACR procedure that in turn triggers the EEC. The procedure may further comprise pushing the EEC context from the S-EES to the T-CES.

[0100] Described herein are examples of an authorization of push EEC context transfer when the ACR transfers from edge to cloud and is EEC initiated. The example procedure 400 further illustrates EEC authorization of EEC context transfer to the CES in a cloud. The AC initiates this ACR that triggers the EEC. The procedure may further comprise that the EEC context be pushed from the S-EES to the T-CES. The EEC requests, from the ECS, authorization tokens for ACR and/or access authorization to the CES on behalf of the S-EES. The EEC may then send the tokens to the S-EES.

[0101] As the EEC context owner, the WTRU, EEC, and/or AC may decide and/or authorize the information transfer from the S-EES to the T-CES. In this case, the ECS may play the role of authorization server for the ACR procedure and/or issue the authorization token. The authorization server in the cloud may be responsible for the access authorization and the resource access authorization to the T-CES by the clients outside the cloud infrastructure, (e.g., the S-EES). Hence, the two authorization servers ECS and/or cloud authorization server may collaborate with each other to successfully execute the procedure of ACR from the edge (e.g., from an EDN) from the edge (e.g., from an EDN) (e.g., from an EDN) to the cloud.

[0102] At 404, the AC may indicate to the EEC that ACR is needed. The EEC may alternatively detect that ACR is needed, or the network may inform the EEC (e.g., EES and/or EAS) that ACR is needed. For example, a mobility event may have triggered the ACR. As a result of mobility there may not be edge service coverage in the new WTRU location. The EEC may decide to perform ACR to cloud and/or the EEC may be provided, may obtain, and/or may request FQDNs of the T-CES and/or T-cloud authorization server from the AC.

[0103] At 408, the EEC may send a request to the ECS, (e.g., a service provisioning request). The EEC may indicate in the request that the CES and/or cloud authorization server FQDNs. The request may indicate that the EEC authorizes the transfer of the EEC context to the cloud and/or may indicate that the ECS needs to issue an authorization token and/or provide the issued token in the response to the EEC.

[0104] The request may comprise the identities of the S-EES and/or the T-CES, and/or the FQDN of the CAS. The request may indicate that access authorization to the CES is needed. The request may identify the context to be transferred. The EEC context ID and/or a combination of identities which comprises the AC ID, EEC ID or WTRU ID, FQDN of S-EAS endpoint, and/or T-cloud authorization server endpoint may identify the context. The context may be identified because multiple ACR procedures for the same EEC (WTRU), S-EES, and/or T-CES may take place simultaneously. The request may also comprise a requested token validity duration time that indicates to the server that it should consider the token valid only for the indicated time duration.

[0105] At 412, the ECS may receive the request from the EEC. The ECS may check the authorization of the EEC and/or validate the information in the request. The ECS may validate the EEC ID and/or the S-EES ID using information provided by the EEC at 408. If the EEC also requests for the CES access authorization on behalf of the S-EES, the ECS may send a delegate request to the cloud authorization server based on the cloud authorization server FQDN provided in the request or local configuration.

[0106] At 416, the cloud authorization server may be responsible for the access authorization to the T-CES by CES clients (e.g., the S-EES). The cloud authorization server may issue a token that the S-EES may use to access the T-CES. The token may also indicate that the T-CES is allowed to accept context information provided by the S-EES. The cloud authorization server may issue and/or digitally sign the T-CES access authorization and/or context information transfer token (e.g., a first token). The T-CES may be provided to the ECS in the delegate response. Upon receiving the response, the ECS may issue and/or digitally sign an ACR authorization token (e.g., a second token) to authorize the EEC to request ACR to cloud with the EES. This step may further comprise steps and/or information in the interaction between the EAS, ECS, and/or cloud authorization server. Moreover, both tokens may be combined to form a composite token.

[0107] At 420, the ECS server may respond to the EEC including the first and/or the second authorization tokens. The response may comprise the associated claims and/or scopes as well as token validity duration that may indicate how long the server will consider the token to be valid.

[0108] At 424, the EEC may initiate the ACR procedure by sending an ACR request to the S- EES. The request may comprise the first and/or second authorization tokens. The S-EES may use the first authorization token (e.g., issued by the cloud authorization server) to access the T- CES. The S-EES may use the first authorization token to indicate to the T-CES that the T-CES is authorized to accept the EEC context. The second authorization token (e.g., issued by the ECS) may indicate consent of the WTRU, EEC, and/or AC for sending the EEC context to the T- CES. The request also may comprise information (e.g., EEC Context ID or AC ID, EEC ID or WTRU ID, S-EAS endpoint, and/or T-cloud authorization server endpoint) that the S-EES may use to start the EEC context relocation procedure.

[0109] At 428, after the request from the S-EES request is validated, the S-EES may send an ACR response message to the EEC. The S-EES may reject the request and/or include a cause code that identifies the reason for the rejection. For example, the S-EES may determine that the authorization token was not comprised in the ACR Request; not properly formatted (e.g. the authorization token is not associated with the identified T-CES); that the token is expired; and/or that the token is not associated with the context to be transferred. If the S-EES has not yet provided a response, the S-EES may proceeds to the next step in the procedure.

[0110] The S -EES may send an EEC context push to the identified T-CES. The EEC context push may include the first authorization token to allow CES access authorization and/or the ACR authorization.

[0111] At 432, the T-CES may validate the token for T-CES access authorization and/or the ACR authorization. The T-CES may contact the cloud authorization server to validate the received token. The T-CES may also validate if the scope of the context information allows the T-CES to accept the provided information. If the scope of the context information does not match with the provided token, then the T-CES may not accept the provided context information.

[0112] At 436, the T-CES may send an EEC context push response message to the S-EES and/or indicate success or failure of the context relocation. If the failure is due to an invalid token, the T-CES may inform the S-EES that the token is not valid and the T-CES may include a reason for it being invalid (e.g., the token is expired, invalid scope, etc.).

[0113] At 440, the S-EES may send an ACR response to the EEC indicating if the context push operation was successful or unsuccessful. If the push was unsuccessful, the S-EES may indicate why the operation was unsuccessful.

[0114] At 444, the EEC may indicate to the AC that the ACR has been completed. The EEC may indicate whether the ACR was successful or not. The response from the S-EES may trigger the EEC to send this request.

[0115] FIG. 5 is an example push EEC context 500 from the cloud to edge when ACR is EEC initiated. FIG. 5 illustrates an example procedure for EEC authorization of EEC context transfer in a scenario where an AC starts the ACR procedure is started by the AC that in turn triggers the EEC. The procedure may further comprise pushing the EEC context from the S-CES to the T-EES. [0116] Described herein are examples of an authorization of push EEC context transfer when the ACR transfers from cloud to edge and is EEC initiated. The example procedure for EEC authorization of EEC context transfer from the CES in a cloud to an EES in the edge. The EEC context may transfer from CES to EES when a WTRU leaves an area without edge capabilities and enters an area with edge capabilities. The AC may initiate the ACR procedure that triggers the EEC, e.g., by the discovery of edge capabilities when a mobility event happens. The procedure may comprise that the EEC context be pushed from the S-CES to the T-EES. The EEC may trigger an ACR procedure after discovering edge availability (e.g., possibly obtaining services from an EDN), may decide to use an application instance present at the edge, may request authorization token for authorizing ACR and provide access authorization to the EES on behalf of the S-CES from the ECS, and/or may send the token to the S-CES in the ACR request message.

[0117] As the EEC context owner, the EEC may authorize information transfer from the S-CES to the T-EES. In this case, the cloud authorization server plays the role of authorization server for the ACR procedure and issues the authorization token. The authorization server in the edge trust domain may be responsible for the access authorization to the T-EES by the S-CES client. Hence, the two authorization servers, cloud authorization server and ECS, may collaborate to successfully provide authorization tokens necessary for executing ACR procedure from cloud to edge.

[0118] At 504, the AC may indicate to the EEC that ACR is needed. The EEC may alternatively detect that ACR or the network may inform (e.g., EES and/or EAS) that ACR is needed. For example, a mobility event may have triggered the ACR. As a result of mobility there may be edge service coverage in the new WTRU location. The EEC may decide to perform ACR to the edge (e.g., from an EDN). The EEC may be provided, may obtain and/or may request FQDNs of the T-EES and/or T-EAS, e.g., by performing service provisioning, EAS discovery procedures, and/or by being notified by the network of T-EES and/or T-EAS availability.

[0119] At 508, the EEC may send a request to the cloud authorization server and/or may indicate in the request the EES and/or EAS FQDNs. The request may indicate that the EEC authorizes the transfer of the EEC context to the edge (e.g., from an EDN). Further, the request may indicate that the cloud authorization server needs to issue an authorization token and/or provide the issued token in the response to the EEC.

[0120] The request may include the identities of the S-CES, the T-EES, the FQDN of the edge authorization server (e.g., ECS). The request may indicate that access authorization to the edge (e.g., from an EDN) is needed. The request may identify the context to be transferred. The EEC context ID and/or a combination of identities which comprises the AC ID, EEC ID or WTRU ID, FQDN of source cloud application server (S-CAS) endpoint and/or T-EAS endpoint may identify the context. The context may be identified because multiple ACR procedures for the same EEC (WTRU), S-CES, and/or T-EES may take place simultaneously. The request may also comprise a requested token validity duration time that indicates to the server that it should consider the token valid only for the indicated time duration.

[0121] At 512, the cloud authorization server may receive the request from the EEC. The cloud authorization server may check the authorization of the EEC and/or validate the information in the request. The cloud authorization server may validate the EEC ID and/or the S-CES ID using information provided by the EEC at 508. If the EEC also requests for the EES access authorization on behalf of the S-CES, then the cloud authorization server may send a delegate request to the ECS based on the ECS FQDN provided on the request and/or local configuration. [0122] At 516, the ECS is responsible for the access authorization to the T-EES by the EES clients (e.g., the S-CES). The ECS may issue a token that the S-CES may use to access the T- EES. The token may also indicate that the T-EES is allowed to accept context information provided by the S-CES. The ECS may issue and/or digitally sign the T-EES access authorization and/or context information transfer token (e.g., a first token). The T-EES may be provided to the cloud authorization server in the delegate response. Upon receiving the response, the cloud authorization server may issue and/or digitally signs an ACR authorization token (e.g., a second token) to authorize the EEC to request ACR to edge with the S-CES. This step may comprise steps and/or information in the interaction between the EAS, ECS, and cloud authorization server. Moreover, both tokens may be combined to form a composite token.

[0123] At 520, the cloud authorization server may respond to the EEC including the first and/or second authorization tokens. The response may comprise associated token claims and/or scopes as well as validity duration that may indicate how long the server will consider the token to be valid.

[0124] At 524, the EEC may initiate the ACR launching procedure by sending an ACR request to the S-CES. The request may comprise the first and/or the second authorization tokens. The S-CES may use the first authorization token (e.g., issued by the ECS) to access the T-EES. The S-CES may indicate to the T-EES that the T-EES is authorized to accept the EEC context. The second authorization token (e.g., issued by the cloud authorization server) may indicate consent of the WTRU, EEC, and/or AC for sending the EEC context to the T-EES. The request may also comprise information (e.g., EEC Context ID or AC ID, EEC ID, and/or WTRU ID the S- CES may use to start the EEC context relocation procedure). [0125] At 528, after the request from the S-CES request is validated, the S-CES may send an ACR response message to the EEC. The S-CES may reject the request and/or include a cause code that identifies the rejection. For example, the S-CES may determine that the authorization token was not included in the ACR request; not properly formatted (e.g. the authorization token not associated with the identified S-CES); that the token is expired; and/or that the token is not associated with the context to be transferred. If the S-EES has not yet provided a response, the S-CES may proceeds to the next step in the procedure.

[0126] The S -CES may send an EEC context push to the identified T-EES. The EEC context push may include the first authorization token to allow T-EES access authorization and/or the ACR authorization.

[0127] At 532, the T-EES may validate the token for T-EES access authorization and/or the ACR authorization. The T-EES may contact the ECS to validate the received token. The T-EES may also validate if the scope of the context information allows the T-EES to accept the provided information. If the scope of the context information does not match with the provided token, then the T-EES may not accept the provided context information.

[0128] At 536, the T-EES may send an EEC Context Push Response message to the S-CES and indicate success or failure of the context relocation. If the failure is due to an invalid token, the T-EES may inform the S-CES that the token is not valid and the T-EES may include a reason for it being invalid (e.g., it is expired, invalid scope, etc.).

[0129] At 540, the S-CES may send an ACR response to the EEC indicating if the context push operation was successful or unsuccessful. If the push was unsuccessful, the S-CES may indicate why the operation was unsuccessful.

[0130] At 544, the EEC may indicate to the AC that the ACR has been completed. The EEC may indicate whether the ACR was successful or not. The response from the S-CES may trigger the EEC to send this request.

[0131] FIG. 6A is an example EAS and/or ECS interaction 600 with the cloud authorization server. FIGs. 6A and 6B illustrate an example procedure for the interaction of EES and/or ECS and cloud authorization server for a scenario where the AC may start an ACR procedure that in turn triggers the EEC and/or the procedure comprises that EEC context be pushed from the S- EES to the T-CES. The authorization interaction of two authorization servers for the ACR push from the S-CES to the edge (e.g., from an EDN) T-EES associated with H H H ^is similar and not duplicated in this disclosure.

[0132] Described herein are examples of server collaboration between the ECS in the edge and the cloud authorization server. FIG. 6A illustrates an example procedure where the EAS (e.g., ECS) delegates the token request from the EEC to the cloud authorization server to issue the composite token that the S-EES may use for cloud access authorization and/or ACR authorization of the EEC context from the S-EES to the T-CES.

[0133] At 604, the EEC may send a request to the ECS to obtain the ACR authorization token. The request may include the FQDN of T-CES, FQDN of T-cloud authorization server, cloud authorization server identity, S-EES identity, S-EAS identity, an indication that the context transfer to the cloud is consented, and/or an indication that access tokens to the T-CES is needed by the S-EES. The authorization token may authorize the transfer of the EEC context from a S-EES to a T-CES. The request may also identify the context to the transferred.

[0134] At 608, ECS may validate the ACR requests and decide the authorization mechanisms for CES. ECS may generate the authorization token to be included in the EEC ACR request to the S-EES. The token may also include information (e.g., EEC context ID or AC ID, EEC ID or WTRU ID the S-EES may use to identify the EEC context to transfer as part of the ACR procedure.

[0135] At 612, ECS may send the delegate ACR authorization request to the cloud authorization server to obtain access tokens on behalf of the S-EES. The S-EES may use this in the request to push the EEC context to the T-CES. The cloud authorization server may digitally sign the token. The token authorizes the S-EES to access the T-CES for transferring the EEC context. The token may indicate that the T-CES is allowed to accept the incoming context.

[0136] At 616, the cloud authorization server may validate the ACR requests. If the request is validated, the cloud authorization server may generate the ACR authorization token for the S- EES to authorize the EEC context transfer to the T-CES. The authorization token may further comprise the cloud access authorization for the S-EES to access CES. The token may comprise the S-EES ID, the EEC context ID or AC ID, and/or EEC ID (or WTRU ID), that the T-CES may use to identify the EEC context to transfer as part of the ACR procedure.

[0137] At 620, the cloud authorization server may respond to the token request from the ECS. The cloud authorization server may delegate the ACR authorization response. This may include a token that the S-EES may use to access the cloud server and ACR procedure between the S- EES and/or the T-CES.

[0138] At 624, the ECS may respond to the EEC request including the token received from the cloud authorization server (e.g., the first token) and/or the token issued by ECS (e.g., the second token). The first token may be for S-EES to access CES access and/or authorize the context transfer to the CES. The second token may be for the ACR authorization token used in the EEC request to the S-EES to trigger ACR launching procedure. Solutions disclosed herein may deal with a collaboration between the ECS and the cloud authorization server.

[0139] In examples, the ECS may serve as the edge authorization server. Depending on deployment, the cloud authorization server and/or the CES may be different server entities. The cloud authorization server and CES may combine as a single server entity performing both functions. The description herein assumes the case of different server entities but may function with a combined cloud authorization server/CES server as well.

[0140] The ECS may receive the EEC request for ACR authorization from the S-EES to the T- CES. The request may comprise FQDNs of T-CES, T-cloud authorization server, cloud authorization server identity, S-EES, S-EAS and/or the authorization of T-CES access in the cloud on behalf of the S-EES. The request may identify the context to be transferred. An EEC Context ID and/or a combination of identifiers which may comprise AC ID, EEC ID, WTRU ID may identify the context. The request may comprise a requested token validity duration time. The requested token validity time may indicate to the server that it should consider the token valid only for the indicated time duration.

[0141] The request may indicate requested authorization limitations. The requested authorization limits may indicate limits on which T-CES may be authorized with the token. The limits may indicate specific T-CES that may be authorized with the token. The limits may indicate the T-CES instance identified by the FQDN, a T-CES type of certain types, a T-CES type associated with specific service providers, and/or that a T-CES in certain locations may be authorized with the token.

[0142] The request may indicate which T-CES(s) may not be authorized with the token. The ECS may validate the ACR authorization request and/or decide the authorization mechanisms for the ACR from the S-EES to the T-CES. The ECS may use pre-configured information and/or may send a request to the cloud authorization server to discover supported authorization mechanisms. The ECS may generate an authorization token (e.g., the first token) for authorizing ACR from the S-EES to the T-CES. The first token authorizes the S-EES to transfer the EEC context to the T-CES located in the cloud. The token may comprise a token validity duration that indicates how long the server will consider the token to be valid. The first token may comprise information (e.g., EEC context ID or AC ID, an EEC ID, and/or a WTRU ID that may identify the EEC context to be transferred as part of the ACR procedure).

[0143] The ECS may send a delegate token request (e.g., on behalf of the S-EES) to the cloud authorization server. The delegate token request may request a cloud access and/or authorization token (e.g., the first token). The first token may authorize the CES to accept EEC context information transfer from the S-EES and/or provide CES access authorization. The cloud authorization server may digitally sign the first token. The S-EES may use the first token when pushing the EEC context to the T-CES. The request from the S-EES may comprise the authorization token, the token validity duration, and/or the authorization limits that apply to the token. The ECS may receive the first token issued by the cloud authorization server. The ECS may respond to the EEC request and/or provide the first and/or second authorization tokens. The first token may be provided to the S-EES to access CES and/or authorize the T-CES to accept the context information from the S-EES. The second token may be provided to the EEC to be used in the EEC request to the S-EES. In this case, the S-EES may authorize the EEC request to transfer the context information toward the T-CES.

[0144] The cloud authorization server may receive the delegate token request from the ECS for the ACR and cloud access authorization. The cloud authorization server may validate the information in the request from the ECS. If the request is validated, the cloud authorization server may generate the ACR authorization token for the T-CES to accept the context information from the S-EES. The token may also authorize the S-EES to access APIs of the T- CES. The token may comprise S-EES ID, the EEC Context ID and/or AC ID, EEC ID and/or WTRU ID. The T-CES may use this information to identify the EEC context that may be transferred from the S-EES as part of the ACR procedure. The cloud authorization server may respond to the delegate token request from the ECS with tokens that the S-EES may use to access the T-CES.

[0145] FIG. 6B is another example edge authorization server-ECS interaction 650 with the cloud authorization server. At 654, the EEC may send a request to the ECS to obtain the ACR authorization token. The request may include the FQDN of T-CES, FQDN of T-cloud authorization server, cloud authorization server identity, S-EES identity, S-EAS identity, an indication that the context transfer to the cloud is consented, and/or an indication that access tokens to the T-CES is needed by the S-EES. The authorization token may authorize the transfer of the EEC context from a S-EES to a T-CES. The request may also identify the context to the transferred.

[0146] At 658, ECS may validate the ACR requests and decide the authorization mechanisms for CES. ECS may generate the authorization token to be included in the EEC ACR request to the S-EES. The token may also include information (e.g., EEC context ID or AC ID, EEC ID or WTRU ID the S-EES may use to identify the EEC context to transfer as part of the ACR procedure. [0147] At 662, ECS may send the delegate ACR authorization request to the cloud authorization server to obtain access tokens on behalf of the S-EES. The S-EES may use this in the request to push the EEC context to the T-CES. The cloud authorization server may digitally sign the token. The token authorizes the S-EES to access the T-CES for transferring the EEC context. The token may indicate that the T-CES is allowed to accept the incoming context.

[0148] At 666, the cloud authorization server may validate the ACR requests. If the request is validated, the cloud authorization server may generate the ACR authorization token for the S- EES to authorize the EEC context transfer to the T-CES. The authorization token may further comprise the cloud access authorization for the S-EES to access CES. The token may comprise the S-EES ID, the EEC context ID or AC ID, and/or EEC ID (or WTRU ID), that the T- CES may use to identify the EEC context to transfer as part of the ACR procedure.

[0149] At 670, the cloud authorization server may respond to the token request from the ECS. The cloud authorization server may delegate the ACR authorization response. The ACR authorization response may include a token. The S-EES may use the token to access the cloud server and/or ACR procedure between the S-EES and/or the T-CES.

[0150] At 674, the ECS may respond to the EEC request including the token received from the cloud authorization server (e.g., the first token) and/or the token issued by ECS (e.g., the second token). The first token may be for S-EES to access CES access and/or authorize the context transfer to the CES. The second token may be for the ACR authorization token used in the EEC request to the S-EES to trigger an ACR launching procedure. Examples disclosed herein may deal with a collaboration between the EAS and the cloud authorization server.

[0151] In examples, the ECS may serve as the EAS. Depending on deployment, the cloud authorization server and/or the CES may be different server entities. The cloud authorization server and CES may combine as a single server entity performing both functions. The description herein assumes the case of different server entities but may function with a combined cloud authorization server /CES server as well.

[0152] The ECS may receive the EEC request for ACR authorization from the S-EES to the T- CES. The request may comprise FQDNs of T-CES, T-cloud authorization server, cloud authorization server identity, S-EES, S-EAS and/or the authorization of T-CES access in the cloud on behalf of the S-EES. The request may identify the context to be transferred. An EEC Context ID and/or a combination of identifiers which may comprise AC ID, EEC ID, WTRU ID may identify the context. The request may comprise a requested token validity duration time. The requested token validity time may indicate to the server that it should consider the token valid only for the indicated time duration. [0153] FIG. 7 is an alternative mechanism 700 of pushing EEC context from the edge (e g., from an EDN) from the edge (e.g., from an EDN) (e.g., from an EDN) to the cloud when ACR is EEC initiated. FIG. 7 illustrates an alternative procedure shown in FIG. 5 for EEC authorization of EEC context transfer. In the scenario depicted in FIG. 7, an AC may start an ACR procedure that in turn triggers the EEC. The procedure may comprise that EEC context be pushed from the S-CES to the T-EES. The ACR authorization token from the EEC request to the S-CES is exchanged to an authorization token from the STS server (ECS) that the S-CES may use in the ACR request sent to the T-EES.

The EEC may request the authorization token for ACR and/or access authorization to the T- EES on behalf of the S-CES from the cloud authorization server. The EEC may send the token to the S-CES.

[0154] As the EEC context information owner, the EEC may authorize the information transfer from the S-CES to the T-EES. In this case, the cloud authorization server may issue the authorization token that the EEC may use in the ACR request to the S-CES. When the S-CES receives the EEC ACR request, the S-CES may first validate the authorization token and/or other information in the request. Since the T-EES is in a different trust domain than the S-CES, the T-EES may need to exchange the authorization token with the ECS that acts as the security token service (STS) server. The ECS may respond with a token that the S-CES may use toward the T-EES for access authorization and/or the authorization of EEC context transfer to the T- EES.

[0155] When the S-CES receives the token issued by the ECS, the S-CES may comprise the token in the ACR request to the T-EES. This is done so that the T-EES may verify that the S- CES is authorized to access the T-EES and/or the T-EES is authorized to receive the EEC context.

[0156] At 704, the AC may start the ACR by informing the EEC to perform an ACR procedure. The FQDNs of the T-EES, ECS, and/or T-EAS may be passed to the EEC.

[0157] At 708, the EEC may perform authorization request with the cloud authorization server along with the FQDNs received from the AC. The provision procedure may authorize the EEC by the authorization server. The provision procedure may issue the authorization token to the EEC that the EEC request may use for the EEC context transfer to the T-EES.

[0158] The request to the server may comprise the identities of the S-CES, the T-EES, and/or the FQDN of the ECS. The request may also identify the context to be transferred. An EEC context ID and/or a combination of IDs which comprises the AC ID, EEC ID, and/or WTRU ID may identify the context. The context may need to be identified because multiple ACR procedures for the same EEC (e.g., the same WTRU), S-CES, and T-EES may take place simultaneously. The request may also comprise a requested token validity duration time that indicates to the server that the server should consider the token valid only for the indicated time duration.

[0159] At 712, when the cloud authorization server receives the request from the EEC, the cloud authorization server may check the authorization of the EEC and/or validate the information in the request. The cloud authorization server may validate the EEC ID and/or the S- CES ID with the information when the EEC requested for the CES authorization token.

[0160] At 716, the server may respond to the EEC with the authorization token that the EEC request may use to start the ACR. The response may comprise the associated claims, scopes, and/or token validity duration that indicates how long the server will consider the token to be valid.

[0161] At 720, the EEC may initiate the ACR launching procedure by sending an ACR request to the S-CES. The request may comprise the authorization token for ACR and/or FQDNs of T- EES and/or ECS. The request may also comprise information (e.g., EEC context ID or AC ID, EEC ID, and/or WTRU ID) that the S-CES may use to start the EEC context relocation procedure.

[0162] At 724, after the authorization token validates the ACR request from the EEC, the S- CES may send an ACR response message to the EEC. If the S-CES determines that the authorization token was not included in the ACR request, that the token was not properly formatted (e.g. is not associated with the identified T-EES), that the token is expired, and/or the token is not associated with the context that will be transferred, then the S-CES may indicate that the request was rejected. The S-CES may include a cause code that identifies the reason for the rejection.

[0163] If the token is validated, the CES may request that the token issued by the cloud authorization server be exchanged with the ECS for an authorization token that the ECS issues. The authorization token may act as a STS server.

[0164] The ECS may verify that the ECS trusts the token issued by the cloud authorization server. Since the token scope may comprise the ACR transfer to the EES in the edge, the ECS may decide to issue a token to authorize the S-CES access to the T-EES and/or the ACR transfer to the T-EES.

[0165] At 728, the ECS may check the request and/or issue the token to be used for T-EES access authorization and EEC context transfer authorization. [0166] At 732, the S-CES may initiate an EEC context push relocation procedure with the identified T-EES by sending a push EEC context request to the T-EES. The EEC context push may comprise the token received at 728 for T-EES access authorization and/or the ACR authorization.

[0167] At 736, the T-EES may validate the token for the T-EES access authorization and/or the ACR authorization. If there is not enough information, the T-EES may contact the authorization server to validate the received token. If the T-EES authorizes the ACR, the S-CES and/or T- EES may start the EEC context relocation process.

[0168] At 740, the T-EES may send a push EEC context response message to the S-CES and/or indicate success or failure. If the failure is due to an invalid token, the T-EES may inform the S-CES that the token is not valid. The T-EES may comprise a reason for it being invalid (e g., it is expired).

[0169] At 744, the S-CES may notify the EEC if the context push operation was successful or unsuccessful. If the push was unsuccessful, the S-CES may indicate why the operation was unsuccessful. The notification can also be sent by the T-EES (not shown in FIG. 7).

[0170] At 748, the EEC may send a request to an AC to begin application context transfer. The notification from the S-CES or T-EES may trigger the EEC to send this request. The application context transfer in the application layer may be similar in the authorization mechanism as in the EEL layer.

[0171] Solutions disclosed herein may deal with the edge authorization server (e.g., EAS and/or ECS) performing the STS server role. In some cases, the cloud authorization server may serve as the STS server.

[0172] The EAS may receive the token exchange request from the S-CES with the token issued by the cloud authorization server. The EAS may validate one or more tokens in the token exchange request. If the request is validated, the EAS may issue one or more tokens that the S- CES may use for accessing the T-EES APIs and/or authorize receiving EEC context information from the S-CES. The one or more tokens that may comprise the S-CES ID, the EEC context ID, AC ID, EEC ID, and/or WTRU ID used by the T-EES to identify the EEC context to be transferred as part of the ACR procedure. The EAS may respond to the token exchange request from the S-CES with tokens that the S-CES may use to access the edge EES and/or ACR procedure between the S-CES and the T-EES.

Claims

1. A method implemented by a first WTRU, the method comprising: sending a first message to an edge configuration server (ECS), wherein the first message comprises a request for the ECS to issue a first authorization token associated with transfer of an application context to a cloud application server; receiving a second message from the ECS, wherein the second message comprises the first authorization token from the ECS and a validity duration of the first authorization token; sending the first authorization token to a cloud enabler server (CES), wherein the first authorization token is used to indicate that the CES is authorized to accept WTRU related information; and receiving an application context relocation (ACR) response from the CES, the ACR response indicating whether a context push operation was successful.

2. The method of claim 1 , further comprising sending the first authorization token to the CES via an edge enablement server (EES).

3. The method of claim 2, wherein the authorization token indicates that the EES is authorized to transfer the WTRU related information to the CES.

4. The method of claim 1 , further comprising sending a notification to an application context indicating that the ACR has been completed.

5. The method of claim 1 , wherein the first message indicates the application context to be transferred to the cloud application server.

6. The method of claim 1 , wherein the first message further comprises one or more of CES fully qualified domain name (FQDN), cloud authorization server FQDN, indication of user consent, indication of service continuity to the cloud application server, WTRU identification, application client (AC) identification, edge enablement server (EES) instance identification, edge application server (EAS) identification, or ECS instance identification.

7. The method of claim 1 , further comprising receiving an indication from an application context to perform ACR.

8. The method of claim 1 , further comprising: receiving a third message from the cloud authorization server comprising a second authorization token from the cloud authorization server; and sending the second authorization token to the CES to indicate that the WTRU consents to send the WTRU related information to the CES.

9. The method of claim 8, further comprising sending the second authorization token to the CES via an edge enablement server (EES).

10. The method of claim 1 , wherein the WTRU related information comprises a WTRU identifier or application client (AC) identifier used by the CES to initiate the context push operation.

11. A wireless transmit/receive unit (WTRU), comprising a processor and a memory, the processor and the memory configured to: send a first message to an edge configuration server (ECS), wherein the first message comprises a request for the ECS to issue a first authorization token associated with transfer of an application context to a cloud application server; receive a second message from the ECS, wherein the second message comprises the first authorization token from the ECS and a validity duration of the first authorization token; sending the first authorization token to a cloud enabler server (CES), wherein the first authorization token is used to indicate that the CES is authorized to accept WTRU related information; and receive an application context relocation (ACR) response from the CES, the ACR response indicating whether a context push operation was successful.

12. The WTRU of claim 11 , wherein the processor and the memory are further configured to: send the first authorization token to the CES via an edge enablement server (EES).

13. The WTRU of claim 12, wherein the authorization token indicates that the EES is authorized to transfer the WTRU related information to the CES.

14. The WTRU of claim 11 , wherein the processor and the memory are further configured to: send a notification to an application context indicating that the ACR has been completed.

15. The method of claim 11, wherein the first message indicates the application context to be transferred to the cloud application server.

16. The WTRU of claim 11 , wherein the first message further comprises one or more of CES fully qualified domain name (FQDN), cloud authorization server FQDN, indication of user consent, indication of service continuity to the cloud application server, WTRU identification, application client (AC) identification, edge enablement server (EES) instance identification, edge application server (EAS) identification, or ECS instance identification.

17. The WTRU of claim 11 , wherein the processor and the memory are further configured to: receive an indication from an application context to perform ACR.

18. The WTRU of claim 11 , wherein the processor and the memory are further configured to: receive a third message from the cloud authorization server comprising a second authorization token from the cloud authorization server; and send the second authorization token to the CES to indicate that the WTRU consents to send the WTRU related information to the CES.

19. The WTRU of claim 18, wherein the processor and the memory are further configured to: send the second authorization token to the CES via an edge enablement server (EES).

20. The WTRU of claim 11 , wherein the WTRU related information comprises a WTRU identifier or application client (AC) identifier used by the CES to initiate the context push operation.