Authorization for Edge Enabler Client (EEC) Context Transfer

Abstract

Methods, devices, and systems for the security and authorization of Edge Enabler Client (EEC) context transfers. In some embodiments, an EEC may authorize and / or consent to the transfer of EEC context information from a Source Edge Enabler Server (S-EES) to a Target Edge Enabler Server (T-EES). In various embodiments, the EEC context may be transferred from S-EES to T-EES via a push method (initiated at S-EES) or a pull method (initiated at T-EES). In some Application Context Transfer (ACR) procedures, the EEC context may be transferred even when communication between the EEC and S-EES is not possible or unreliable. Therefore, in some embodiments, the EEC context transfer mechanism may allow the EEC to authorize a context transfer even when communication between the EEC and T-EES is not possible or unreliable during the context transfer.

Description

Technical Field

[0001] This disclosure relates to authorization of Edge Enabler Client (EEC) context transfer.

Background Art

[0002] This application claims the benefit and priority of U.S. Provisional Patent Application No. 63 / 458,015, entitled "Authorization of Edge Enabler Client (EEC) Context Transfer," filed on April 7, 2023, which is hereby incorporated by reference in its entirety.

[0003] Edge computing enables services to be hosted near user devices or other client services, providing low-latency and high-bandwidth services while reducing traffic across the network backbone. Such services can provide a variety of capabilities, including virtual reality and augmented reality, real-time video gaming, teleconferencing, autonomous driving, and applications enhanced by artificial intelligence.

[0004] In many embodiments, an edge enabler client (EEC) may be run by a client device such as a wireless transceiver unit (WTRU), user equipment (UE), or other computing device to communicate with an edge configuration server (ECS) and / or edge enabler server (EES). The EES may provide EEC context information, such as the WTRU or UE's identification information, location information, application client (AC) profile, service session context information, and / or other information. Context information may be transmitted from a source EES (S-EES) to a target EES (T-EES) during an application context relocation (ACR) procedure. However, this information may require careful handling, as theft or interception by a malicious actor could result in security threats, compromised functionality, or additional attack vectors. [Overview of the project]

[0005] Embodiments of systems and methods for the security and authorization of EEC context transfers are described herein. In some embodiments, an EEC may authorize and / or consent to the transfer of EEC context information from an S-EES to a T-EES. Authorization may have different levels of granularity, depending on the embodiment, including authorizing an EEC context transfer to a particular T-EES, authorizing a particular transfer operation, authorizing that particular information be transferred, and so on. In some embodiments, an EEC may authorize a particular transfer operation as part of a particular ACR procedure. For example, in some such embodiments, each EEC context transfer from an S-EES to a T-EES for a given EEC may be authorized separately or individually by that EEC for each ACR procedure, even if that EEC is not involved in the selection of that T-EES.

[0006] In various embodiments, the EEC context may be transferred from S-EES to T-EES via a push method (initiated in S-EES) or a pull method (initiated in T-EES). In some ACR procedures, the EEC context may be transferred even when communication between the EEC and S-EES is not possible or unreliable. Therefore, in some embodiments, the EEC context transfer mechanism may allow the EEC to authorize a context transfer even when communication between the EEC and T-EES is not possible or unreliable during the context transfer. [Brief explanation of the drawing]

[0007] A more detailed understanding can be obtained from the following explanation, which is provided as an example along with the attached drawings, and similar reference numbers in the drawings refer to the same elements.

[0008] [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that may be used in the communication system shown in Figure 1A, according to one embodiment. [Figure 1C] This is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 1D] This is a system diagram showing further exemplary RAN and further exemplary CN that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 2] This is a block diagram of one embodiment of a system for enabling edge applications. [Figure 3] This is a flowchart of one embodiment of a method for transferring the application context. [Figure 4]This is a flowchart of one embodiment of a method for EEC authorization of an EEC context transfer initiated by an EEC, and for an EEC context being pulled from S-EES to T-EES. [Figure 5] This is a flowchart of one embodiment of a method for EEC authorization of EEC context transfers not initiated by the EEC, and for EEC contexts pushed from S-EES to T-EES. [Figure 6] This is a flowchart of one embodiment of a method for EEC authorization of EEC context transfer initiated by the EEC, and for EEC contexts pushed from S-EES to T-EES. [Figure 7A] This is a flowchart of one embodiment of a method for EEC authorization of EEC context transfer. [Figure 7B] This is a flowchart of one embodiment of a method for EEC authorization of EEC context transfer. [Figure 8] This is a flowchart of one embodiment of a method for EEC authorization of EEC context transfer. [Modes for carrying out the invention]

[0009] Edge computing enables services to be hosted closer to user devices or other client services, allowing for low-latency, high-bandwidth services while reducing traffic across the entire network backbone. Such services can offer a variety of capabilities, including virtual and augmented reality, real-time video gaming, teleconferencing, autonomous driving, and artificial intelligence-enhanced applications.

[0010] In many embodiments, an edge enabler client (EEC) may be run by a client device such as a wireless transceiver unit (WTRU), user equipment (UE), or other computing device to communicate with an edge configuration server (ECS) and / or edge enabler server (EES). The EES may provide EEC context information, such as the WTRU or UE's identification information, location information, application client (AC) profile, service session context information, and / or other information. Context information may be transmitted from a source EES (S-EES) to a target EES (T-EES) during an Application Context Transfer (ACR) procedure. However, this information may require careful handling, as theft or interception by a malicious actor could result in security threats, compromised functionality, or additional attack vectors.

[0011] Embodiments of systems and methods for the security and authorization of EEC context transfers are described herein. In some embodiments, an EEC may authorize and / or consent to the transfer of EEC context information from an S-EES to a T-EES. Authorization may have different levels of granularity, depending on the embodiment, including authorizing an EEC context transfer to a particular T-EES, authorizing a particular transfer operation, authorizing that particular information be transferred, and so on. In some embodiments, an EEC may authorize a particular transfer operation as part of a particular ACR procedure. For example, in some such embodiments, each EEC context transfer from an S-EES to a T-EES for a given EEC may be authorized separately or individually by that EEC for each ACR procedure, even if that EEC is not involved in the selection of that T-EES.

[0012] In a first embodiment, the Disclosure relates to embodiments of methods and systems for EEC authorization of EEC context transfers in scenarios in which an ACR procedure is initiated by an EEC and an EEC context is pulled from an S-EES to a T-EES. In these embodiments, the EEC may obtain a token before any entity in the edge enablement layer (EEL) decides to initiate an ACR procedure. The EEC may negotiate with a token server to impose restrictions (e.g., time, date, specific use, etc.) on which entities can use the token. The EEC may provide the token to the S-EES. The S-EES may then use the token when authorizing a request from the T-EES to retrieve the EEC's context. In some such embodiments, the EEC may be able to exercise some control over where the context may be transferred, even if the S-EES is unable to communicate with the EEC at the time the context transfer needs to occur.

[0013] In another embodiment, the disclosure covers embodiments of methods and systems for EEC authorization of EEC context transfers in scenarios where the ACR procedure is not initiated by the EEC and the EEC context is pushed from the S-EES to the T-EES. In these embodiments, the EEC may obtain a token before any entity in the EEL decides to initiate the ACR procedure. The EEC may negotiate with a token server to impose restrictions and / or other restrictions (e.g., time, date, specific use, etc.) on which entities can use the token. The EEC may provide the token to the S-EES. The S-EES may then use the token when transferring the context to the T-EES. In some such embodiments, the EEC may be able to exercise some control over where the context may be transferred, even if the S-EES is unable to communicate with the EEC at the time the context transfer needs to occur.

[0014] In yet another embodiment, the Disclosure relates to embodiments of methods and systems for EEC authorization of EEC context transfer in scenarios in which an ACR procedure is initiated by an EEC and an EEC context is pushed from an S-EES to a T-EES. In these embodiments, the EEC decides to perform an ACR procedure, obtains a token, and sends the token to the S-EES. The S-EES may then provide the token to the T-EES so that the T-EES can verify that it is authorized to receive the EEC's context.

[0015] Various embodiments of these systems and methods use tokens to authorize the transfer of EEC context from S-EES to T-EES. The token may be an OAuth 2.0 Access Token and, in some embodiments, may be generated by a server (e.g., a token server, an edge configuration server (ECS)) or another device. In some embodiments, the server that generates the token may be called an authentication server. In various embodiments, the EEC may authorize the transfer of context information from S-EES to T-EES. Authorization may be a form of consent, and therefore, in such embodiments, the EEC may give consent to the transfer of context information from S-EES to T-EES. The EEC may act on behalf of the user or be operated by the user, and therefore, this type of consent may be called user consent. The context information transferred from the first EES to the second EES may include information about one or more application layer sessions.

[0016] For reference, various abbreviations and acronyms are used herein, for example, as follows: 3GPP Third Generation Partnership Project 5G (5th generation) AC Application Client ACR Application Context Migration ACT Application Context Transfer DNN Data Network Name EAS Edge Application Server ECS Edge Configuration Server ECSP Edge Computing Service Provider EDN Edge Data Network EEC Edge Enable Client EEL Edge Enablement Layer EES Edge Enable Server FQDN Fully Qualified Domain Name KI Key Issue KPI Key Performance Indicator MNO Mobile Network Operator NMC Notification Management Client NMS Notification Management Server QoS Quality of Service SCP Service Continuity Plan S-EAS Source Edge Application Server S-EES Source Edge Enable Server TR Technical Report TS Technical Specification T-EAS Target Edge Application Server T-EES Target Edge Enable Server UID User Identifier URI Universal Resource Identifier UE User Equipment WLAN Wireless Local Area Network and Related Technologies (IEEE802.1 Domain) WTRU Wireless Transceiver Unit

[0017] Prior to discussing embodiments of the systems and methods discussed herein, it may be useful to briefly discuss embodiments of communication systems and devices that may be used with these systems and methods.

[0018] Figure 1A shows an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may utilize 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 discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique-word OFDM (UW-OFDM), resource-block filtered OFDM, and filtered-bank multi-carrier (FBMC).

[0019] As shown in Figure 1A, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRU102a, 102b, 102c, and 102d, any of which may be called base stations (STAs), may be configured to transmit and / or receive wireless signals and may include user equipment (UEs), mobile stations, fixed or mobile subscriber units, contract-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), automobiles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronic devices, and devices operating on commercial and / or industrial wireless networks. Any of WTRU102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

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

[0022] Base stations 114a, 114b may communicate with one or more WTRUs 102a, 102b, 102c, 102d via an air interface 116, the air interface 116 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).

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

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

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

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

[0027] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 3X, 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), and GSM EDGE (GERAN).

[0028] The base station 114b in Figure 1A may be a wireless router, Home Node B, Home eNode B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in localized areas such as businesses, homes, automobiles, campuses, industrial facilities, aerial walkways (e.g., for use by drones), and roads. In one embodiment, the base stations 114b and WTRUs 102c, 102d may establish a wireless local area network (WLAN) by implementing radio technology such as IEEE 802.11. In another embodiment, the base stations 114b and WTRUs 102c, 102d may establish a wireless personal area network (WPAN) by implementing radio technology such as IEEE 802.15. In yet another embodiment, the base stations 114b and WTRUs 102c, 102d may establish a picocell or femtocell by utilizing a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not be required to access the internet 110 via CN 106.

[0029] RAN104 may communicate with CN106, 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 WTRU102a, 102b, 102c, and 102d. The data may have various Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 may provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, and / or implement high-level security features such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 and / or CN106 may communicate directly or indirectly with other RANs that utilize the same RAT as RAN104 or different RATs. For example, in addition to connecting to RAN104 which may utilize NR radio technology, CN106 may also communicate with another RAN (not shown) which utilizes GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

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

[0033] The processor 118 could be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which can be coupled to a transmit / receive element 122. Although Figure 1B illustrates the processor 118 and transceiver 120 as separate components, it will be understood that the processor 118 and transceiver 120 can be integrated together in an electronic package or chip.

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

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

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

[0037] The processor 118 of the WTRU102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (for example, a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and may receive user input data from there. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and may store data therein. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identification 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 memory not physically located in the WTRU 102, such as a server or home computer (not shown), and may store data therein.

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

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

[0040] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. Peripherals 138 may include one or more sensors. The sensors may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a compass sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, and the like.

[0041] WTRU102 may include a full-duplex radio that is associated with specific subframes for both the transmission and reception of some or all of the signals (e.g., UL (e.g., for transmission) and DL (e.g., for reception)), but which may be simultaneous and / or parallel. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference, either through hardware (e.g., chokes) or through signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WTRU102 may include a half-duplex radio that is the transmission and reception of some or all of the signals (e.g., associated with specific subframes for either UL (e.g., for transmission) or DL ​​(e.g., for reception)).

[0042] Figure 1C is a system diagram showing RAN104 and CN106 according to one embodiment. As described above, RAN104 may utilize E-UTRA radio technology to communicate with WTRU102a, 102b, and 102c via air interface 116. RAN104 may also communicate with CN106.

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

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

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

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

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

[0048] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and an IP-enabled device.

[0049] CN106 can facilitate communication with other networks. For example, CN106 may provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional fixed telephone line communication devices. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) acting as an interface between CN106 and PSTN108. In addition, CN106 may provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0050] Although WTRUs are described as wireless terminals in Figures 1A to 1D, in some representative embodiments, such terminals are intended to use wired communication interfaces (e.g., temporary or permanent) with a communication network.

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

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

[0053] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may have a fixed width (e.g., a 20 MHz bandwidth) or a dynamically set width. The primary channel may also be the operating channel of the BSS and may be used by an STA to establish a connection with the AP. In some typical embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. In CSMA / CA, an STA, including the AP (e.g., any STA), may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that particular STA may make concessions. A single STA (e.g., only one station) may transmit at any given time within a given BSS.

[0054] A high-throughput (HT) STA may use a 40MHz wide channel for communication via a combination of a primary 20MHz channel and adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel, for example.

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

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

[0057] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) 1 MHz mode, even if other STAs in the AP and BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier detection and / or network allocation vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (which only supports 1MHz operating mode) is transmitting to the AP, then all available frequency bands may be considered busy, even if the majority of the available frequency bands remain idle.

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

[0059] Figure 1D is a system diagram showing RAN104 and CN106 according to one embodiment. As described above, RAN104 may utilize NR radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 may also communicate with CN106.

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

[0061] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may differ for different transmissions, different cells, and / or different parts of the wireless transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., including a variable number of OFDM symbols and / or a variable-length absolute time that continues).

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

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

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

[0065] AMF182a and 182b may be connected to one or more gNB180a, 180b, and 180c in RAN104 via the N2 interface and may act as control nodes. For example, AMF182a and 182b may be responsible for authenticating users of WTRU102a, 102b, and 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating non-accessible layer (NAS) signaling, and mobility management. Network slicing may be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of services utilized by WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-high reliability low latency (URLLC) access, services relying on extended large-scale mobile broadband (eMBB) access, and services for MTC access. The AMF182a and 182b may provide control plane functionality for switching between RAN104 and other RANs (not shown) that utilize other radio technologies such as LTE, LE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

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

[0067] UPF184a, 184b may be connected to one or more gNB180a, 180b, 180c in RAN104 via the N3 interface, and the N3 interface may provide WTRU102a, 102b, 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, 102c and IP-enabled devices. UPF184a, 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 DL packets, and providing mobility anchoring.

[0068] CN106 can facilitate communication with other networks. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. In addition, CN106 can provide WTRU102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to local DN185a, 185b through UPF184a, 184b via an N3 interface to UPF184a, 184b and an N6 interface between UPF184a, 184b and DN185a, 185b.

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

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

[0071] One or more emulation devices may perform one or more functions, including all functions, without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be used in a test laboratory and / or in test scenarios in undeployed (e.g., experimental) wired and / or wireless communication networks to perform testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by emulation devices to transmit and / or receive data.

[0072] Figure 2 is a block diagram of one embodiment of system 200 for enabling edge applications. Schematically, the system may comprise a UE or WTRU 202 or other device (referred to in various ways as UE, WTRU, mobile device, smartphone, mobile computing device, remote device, wearable device, or any other similar terminology) communicating with the edge data network 212, edge configuration server 218, and / or notification management server 220 via network 210 (e.g., a 3GPP core network, or any other type and form of network).

[0073] As shown, in some implementations, the WTRU202 may have or run one or more application clients 204. In some embodiments, the application client (AC) 204 is a user application residing in the UE that communicates with the edge application server (EAS) 214. The UE or WTRU202 may use several AC204 simultaneously. For example, the WTRU202 may have one or more processors running one or more AC204 stored in the WTRU202's memory. For example, in some implementations, the AC204 may be a web browsing application, a social media application, a video game application, a productivity application, a remote desktop application, or any other type and form of application. In many implementations, the AC204 may be an application running within a web application or a web browser or similar local application that communicates with an application server such as the EAS 214.

[0074] In some embodiments, the edge application server (EAS) 214 is an application server located on the edge data network (EDN) 212. The EAS may comprise hardware, software, or a combination of hardware and software. For example, in some implementations, the EAS may comprise one or more software servers running on general-purpose hardware (e.g., a cloud server, cluster, or virtual machine farm) located on the edge data network 212 and providing services to the AC202. For example, the EAS 214 may include a web server that provides web applications (e.g., email applications, productivity applications, etc.) to one or more WTRU 202 and AC204.

[0075] In some implementations, a WTRU can be moved geographically and / or logically. For example, as a WTRU202 moves within an area, it may become geographically closer to various EAS214s. Since a physically closer EAS214 may have a lower latency connection to the WTRU, it may be desirable to switch the WTRU and AC204 from a first EAS serving a certain application (called a source EAS or S-EAS) to a second EAS (called a target EAS or T-EAS) that may serve the same application. In some implementations, the second EAS or target EAS may not necessarily be geographically closer than the S-EAS, but may be logically closer. That is, network speed, bandwidth, or congestion may result in a faster or lower latency connection from the WTRU202 to the T-EAS than to the S-EAS, regardless of physical proximity. Therefore, in various implementations, it may be desirable to switch WTRUs from services provided by S-EAS to services provided by T-EAS based on location, latency, throughput, congestion, or any other physical and / or network characteristics. Such a switch is sometimes called a transfer, but in some implementations, as discussed above, the WTRU may not physically change location. As will be discussed in more detail below, transferring a WTRU from S-EAS to T-EAS may involve transferring configuration and / or state information (commonly called context) from S-EAS to T-EAS. For example, if S-EAS is providing a stateful web application to an AC204, switching the AC to T-EAS without transferring the context may result in the web application crashing or the web application losing its state and being unable to fulfill requests until it is reloaded. This may result in broken functionality, data loss, etc. Instead, implementations of the systems and methods discussed herein may enable seamless context transfer between S-EAS and T-EAS, allowing for continued use by the transferred AC.

[0076] In the context of a move / transfer use case, the source EAS (S-EAS) may be an instance of the EAS at the initial location that was serving the AC before the move / transfer occurred, and the target EAS (T-EAS) may be an instance of the EAS at the target location that will serve the AC after the move / transfer occurred. There may be multiple EAS instances 214 for each EDN 212. Each EDN 212 may contain a different set of EAS instances 214 of different types (e.g., different EASIDs), and the EAS 214 may serve one or more AC instances 204 that may reside in different UEs 202.

[0077] In some embodiments, the Edge Enabler Client (EEC) 206 provides edge support to AC202 instances on the UE / WTRU 202. There may be one or more EEC206 per UE202. In some embodiments, each AC204 uses only one EEC206. For example, the EEC206 may have a plug-in or subroutine for the AC204, or it may run as a handler dedicated to the AC204 and configured to connect or intercept calls to and from the AC204. Thus, in various embodiments, the EEC206 may have applications, services, servers, daemons, routines, or other executable logic to communicate with the Edge Enabler Server 216 and Edge Configuration Server 218 on behalf of the AC204, including those for managing context switching or transfer.

[0078] In some embodiments, the Edge Enabler Server (EES) 216 provides auxiliary functions required by the EAS 214 and EEC 206. The EES 216 may contain applications, servers, services, daemons, routines, or other executable logic to transfer state and / or configuration information or other contextual information between the EAS 214 and the EEC 206 on behalf of the AC 204. The EES 216 may run on one or more physical computing devices (e.g., servers, workstations, etc.) or on one or more virtual computing devices running on one or more physical computing devices (e.g., as a cloud service, virtual server farm, etc.). The EES 216 may run on the same device as the EAS 214 or on a different device. As discussed above, in the context of a move / relocation use case, the source EES (S-EES) is the EES used before the move / relocation occurs, and the target EES (T-EES) is the EES used after the move / relocation occurs. There may be one or more EES instances 216 for each EDN212 (or for each Data Network Name (DNN)). There may be multiple EDN instances 212 in network 210.

[0079] In some embodiments, the Edge Configuration Server (ECS) 218 ​​may include applications, servers, services, daemons, routines, or other executable logic to provide auxiliary functions for an EEC 206 or EES 216 to discover an EES instance 216 that provides a certain EAS 214. For example, the ECS may include a configuration database, user database, application database, or other such database for identifying the EAS 214 and / or EEC 206 or AC 204. The ECS 218 may be provided by one or more computing devices, including physical or virtual computing devices (e.g., cloud servers) as discussed above. There may be one or more ECS 218 for a network.

[0080] In some embodiments, the Notification Management Client (NMC) 208 provides auxiliary functions for creating a notification channel (NM-UU) between the NMC 208 and the Notification Management Server (NMS) 220 for the EEC 206 to receive notifications from the ECS or EES. In some embodiments, each EEC uses only one NMC. The NMC 208 can be an application, server, service, daemon, routine, or other executable logic that runs on and / or communicates with one or more processors of the UE / WTRU 202. For example, in some implementations, the NMC 208 may contain an application provided by the EAS 214. In other implementations, the NMC 208 may contain a service run by an application or operating system of the WTRU, such as a listening service or other routine for periodically pulling and / or receiving notifications from the NMS 220. As shown, the NMC 208 may be provided as a Service Enable Structure Layer (SEAL) service. The NMC208 can assist with notification management functions for the EEC206 and AC204, sometimes referred to as a vertical application layer (VAL) client on the NM-C reference point.

[0081] In some embodiments, the Notification Management Server (NMS) 220 provides auxiliary functions for the ECS or EES to send notifications to the EEC via a notification channel created between the NMC and the NMS. The NMS 220 may be an application, service, server, daemon, routine, or other executable logic, running on one or more physical computing devices and / or running on virtual computing devices running on physical computing devices. There may be one or more NMS 220s for a network. The NMS 220 may communicate with the NMC 208 via an NM-UU reference point (e.g., a point-to-point interface over network 210 or another network) or via a PUSH server for indirect distribution, and may provide notification management functions to the EEC 218 and EES 216 via an NM-S reference point (e.g., a point-to-point interface over network 210 or another network).

[0082] The 3GPP TS23.558 V18.1.0 “Architecture for enabling Edge Applications,” incorporated by reference herein, describes several embodiments of service continuity procedures in the Edge Enabler Layer (EEL) for transferring application context from S-EAS to T-EAS. As discussed above, context transfer can be triggered, for example, by UE movement, as well as by non-moving events such as maintenance or overload of EAS servers. The goal of service continuity is to minimize disruption to edge services running on AC204 on UE202.

[0083] Service continuity for applications requiring context transfer is defined by EEL in five different Application Context Transfer (ACR) scenarios. Each scenario may include four distinct stages: detection, determination, execution, and post-execution. An ACR scenario may define different EEL entities (e.g., EEC, EES, EAS) for the detection and determination stages (e.g., detection entity and decision entity), as well as different sets of interactions between EEL entities for the execution stage.

[0084] Figure 3 is a flowchart of one embodiment of a method for transferring application context. Schematically, in various implementations, a detection entity, which may run by or on the UE or WTRU, or on an external server or another computing device, monitors the location, movement, or other physical or network characteristics of the UE or WTRU (e.g., noise, latency, congestion, velocity or acceleration, location coordinates, received beacon signal strength, etc.) and informs a decision-making entity (step 305). The decision-making entity, which may similarly run by or on the UE or WTRU, or on an external server or another computing device, then determines whether ACR is required and instructs the execution entity to perform ACR (step 310). The execution entity, which may similarly run by or on the UE or WTRU, or on an external server or another computing device, then performs the ACR procedure defined in the service continuity scenario to transfer the application context from S-EAS to T-EAS (step 315). Once the ACR execution is complete, ACR cleanup is performed (step 320). For example, a WTRU acting as a detection entity (which may include EEC206) may monitor network or device characteristics. In some implementations, the decision entity of the WTRU (which may also include EEC206) may decide based on the measurements that ACR is needed and communicate with EES216 and / or ECS218 to initiate forwarding. Conversely, in some implementations, the measurements may be reported by the WTRU's detection entity to a decision entity on EES216, which may decide that ACR is needed and communicate with EEC206 and / or ECS218.

[0085] Various methods can be used for EEC authorization, including pre-configuring tokens for future EEC pull or push context transfers. Outline, in a first embodiment, to pre-configure tokens for future EEC pull context transfers, in some embodiments, the EEC may perform one or more of the following steps:

[0086] First, in some implementations, the EEC (e.g., EEC206) may send a request for a token to the server. The request may identify an instance of the EEC context. In some implementations, the request may also indicate a request for authorization restrictions. In some embodiments, the EEC context may be identified by an EEC context ID, or by a session context which may be identified by some or all combinations of an Application Client Identifier (ACID), an EEC Identifier (EEC ID), a User Equipment Identifier (UE ID), an S-EAS endpoint, and / or a T-EAS endpoint. In some embodiments, the authorization restrictions may indicate a specific T-EES that can be authorized by the token. In some embodiments, the authorization restrictions may indicate that only certain types of T-EES can be authorized using the token. In some embodiments, the authorization restrictions may indicate that only T-EES associated with a particular service provider can be authorized using the token. In some embodiments, the authorization restrictions may indicate that only T-EES in certain locations can be authorized using the token. In some embodiments, the authorization restrictions may indicate that only T-EES in certain EDNs can be authorized using the token. In various embodiments, any of the above authorization restrictions may indicate which T-EES cannot be authorized using a token. The request may also include the requested token validity period. In some embodiments, the token server may be an ECS218 and / or an EES216, or an application or server running on an ECS218 or similar hardware server.

[0087] In many implementations, authorization restrictions may specify characteristics of an EES rather than identifying an individual EES. For example, instead of identifying a specific server, authorization restrictions may specify that a server may be authorized if it has uptime longer than a threshold, or resource utilization below a threshold, or is within a threshold number of miles from a geographical location, or has latency below a threshold to an EEC or ECS, or has certain application serving capabilities (e.g., the server can host an artificial intelligence / machine learning application, or provide a web interface to a web application, or provide remote data storage capabilities), or has a specified operating system version (e.g., indicating that a particular patch is up to date), or has access to other special hardware or such hardware (e.g., satellite uplink or ray tracing GPU). In some such implementations, a group of potential EESs that possess characteristics that may satisfy authorization restrictions may be referred to as target EES candidates, or by similar terminology. Often, not all EESs will meet the requirements, and therefore, target EES candidates may be a subset of EESs in the system. In many implementations, authorization restrictions may not depend on any particular EES, or may not include any identification information for a particular EES, and may only include the characteristics necessary for the authorization or validity of the token.

[0088] Secondly, in some embodiments, the EEC206 may receive a response from the server. In some embodiments, the response may include a token and, optionally, authorization restrictions applied to the token. The response may also include the token's validity period.

[0089] Thirdly, in some implementations, EEC206 may send a message to a first EES (S-EES 216A). In some embodiments, the message may include a token and authorization restrictions (for example, if they are included with the token). In some embodiments, the message may also include the token's validity period. The message may be used to control which other EESs (T-EES) may receive context information associated with EEC206. For example, in some implementations, a T-EES may send a request for context information to an S-EES, and the S-EES may determine, based on authorization restrictions, whether the T-EES is permitted to receive the context information.

[0090] Fourth, in some implementations, the EEC206 may decide to perform an ACR procedure to select a T-EES (e.g., T-EES 216B). Selecting a T-EES may involve identifying from T-EES candidates a T-EES that possesses characteristics that satisfy the authorization restriction requirements associated with the token. For example, the EEC may select a T-EES that has a location within the required area, has latency below the required threshold, or has the ability to provide a specific application service.

[0091] Fifth, in some implementations, the EEC206 may send an ACR request to a selected T-EES216B. In some embodiments, the request may include a token. In such embodiments, the T-EES may use the token to retrieve EEC context information from the S-EES216A (provided that token authorization restrictions do not prevent the T-EES from receiving the context information).

[0092] Sixth, in some implementations, EEC206 may receive a message from T-EES216B (for example, if T-EES was not prevented by a token authorization restriction from receiving context information). In some embodiments, the message includes an indication that the authorization token was used to authorize the transfer of context to T-EES. In some embodiments, the message may trigger EEC206 to consider the token invalid and restart the procedure to obtain a new token for a future ACR procedure. For example, T-EES216B may indicate that it was prevented by an authorization restriction, or T-EES216B may provide an indication that the transfer of context was authorized, but the token has provisionally expired. The message provided by T-EES216B may be an ACR information notice or any other appropriate type and format of notice message.

[0093] In another embodiment, in order to pre-configure a token for future EEC push context transfers, the EEC may perform one or more of the following steps:

[0094] First, in some implementations, EEC206 may send a request for a token to the server. In some embodiments, the request identifies an instance of the EEC context. In some embodiments, the request also indicates a request for authorization restrictions.

[0095] In some embodiments, the EEC context is identified by an EEC context ID, or by a session context which may be identified by a combination of ACID, EEC ID (or UE ID), S-EAS endpoint, and T-EAS endpoint. In some embodiments, authorization restrictions may indicate specific T-EES that can be authorized using a token. In some embodiments, authorization restrictions may indicate that only certain types of T-EES can be authorized using a token. In some embodiments, authorization restrictions may indicate that only T-EES associated with a particular service provider can be authorized using a token. In some embodiments, authorization restrictions may indicate that only T-EES at a particular location can be authorized using a token. In some embodiments, authorization restrictions may indicate that only T-EES within a certain EDN can be authorized using a token. In some embodiments, any of the above authorization restrictions may indicate which T-EES cannot be authorized using a token. As discussed above, authorization restrictions may refer to required characteristics, or characteristics that can be satisfied by some EESs, and corresponding thresholds, for which the token accordingly indicates authorization of context transfer.

[0096] In some embodiments, the request may also include the requested token validity period. In many implementations, the token server may be an ECS218.

[0097] Secondly, in some implementations, EEC206 may receive a response from the server. In some embodiments, the response may include the token and the authorization restrictions applied to the token. The response may also include the token's validity period.

[0098] Thirdly, in some implementations, EEC206 sends a message to a first EES (S-EES216A). In some embodiments, the message includes a token and authorization restrictions. The message may also include the token's validity period. The purpose of the message may be to control which other EESs (T-EES216B) can receive contextual information associated with the EEC.

[0099] Fourth, in some implementations, the EEC206 receives a message from the first EES (S-EES216A). In some embodiments, the message includes an indication that an authorization token was used to authorize the transfer of context to the T-EES216B. In some embodiments, the message may include T-EES identification information (for example, S-EES216A may select the T-EES to which the context is being transferred from multiple potential EES216s). The message may prompt the EEC to consider the token invalid and restart the procedure to obtain a new token for a future ACR procedure. In some embodiments, the message may be an ACR informational notice.

[0100] The aspects of these embodiments will be discussed in more detail below.

[0101] Figure 4 shows one embodiment of procedure 400 for EEC authorization of EEC context transfer in a scenario in which the ACR procedure is initiated by EEC206 and the procedure requires that the EEC context be pulled from S-EES216A to T-EES216B. In such embodiments, EEC206 may obtain a token before any entity in the EEL decides to initiate the ACR procedure. In some embodiments, EEC206 negotiates with a token server 402 (which may be provided by ECS218) to impose limits on how entities can use the token. In some embodiments, EEC206 then provides the token to S-EES216A, which then uses the token when authorizing a request from T-EES216B to retrieve the EEC context. Advantageously, in these embodiments, EEC206 may be able to exercise some control over where the context may be transferred to, even if S-EES216A is unable to communicate with the EEC at the time the context transfer needs to occur (for example, because the EEC has moved out of range of S-EES due to changing network conditions).

[0102] In step 1, in some embodiments, EEC206 sends a request to server 402 to obtain an authorization token. The authorization token should be used to authorize the transfer of the EEC context from source EES (S-EES216A) to T-EES216B. The request to the server may include the identification information of S-EES216A. Since there may not yet be a decided or selected T-EES216B, the request may not specify a T-EES, or may indicate that there is no selected T-EES. In some embodiments, the request also specifies the context to be transferred. The context is identified by an EEC context ID, or by a combination of identification information including ACID, EEC ID (or UE ID), S-EAS endpoint, and T-EAS endpoint. In some embodiments, since multiple ACR procedures for the same EEC (UE), S-EES, and T-EES may occur simultaneously, the session context needs to be identified. In some embodiments, the request may also include a requested token validity period, indicating to the server that it should consider the token valid only for the specified period. In some embodiments, the request may also indicate a requested authorization restriction. The requested authorization restriction may indicate a restriction on which T-EES can be authorized using the token. The restriction may indicate specific T-EES that can be authorized using the token. The restriction may indicate that only certain types of T-EES, T-EES associated with a particular service provider, or T-EES located in a certain location can be authorized using the token. Alternatively, the restriction may indicate which T-EES cannot be authorized using the token.

[0103] In some embodiments, server 402 may be ECS218. The request may be integrated with a service provisioning procedure.

[0104] In step 2, in some embodiments, server 402 responds to EEC206 with an authorization token. In some embodiments, the response includes a token validity period indicating how long the server considers the token to be valid. In some embodiments, the response also indicates authorization restrictions that apply to the token. Note that EEC206 may choose to request a token after deciding to perform an ACR.

[0105] In step 3, in some embodiments, EEC206 sends a token delegation message to S-EES216A. In some embodiments, the request includes an authorization token, a token validity period, and authorization restrictions applicable to the token. In these embodiments, the term delegation refers to EEC206 delegating the task of validating the token to S-EES216A. S-EES may then perform token validation (for example, as part of step 9 when transferring the EEC context).

[0106] In step 4, in some embodiments, EEC206 decides to perform an ACR procedure. For example, EEC206 may be triggered to perform an ACR procedure based on the detection of a change in the UE location. In some embodiments, EEC206 may also be triggered to perform an ACR procedure based on a notification request from ECS218.

[0107] In step 5, in some embodiments, EEC206 selects one of the EESs that should act as the target EES (T-EES216B) in the ACR procedure.

[0108] In step 6, in some embodiments, EEC206 initiates the ACR initiation procedure by sending an ACR request to T-EES216B. The request may include an authorization token and identification information for S-EES216A. In some embodiments, the request also includes information used by T-EES216B to identify the EEC context that needs to be transferred as part of the ACR procedure (e.g., EEC context ID or ACID, EEC ID (or UE ID), S-EAS endpoint and T-EAS endpoint). In some embodiments, T-EES216B may determine whether an authorization token is required to perform the context transfer. The determination of whether an authorization token is required may be based on local policy or an indication previously received from EEC206 (e.g., during the registration procedure).

[0109] In step 7, in some embodiments, T-EES216B sends an ACR response message to EEC206. If T-EES216B determines that the authorization token was not included in the ACR request, the token was not properly formatted (e.g., not associated with the identified S-EES216A), the token has expired, or the token is not associated with the context that needs to be transferred, T-EES216B may indicate that the request has been rejected and include a cause code that identifies the reason for the rejection.

[0110] In step 8, in some embodiments, if an authorization token is not included in the ACR request, T-EES216B may determine that it is authorized to pull the EEC context from S-EES, and if T-EES is authorized, T-EES216B may initiate the EEC context pull transfer procedure using the identified S-EES by sending a pull EEC context request to S-EES216A. The EEC context pull may include an authorization token.

[0111] In step 9, in some embodiments, S-EES216A may verify the validity of the token's applicability to the context to be transferred and validate the token (for example, S-EES216A may verify that the token is the same token provided to S-EES by EES in step 3, verify the token's signature, and / or send the token to the token server 402 for validation or verification). S-EES216A may first determine whether the token is valid for S-EES216A to authorize it to transfer the EEC context to T-EES216B. If the pull request included the authorization token in step 8, S-EES may verify whether the token received in the pull EEC context request is valid for S-EES216A to authorize it to transfer the EEC context to T-EES216B. S-EES216A may send a pull EEC context response message to T-EES indicating success or failure. If the failure is due to an invalid token, S-EES may inform T-EES that the token is invalid, and S-EES may include the reason why it is invalid (for example, the token has expired).

[0112] In step 10, in some embodiments, T-EES216B may send an ACR information notice to EEC206. In some embodiments, the ACR information notice may include an indication of which authorization token was used to authorize the context transfer to T-EES216B, whether the token was invalid or valid, and whether the transfer was successful or unsuccessful. This message may prompt the EEC to consider the token invalid and restart the procedure in step 1 to obtain a new token for the S-EES for future ACR procedures. Note that when the procedure is restarted, in some implementations, the S-EES may be an EES that is considered to be the T-EES in this procedure (for example, the procedure may be restarted with the T-EES as the new S-EES).

[0113] Figure 5 shows an exemplary procedure 500 for EEC authorization of EEC context transfer in a scenario where the ACR procedure is not initiated by EEC206 and the procedure requires that the EEC context be pushed from S-EES216A to T-EES216B. In embodiments of this procedure, EEC206 may obtain a token before any entity in the EEL decides to initiate the ACR procedure. In some embodiments, EEC206 negotiates with a token server 402 to impose limits on how entities can use the token. EEC206 then provides the token to S-EES216A, which then uses the token when transferring the context to T-EES216B. In addition, in some implementations, the token may be transferred to T-EES216B so that T-EES can verify the validity that it is permitted to accept the EEC context. Advantageously, in some embodiments, the EEC206 can exercise some control over where the context may be forwarded even if the S-EES216A is unable to communicate with the EEC at the time the context forwarding needs to occur (for example, because the EEC is out of range, or due to changing network conditions).

[0114] In step 1, in some embodiments, EEC206 sends a request to server 402 to obtain an authorization token. In some implementations, the token server 402 may be provided by ECS218. The authorization token may be used to authorize the transfer of an EEC context from a source EES (S-EES) to a T-EES. In some embodiments, the request to the server includes identification information for S-EES216A. Since there is no determined T-EES in these implementations, the request may not indicate T-EES216B, or may be T-EES-independent or blank in relation to it. In some implementations, the request may indicate several candidate T-EES216B (e.g., a subset of all T-EES, for example), assuming that one of them may be selected later. In some embodiments, the request may specify the context to be transferred. In some embodiments, the session context is identified by an EEC context ID, or by a combination of identifiers including ACID, EEC ID (or UE ID), S-EAS endpoint, and T-EAS endpoint. In some embodiments, the session context may be identified so that multiple ACR procedures for the same EEC (UE), S-EES, and T-EES can occur simultaneously. In some embodiments, the request may also include a requested token validity period, indicating to the server that it should consider the token valid only for the specified period. In some embodiments, the request also indicates a requested authorization restriction. The requested authorization restriction may indicate a limitation on which T-EES216B can be authorized using the token. The restriction may indicate specific T-EES that can be authorized using the token. The restriction may indicate that only certain types of T-EES, T-EES associated with a particular service provider, or T-EES located in a certain location can be authorized using the token. Alternatively, the restriction may indicate which T-EES cannot be authorized using the token. The request may be integrated with a service provisioning procedure.

[0115] In step 2, in some embodiments, the server 402 may respond to EEC206 using an authorization token. In some embodiments, the response includes the token and a token validity period indicating how long the server considers the token to be valid. In some embodiments, the response also indicates authorization restrictions that apply to the token.

[0116] In step 3, in some embodiments, EEC206 sends a token delegation message to S-EES216A. In some embodiments, the request includes an authorization token, a token validity period, and authorization restrictions applicable to the token. In some embodiments, the information sent in the token delegation message may be carried in an EAS information provisioning message.

[0117] In step 4, in some embodiments, the S-EES216A decides to perform the ACR procedure. For example, the S-EES216A may be triggered to perform the ACR procedure based on the detection of a change in the UE position.

[0118] In step 5, in some embodiments, S-EES216A selects an EES that should act as the target EES (T-EES216B) in the ACR procedure. In some embodiments, S-EES216A selects a T-EES216B that can use authorization tokens (e.g., one authorized by token authorization restrictions). In other words, S-EES216A may apply filters to the EES considered for T-EES selection (e.g., T-EES candidates) so that EES to which tokens cannot be applied are not considered.

[0119] In step 6, in some embodiments, S-EES216A initiates the EEC context push transfer procedure using the identified T-EES216B by sending a push EEC context request to T-EES. The EEC context push may include an authorization token.

[0120] In step 7, in some embodiments, T-EES216B may send a request to token server 402 and / or ECS218 to verify that the token is valid and to confirm that the token is applicable to the context in which it is requested to be transmitted. For example, T-EES may send a notice of the token, the hash of the token, the identifier of the token, the signed version of the token, or any other type and format.

[0121] In step 8, in some embodiments, the server 402 may respond to the T-EES216B. In some embodiments, the server 402 may inform the T-EES216B whether the token is valid or invalid. If the server 402 informs the T-EES216B that the token is invalid, it may include the reason why it is invalid (for example, the token has expired).

[0122] In step 9, in some embodiments, T-EES216B sends a push EEC context response message to S-EES216A indicating success or failure. If the failure is due to an invalid token, in some embodiments, T-EES216B informs S-EES216A that the token is invalid, and T-EES may include the reason why it is invalid (e.g., the token has expired).

[0123] In step 10, in some embodiments, S-EES216A sends an ACR information notice to EEC206. In some embodiments, the ACR information notice includes T-EES identification information and an indication of which authorization token was used to authorize the transfer of context to T-EES216B. This message may trigger EEC206 to restart the procedure in step 1 to obtain a new token for S-EES216A for future ACR procedures, considering the token invalid. When the procedure is restarted, it should be noted that in some embodiments, S-EES may be an EES that is considered to be T-EES in this procedure (e.g., returning the context to S-EES).

[0124] In some embodiments, procedure 500 may begin with steps 4 and 5. S-EES216A may then perform step 10 to send the identification information of T-EES216B to EEC206. EEC206 may then perform steps 1, 2 and 3 to obtain a token specifically associated with T-EES216B. The delegated token message may then contain a token specifically associated with T-EES216B. The procedure may then proceed to steps 6, 7, 8 and 9.

[0125] Figure 6 shows an exemplary procedure 600 for EEC authorization of EEC context transfer in a scenario in which the ACR procedure is initiated by EEC206 and the procedure requires that the EEC context be pushed from S-EEA216A to T-EES216B. In some such embodiments, EEC206 may decide to perform the ACR procedure, obtain a token, and send the token to S-EES216A. S-EES216A may use the token to verify whether it is permissible to transfer the EEC context to T-EES216B. S-EES216A may provide the token to T-EES216B so that T-EES216B can verify that it is permitted to receive the EEC context.

[0126] In step 1, in some embodiments, EEC206 decides to perform an ACR procedure. For example, in some embodiments, EEC206 may be triggered to perform an ACR procedure based on the detection of a change in UE location, network conditions, etc. In other embodiments, EEC206 may be triggered to perform an ACR procedure based on a notification request from ECS218.

[0127] In step 2, in some embodiments, EEC206 performs a service provisioning procedure using ECS218. As part of the service provisioning procedure, in some embodiments, EEC206 receives information about EES216 available in the EDN. The received information may include identification information for EES216. In some implementations, the information may also include the coverage area of ​​EES216, enabling EEC206 to select T-EES216B based on the location of the UE / WTRU.

[0128] In step 3, in some embodiments, EEC206 selects one of the EES216s that should act as the target EES (T-EES216B) in the ACR procedure. In some embodiments, EEC206 also performs T-EAS discovery to determine the identification information of T-EAS214B. For example, EEC206 may broadcast a query to available T-EAS servers, communicate with an EES216, or communicate with a management server.

[0129] In step 4, in some embodiments, EEC206 sends a request to server 402 and / or ECS218 to obtain an authorization token. In some embodiments, the authorization token may be used to authorize the transfer of the EEC context from source EES (S-EES216A) to T-EES218B. In some embodiments, the request to server 402 may include identification information for S-EES216A and T-EES218B. In some embodiments, the request also specifies the context to be transferred. In some embodiments, the session context is identified by an EEC context ID, or by a combination of identification information including ACID, EEC ID (or UE ID), S-EAS endpoint, and T-EAS endpoint. In some embodiments, the session context may be identified such that multiple ACR procedures for the same EEC (UE), S-EES, and T-EES may occur simultaneously. In some embodiments, the request may also include a requested token validity period indicating to the server that it should consider the token valid only for the specified period. The request can be integrated with the service provisioning procedure.

[0130] In step 5, in some embodiments, the server 400 and / or ECS218 respond to EEC206 with an authorization token. In some embodiments, the response includes a token validity period indicating how long the server considers the token to be valid.

[0131] In step 6, in some embodiments, EEC206 initiates the ACR initiation procedure by sending an ACR request to S-EES216A. In some embodiments, the request includes an authorization token and the identification information of the selected T-EES216B. In some embodiments, the request also includes information used by S-EES216A to identify the EEC context that needs to be transferred as part of the ACR procedure (e.g., EEC context ID or ACID, EEC ID (or UE ID), S-EAS endpoint, and T-EAS endpoint). In some embodiments, S-EES216A may determine whether an authorization token is required to perform the context transfer. The determination of whether an authorization token is required may be based on local policies or indications previously received from EEC206 (i.e., during the registration procedure).

[0132] In step 7, in some embodiments, S-EES216A sends an ACR response message to EEC206. If S-EES determines that the authorization token was not included in the ACR request, the token was not properly formatted (e.g., not associated with the identified T-EES216B), the token has expired, or the token is not associated with the context that needs to be transferred, in some embodiments, S-EES216A may indicate that the request has been rejected and include a cause code that identifies the reason for the rejection.

[0133] In step 8, in some embodiments, S-EES216A may verify the validity of being authorized to transfer the EEC context to T-EES216B by validating the token, and S-EES216A may interact with a token server (not shown in the figure). If authorized, S-EES216A may initiate the EEC context push transfer procedure using the identified T-EES216B by sending a push EEC context request to T-EES216B. The EEC context push may include an authorization token.

[0134] In step 9, if a token is included, in some embodiments, T-EES216B may send a request to the server to verify that the token is valid and that it is effective in the context being forwarded.

[0135] In step 10, in some embodiments, the server 400 and / or ECS218 respond to T-EES216B. The server 400 and / or ECS218 may inform T-EES216B whether the token is valid or invalid. If the server informs T-EES216B that the token is invalid, it may include the reason why it is invalid (for example, that it has expired).

[0136] In step 11, in some embodiments, T-EES216B sends a push EEC context response message to S-EES216A indicating success or failure. If the failure is due to an invalid token, T-EES216B may inform S-EES216A that the token is invalid, and T-EES216B may include the reason why it is invalid (e.g., it has expired, it is not permitted to be transferred to the T-EES instance).

[0137] In step 12a or 12b, in some embodiments, S-EES216A or T-EES216B may each notify EEC206 whether the context push operation was successful or not. If the push was unsuccessful, in some embodiments, S-EES216A or T-EES216B may indicate why the operation was unsuccessful. In some embodiments, T-EES216B may notify EEC206 if the operation was successful, and / or S-EES216A may notify EEC206 if the operation was unsuccessful.

[0138] In step 13, in some embodiments, EEC206 sends a request to AC204 to initiate application context transfer. In some embodiments, EEC206 may be triggered to send this request by notification from S-EES216A or T-EES216B.

[0139] Figures 7A and 7B are flowcharts of one embodiment of method 700 for EEC authorization of EEC context transfer. In 702, in some implementations, the EEC 206 may request an authorization token 702 from the token server 400. The request may be transmitted via any suitable method or communication format, such as via the Uu wireless interface or via a management frame. The request may include identification information of the EEC and / or one or more associated ACs, UE ID or WTRU ID, or any other such information. In some implementations, the request may include identification information of the source and / or target EES.

[0140] In 704, the token server may, in some implementations, determine whether the EEC is permitted to request a token. For example, the token server may verify a cryptographic signature (e.g., the EEC's public key), a user ID, or any other such information. If not permitted, the request may be rejected either explicitly or by not returning a token. If permitted, in 706, the token server 400 may generate a token and provide it to the EEC. The token may be of any type and format and may include a cryptographic hash or signature, a UE or WTRU ID, a source and / or target EES identifier, or any other such information. For example, in some implementations, the token may include authorization restrictions, such as an expiration time, location, application type or class, a user identifier, a T-EES identifier, or restrictions of any other type and form. In 708, the EEC may receive the token.

[0141] As discussed above, in some implementations, the application context may be "pushed" from the source EES to the target EES, while in other implementations, the application context may be "pulled" from the source EES by the target EES. As used herein, push and pull may correspondingly indicate which EES initiates the context transfer from the other EES (e.g., pull by T-EES or push by S-EES).

[0142] If the device is configured for “pull” mode in 710, then in 712, in some embodiments, the EEC206 may decide whether to transfer the application context. This may be based on any type and form of information or measurements, such as the device’s location, measurements of network characteristics including latency, throughput, bandwidth, and congestion, and geographical proximity to the EES.

[0143] In some implementations, in response to the decision to transfer the application context, in 714, EEC206 may provide an authorization token to the target server (e.g., T-EES216B). In some implementations, providing an authorization token may involve selecting a T-EES from among several EESs that is suitable to receive the application context and provide application services after the transfer. The T-EES may be selected based on its location, its network connectivity, or the characteristics of the network connectivity between the EEC and the T-EES. For example, the T-EES may be selected based on characteristics (e.g., physical, logical, functional, or other such characteristics) that match, conform to, or correspond to the authorization restrictions associated with the token, as discussed above. In 716, T-EES216B may receive the token. As discussed above, the token may include authorization restrictions such as expiration time, location, application type or class, user identifier, T-EES identifier, or any other type and form of restrictions.

[0144] In 718, T-EES216B may attempt to validate or verify the token. Validating a token may involve verifying the hash or cryptographic signature of the token, or sending a message to the token server 400 or other authorization server requesting information to validate the token. For example, in some implementations, T-EES may provide the token server with a user identifier, location, or any other such information. In some embodiments, the token may be signed using the token server's private key, and T-EES may verify the origin of the token by verifying the token server's public key and the token's information payload. In 720, the token server may validate the token (e.g., by comparing the token to a user or EEC database, etc.) and / or verify the token's authorization restrictions (e.g., that T-EES216B is authorized to use the token for context transfer, that the token is not expired, that the token is associated with an application provided by T-EES or an associated EAS, that the characteristics of T-EES correspond to or conform to the authorization restrictions associated with the token, etc.). The token server may respond to T-EES with authorization or error identification information (or other messages indicating token invalidity or lack of authorization to use the token).

[0145] In 722, if the token is valid, the T-EES may send a request for context information of the application client (e.g., a context "pull" request) from the S-EES that was providing the service to the AC. The request for context information may include the token and / or identification information of the token's authorization or validity, identification information of the AC or EEC or UE / WTRU or the device user, or any other type and format of information. In 724, the S-EES may provide the context to the target server. The context may be in any suitable format, such as a flat file, a database, parameter value pairs, data strings or arrays, a bitmap, XML data, compressed data, or any other type and format of information for providing state or context information of the application client and / or application server.

[0146] In 726, T-EES may provide EEC206 with Application Context Transfer (ACR) information to complete the transfer, such as synchronization or handshake information with T-EES, status information or other identifiers, or any other type and format of information that would enable EEC and / or AC to resume using applications provided by EAS. In 728, EEC206 may receive this ACR information and use it to continue AC's communication with the corresponding EAS (for example, to continue accessing a web application).

[0147] As shown in Figure 7B, in an implementation using context push requests, at 730, EEC206 may send an authorization token to EES-S. As discussed above, this may occur at some point before the loss or failure of communication or before the physical movement of the UE / WTRU, and therefore the sending of the token may not indicate that context transfer is being performed.

[0148] In 732, EES-S216A may determine whether a relocation is required. For example, EES-S216A may monitor communications with EEC206 to determine whether the UE / WTRU has moved beyond a designated area, or whether communications have been impaired or slowed (e.g., due to interference or congestion). If not, EES-S may remain on standby (and continue to provide application services to AC). If so, in 734, EES-S may select a target server. The selection of T-EES216B may involve identifying a T-EES associated with the new location of the WTRU / UE, identifying a T-EES with sufficient bandwidth or processing resources, etc. In some implementations, the selection of T-EES may involve determining whether the characteristics of the T-EES match, conform to, or correspond to the authorization restrictions associated with the token. In 736, EES-S may send a context transfer request to T-EES. A request may include a token or token identifier (e.g., a hash or other cryptographic function), an application client identifier, an EEC, a user identifier, an UE or WTRU, or any other such information. In some implementations, the request may include authorization restrictions or other such information.

[0149] In 738, T-EES may attempt to validate the token. Validating the token may involve sending the token, the hash of the token, the signed version of the token, or any other type and format of information to the token server 400. In some implementations, validating the token may involve determining that the token is not expired and / or that T-EES is authorized to use the token (whether it is valid). In 740, the token server may determine whether the token is valid, provide T-EES with either the token information or similar information, respectively, or send an error message to T-EES (for example, indicating that the token is invalid, expired, or that T-EES does not have the authority or permission to use the token).

[0150] In 742, if the token is valid and the T-EES is authorized, the T-EES may send a response to the initial transfer request. In some implementations, the response may request that context information be provided to the T-EES. In 744, in response to receiving a response to the context transfer request, the S-EES may provide ACR information to the EEC and / or any other type and format of information (e.g., identification information such as the selected target server or T-EES). In 746, the EEC may receive confirmation via any appropriate means (e.g., a UU interface or other such interface).

[0151] Figure 8 is a flowchart of one embodiment of method 802 for EEC authorization of EEC context transfer from the perspective of a token server or ECS. In some implementations, in 802, the server may receive a request for an authorization token. The request may be received from the UE / WTRU, from the AC or EAC performed by or on behalf of the UE / WTRU, etc. The request may contain identification information for the UE / WTRU, AC and / or EAC, S-EES and / or T-EES for context transfer, or information of any other type and format.

[0152] In 804, in some implementations, the server may provide a token to the requesting entity (e.g., UE / WTRU, AC or EAC performed by or on behalf of the UE / WTRU). The token may have one or more authorization restrictions, including an expiration time or date, and identification information of the applications and / or EES that can provide the application service.

[0153] Subsequently (for example, during the context transfer process), in 808, the token server may receive a request from the S-EES or T-EES to validate the token. The request may include any type and form of auxiliary information, such as the AC, EAS, or EES identifier, the token's usage time or validity period, and a user identifier. In some implementations, the token may be signed via a cryptographic key pair, and the token server may include the signed data in the original token data to ensure that it is still valid.

[0154] If the token is invalid or expired, or if the T-EES does not have authorization for context transfer (for example, it does not have characteristics that match or conform to the authorization restrictions associated with the token), in 810, the token server may reject the token and provide identification information for the reason for rejection (for example, expiration of validity period, restrictions on which EESs are permitted or eligible to use the token). If the T-EES has authorization and / or the token is valid, in 812, the token server may provide authorization confirmation to the requesting device or entity. For example, if the T-EES requests that the token be validated, the token server may provide an acknowledgment or other notification of the token's validity, or authorization to perform a context transfer to the T-EES. If the S-EES requests that the token be validated, the token server may provide an acknowledgment or other notification of the token's validity, or authorization to perform a context transfer to the S-EES.

[0155] Accordingly, this disclosure covers embodiments of methods and systems for authorizing the transfer of specific instances of context from an S-EES to a T-EES. Embodiments of these methods and systems can ensure that context information associated with an EEC is transmitted only to T-EES authorized to receive the context.

[0156] In a first aspect, the disclosure relates to a method for authorizing an edge enabler client (EEC) context transfer. The method also includes deciding to transfer an application context from a first edge enabler server by an edge enabler client (EEC) operated by a wireless transmit / receive unit (WTRU). In response to this decision, the method includes requesting an authorization token from a token server by the edge enabler client (EEC), the request comprising identification information for the application context and identification information for one or more authorization restrictions, the one or more authorization restrictions corresponding to the characteristics of the edge enabler server required for authorization. The method also includes receiving an authorization token for the application context and, in some implementations, identification information for one or more authorization restrictions from the token server by the EEC. The method also includes transmitting the authorization token to the first edge enabler server by the EEC. The method also includes receiving an indication from one of the first and second edge enabler servers by the EEC that an authorization token was used to authorize the transfer of context from the first edge enabler server to the second edge enabler server in response that the second edge enabler server has characteristics that match one or more authorization restrictions.

[0157] In some implementations, the indication is received by a second edge enabler server, which then sends the indication to the EEC in response to successfully retrieving EEC context information from the first edge enabler server. In further implementations, the method includes the EEC selecting a second edge enabler server from among several edge enabler servers. In yet another further implementation, the method includes the EEC sending an application context transfer request to the second edge enabler server, the application context transfer request comprising an authorization token.

[0158] In some implementations, the indication is received by a first edge enabler server, which then sends the indication to the EEC in response to the first edge enabler server successfully pushing the EEC context information to a second edge enabler server. In further implementations, the first edge enabler server selects the second edge enabler server from among multiple edge enabler servers.

[0159] In some implementations, the method includes determining to transfer the application context from a first edge enabler server by monitoring the physical location or movement of the WTRU. In some implementations, the method includes the EEC sending a request containing the identification information of one or more authorization restrictions. In further implementations, one or more authorization restrictions contain the identification information of a target edge enabler server that is authorized to use an authorization token to receive the transferred application context.

[0160] In some implementations, one or more authorization restrictions do not identify a specific edge enabler server. In some implementations, one or more authorization restrictions include identifying information such as the validity period of the authorization token, location or region, minimum communication latency, application capability, or maximum utilization level.

[0161] In another embodiment, this disclosure relates to a method. The method includes the authorization token server receiving a request for an authorization token from an edge enabler client (EEC) executed by a wireless transmit / receive unit (WTRU), the request comprising identification information for an application context associated with a first edge enabler server and identification information for one or more first authorization restrictions, the one or more authorization restrictions corresponding to the characteristics of the edge enabler server required for authorization. The method also includes the authorization token server providing the authorization token to the EEC. The method also includes the authorization token server subsequently receiving an authorization token from a second edge enabler server. The method also includes the authorization token server determining, based on the characteristics of the second edge enabler server matching one or more authorization restrictions, that the authorization token is valid and that the authorization token authorizes the transfer of the application context to the second edge enabler server. In response to the determination, the method also includes the authorization token server communicating authorization for the transfer of the application context to one or more of the EEC, the first edge enabler server, and the second edge enabler server.

[0162] In some implementations, one or more authorization restrictions do not identify individual edge enabler servers. In some implementations, one or more authorization restrictions include identification information for individual target edge enabler servers that are permitted to use the authorization token to receive the transferred application context. In some implementations, one or more authorization restrictions include location or region, minimum communication latency, application capability, or maximum utilization level. In some implementations, one or more authorization restrictions include the validity period of the authorization token. In some implementations, the application context includes WTRU or user equipment (UE) identification information, location information, application client (AC) profile, or service session context information.

[0163] In another aspect, the disclosure covers a wireless transmit / receive unit (WTRU) configured to implement an embodiment of the method discussed above. In another aspect, the disclosure covers a user device (UE) configured to implement an embodiment of the method discussed above. In another aspect, the disclosure covers a network device configured to implement an embodiment of the method discussed above. In another aspect, the disclosure covers a computing device configured to implement an embodiment of the method discussed above. In another aspect, the disclosure covers an integrated circuit configured to implement an embodiment of the method discussed above. In another aspect, the disclosure covers a non-temporary computer-readable medium comprising instructions executed by a processing device to cause the processing device to implement an embodiment of the method discussed above.

[0164] While features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in computer programs, software, or firmware embedded on computer-readable media for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital multi-purpose disks (DVDs). A processor may be used in conjunction with software to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method for authorizing Edge Enabler Client (EEC) context transfer, The Edge Enabler Client (EEC), which is executed by the Wireless Transceiver Unit (WTRU), decides to transfer the application context from the first Edge Enabler Server, In response to the aforementioned decision, the token server requests an authorization token from the EEC, the request comprising the identification information of the application context and the identification information of one or more authorization restrictions, the one or more authorization restrictions corresponding to the characteristics of the edge enabler server required for authorization, The EEC receives the authorization token for the application context from the token server, The EEC transmits the authorization token and the identification information of one or more authorization restrictions to the first edge enabler server, The EEC receives an indication from one of the first and second edge enabler servers that the authorization token was used to authorize the transfer of context from the first edge enabler server to the second edge enabler server in response to the second edge enabler server having characteristics consistent with the one or more authorization restrictions. Methods that include...

2. The method according to claim 1, wherein the indication is received from the second edge enabler server, and the second edge enabler server transmits the indication to the EEC in response to successfully retrieving EEC context information from the first edge enabler server.

3. The method according to claim 2, further comprising selecting the second edge enabler server from a plurality of edge enabler servers by the EEC.

4. The method according to claim 2, further comprising the EEC sending an application context transfer request to the second edge enabler server, wherein the application context transfer request comprises the authorization token.

5. The method according to claim 1, wherein the indication is received from the first edge enabler server, and the first edge enabler server transmits the indication to the EEC in response to the first edge enabler server successfully pushing EEC context information to the second edge enabler server.

6. The method according to claim 5, wherein the first edge enabler server selects the second edge enabler server from a plurality of edge enabler servers.

7. The method according to any one of claims 1 to 6, wherein deciding to transfer the application context from the first edge enabler server includes monitoring the physical location or movement of the WTRU.

8. The method according to any one of claims 1 to 7, wherein the one or more authorization restrictions do not specify a particular edge enabler server.

9. The method according to any one of claims 1 to 8, wherein the one or more authorization restrictions include identification information of the validity period, location or area, minimum communication latency, application capability, or maximum utilization level of the authorization token.

10. The authorization token server receives requests for authorization tokens from edge enabler clients (EECs) executed by wireless transceiver units (WTRUs), wherein the requests comprise identification information of an application context associated with a first edge enabler server and identification information of one or more authorization restrictions, the one or more authorization restrictions corresponding to the characteristics of the edge enabler server required for authorization. The authorization token server provides the authorization token to the EEC, The authorization token server subsequently receives the authorization token from the second edge enabler server, Based on the fact that the characteristics of the second edge enabler server match the one or more authorization restrictions, the authorization token server determines that the authorization token is valid and that the authorization token authorizes the transfer of the application context to the second edge enabler server. In response to the aforementioned decision, the authorization token server communicates authorization for the transfer of the application context to one or more of the EEC, the first edge enabler server, and the second edge enabler server. Methods that include...

11. The method according to claim 10, wherein the one or more authorization restrictions do not specify a particular edge enabler server.

12. The method according to claim 10 or 11, wherein the one or more authorization restrictions include location or area, minimum communication latency, application capability, or maximum utilization level.

13. The method according to any one of claims 10 to 12, wherein the one or more authorization restrictions include a period of validity for the authorization token.

14. The method according to any one of claims 10 to 13, wherein the application context comprises WTRU or user device (UE) identification information, location information, application client (AC) profile, or service session context information.

15. A wireless transceiver unit (WTRU), A WTRU configured to perform the method described in any one of claims 1 to 14.

16. User equipment (UE), A UE configured to perform the method described in any one of claims 1 to 14.

17. A network device, A network device configured to perform the method described in any one of claims 1 to 14.

18. A computing device, A computing device configured to perform the method described in any one of claims 1 to 14.

19. Integrated circuits An integrated circuit configured to perform the method described in any one of claims 1 to 14.

20. A non-temporary computer-readable medium comprising an instruction, which, when executed by a processing device, causes the processing device to perform the method according to any one of claims 1 to 14.

Images