Method and apparatus for enabling wireless transmit receive unit (WTRU) - based edge computing scaling

Abstract

To provide a method and apparatus for wireless transmit / receive unit (WTRU) - based edge computation auto-scaling.SOLUTION: In a communication system, a WTRU receives, from a network device, a message including a list of one or more edge application servers (EASs) associated with an uninstantiated application, selects an EAS from the list of one or more EASs associated with the uninstantiated application, and transmits, to an edge data network (EDN), a request to instantiate the uninstantiated application at the selected EAS, indicating from the EDN that the uninstantiated application has been instantiated at the selected edge application server. And receive a response indicating information for accessing a current instantiated application in the EAS.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 277,391, filed November 9, 2021, which is incorporated herein by reference in its entirety. [Background technology]

[0002] Self-Organizing Network (SON) is a concept defined as automation techniques designed to make planning, configuration, management, optimization, and repair of mobile radio access networks simpler and faster. The SON concept also exists in cloud computing. An important aspect of cloud computational self-organization is called autoscaling. Autoscaling is a method for dynamically adjusting the number of servers in a group using the group's computational load. The goal is to enable cloud applications to scale as usage increases. Cloud scaling techniques typically rely on key performance indicators (KPIs) measured at the servers and provided by load balancers that steer incoming traffic to these servers. Autoscaling is coarse-grained and typically applied reactively to demand. This technique is well suited to data center environments where computers are co-located and abundant. As edge computing becomes ubiquitous and computation moves closer to mobile devices, scaling of edge network resources needs to evolve. However, auto-scaling in cloud computing is not adequate to handle the fine-grained, limited, and distributed computation at the edge. Therefore, a method and apparatus that enables auto-scaling for mobile edge computing is needed. Summary of the Invention

[0003] Methods and apparatus for wireless transmit / receive unit (WTRU)-based edge compute autoscaling are described herein. For example, a WTRU may send an EAS discovery request including one or more edge application server (EAS) requirements to an edge data network (EDN). The WTRU may receive an EAS discovery response from the EDN including a list of EASs to be executed and on-demand EASs, e.g., EASs that are not executed. Based on a selection of an on-demand EAS from the list of executed EASs and on-demand EASs, the WTRU may send an on-demand EAS instantiation request to the EDN indicating the selected on-demand EAS. The WTRU may receive an on-demand EAS instantiation response from the EDN indicating EAS instantiation synchronously or asynchronously. Provided that EAS instantiation is indicated synchronously, the on-demand EAS instantiation response may include EAS information associated with the selected on-demand EAS. On the condition that the EAS instantiation is indicated asynchronously, the on-demand EAS instantiation response may include a result code indicating the status of the EAS instantiation, and the WTRU may receive an on-demand EAS instantiation notification from the EDN that includes EAS information associated with the selected on-demand EAS. The WTRU may transmit data to the selected on-demand EAS based on the EAS information.

[0004] The method performed by the WTRU may include receiving a message from a network device. The message may provide a list of one or more EAS identifiers. Each EAS identifier may be associated with an uninstantiated application. The method may include selecting one or more EAS identifiers from the list of EAS identifiers associated with the uninstantiated applications. The method may include sending a message to an EDN. The message may be provided indicating a request to instantiate one or more uninstantiated applications in the EDN. The method may include receiving a response from the EDN. The response may include an indication that the uninstantiated applications have been instantiated in the selected EDN and may include information for accessing the newly instantiated application instances in the EDN.

[0005] The method may include sending an EAS discovery request to an EDN. The EAS discovery request includes indicating one or more EAS requirements. The method may provide that sending a message provides an EAS discovery response received in response to the EAS discovery request.

[0006] The method can include including a list of one or more EAS identifiers associated with already-instantiated versions of the instantiated application.

[0007] The method may provide for transmitting information for accessing the newly instantiated application, which may indicate whether the newly instantiated application was instantiated synchronously or asynchronously.

[0008] The method may provide for sending information for accessing the newly instantiated application indicating that the newly instantiated application was instantiated synchronously. The method may provide for sending information that the EAS instantiation response includes EAS information that enables the WTRU to access the newly instantiated application.

[0009] The method can include receiving, in response, the selected EAS Internet Protocol (IP) address, URL, or FQDN.

[0010] The method may provide each uninstantiated application corresponding to an uninstantiated EAS included in the EDN.

[0011] The WTRU may be configured to receive messages from a network device. The message may provide a list of one or more edge application servers associated with the uninstantiated application. The WTRU may select an EAS from the list of one or more EASs associated with the uninstantiated application. The WTRU may send a request to the EDN. The request may request instantiation of the uninstantiated application in the selected EAS. The WTRU may receive a response from the EDN, which may indicate that an uninstantiated application has been instantiated in the selected EAS and / or may indicate information for accessing a currently instantiated application in the EAS.

[0012] The WTRU may be configured to send an EAS discovery request to the EDN. The EAS discovery request may indicate one or more EAS requirements. The WTRU may send a message including an EAS discovery response received in response to the EAS discovery request.

[0013] The WTRU may send a request to the EAS of the EDN.

[0014] The WTRU may send a message including a service provisioning message.

[0015] The WTRU may include the information for accessing the currently instantiated application indicating that the currently instantiated application was instantiated synchronously, and the edge application server instantiation response including edge application server information associated with the selected edge application server.

[0016] The WTRU may include the Internet Protocol (IP) address of the selected EAS in its response.

[0017] The method implemented by the WTRU may include sending an application server discovery request to a data network. The application server discovery request may include indicating one or more application server requirements. The method may further provide for receiving an application server discovery request message from the network device. The message may include a list of one or more application servers associated with the application that satisfy the one or more application server requirements. The application server discovery request may provide for an indication that the application is not currently instantiated on the one or more application servers. The method may provide for selecting an application server from the list of one or more application servers associated with the application. The method may include sending a request to the data network. The request may include indicating a request to instantiate the application on the selected application server. The method may include receiving a response from the network. The response may include an indication that the application has been instantiated on the selected application server and information for accessing the application on the application server.

[0018] The method can include including a list of one or more application servers associated with the application on which the application is currently instantiated.

[0019] The WTRU may be configured to send an EAS discovery request to the edge data network. The EAS discovery request may indicate one or more EAS requirements. The EAS may receive an EAS discovery response message from the EDN, where the message includes a list of one or more EASs that satisfy the one or more EAS requirements. The EAS discovery request may indicate that an EAS is not currently instantiated. The WTRU may select an EAS from the list of one or more EASs. The WTRU may send a request to the EDN. The request may indicate a request to instantiate a selected EAS. The WTRU may receive a response from the EDN. The response may indicate that the selected EAS has been instantiated and may indicate information for accessing the selected application server.

[0020] The WTRU may be configured to receive an edge service provisioning procedure message from a network device. The edge service provisioning procedure message may include a list of one or more EASs that are not currently instantiated. The WTRU may select an EAS from the list of one or more EASs that are not currently instantiated. The WTRU may send a request to the EDN. The request indicates a request to instantiate the selected EAS. The WTRU may receive a response from the EDN. The response may indicate that the selected EAS has been instantiated and / or may indicate information for accessing the selected application server.

[0021] The WTRU may send a request to an edge enabler server (EES) of the EDN and / or receive a response from the EES.

[0022] The WTRU may provide a message that includes a list of one or more existing EASs.

[0023] The WTRU may indicate that the information for accessing the currently instantiated EAS indicates whether the current EAS was instantiated synchronously or asynchronously.

[0024] The WTRU may include information for accessing the currently instantiated EAS, and the information may indicate that the currently instantiated EAS was instantiated synchronously and / or a service provisioning procedure message. [Brief explanation of the drawings]

[0025] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate similar elements and in which: [Figure 1A] FIG. 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] FIG. 1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] FIG. 1D is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 2] FIG. 2 is a diagram illustrating an example SA6 architecture for enabling edge applications. [Figure 3] FIG. 3 is a diagram illustrating an exemplary high-level cloud service architecture. [Figure 4] FIG. 4 is a diagram illustrating an exemplary machine learning-based context-aware rule learning framework. [Figure 5] FIG. 5 is a diagram illustrating an example high-level overview of a WTRU on-demand edge application server (EAS) instantiation. [Figure 6] FIG. 6 is a diagram illustrating an example procedure for WTRU on-demand EAS instantiation. [Figure 7] FIG. 7 is a diagram illustrating an example procedure for WTRU on-demand EAS selection. [Figure 8] FIG. 8 is a diagram illustrating an example procedure for WTRU on-demand EAS termination. [Figure 9] FIG. 9 is a diagram illustrating an example procedure for edge enabler server (EES) on-demand EAS instantiation. [Figure 10] FIG. 10 is a diagram illustrating an example WTRU-based edge auto-scaling architecture. [Figure 11] FIG. 11 is a diagram illustrating an example WTRU-based edge auto-scaling architecture in an edge enabler client (EEC); and [Figure 12] FIG. 12 is a diagram illustrating an example WTRU-based edge auto-scaling architecture using network artificial intelligence (AI) / machine learning (ML). DETAILED DESCRIPTION OF THE INVENTION

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

[0027] 1A, communications 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, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a mobile phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., remote surgery), an industrial device and application (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), a home electronic device, a device operating in a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

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

[0029] The base station 114a may be part of the 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), relay nodes, etc. The base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers per sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

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

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

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

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

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

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

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

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

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

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

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

[0041] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), 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 functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0042] The transmit / receive element 122 may be configured to transmit or receive signals to or 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 IR signals, UV signals, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and light signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0043] 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. 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 over the air interface 116.

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

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

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

[0047] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information from 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 appreciated that the WTRU 102 may obtain location information by way of any suitable position-determination method while remaining consistent with an embodiment.

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

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

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

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

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

[0053] 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN), packet data gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0080] A key feature of modern mobile networks is their ability to self-organize. Self-organizing network (SON) is a concept defined as automation techniques designed to make planning, configuration, management, optimization, and repair of mobile radio access networks simpler and faster. The SON concept can be applied to radio resources as terminals move within the network, with the network constantly adjusting to terminal mobility to provide the best user experience.

[0081] SON concepts can also be present in cloud computing. An important aspect of cloud computational self-organization is called autoscaling. Autoscaling can be defined as dynamically adjusting the number of servers in a group using the computational load of that group, with the goal being to allow cloud applications to scale as usage increases. Cloud scaling techniques typically rely on key performance indicators (KPIs) measured at the servers and provided by load balancers that steer incoming traffic to these servers. Autoscaling is coarse-grained and typically applied reactively to demand, making this technique well suited to data center environments where computers are co-located and abundant.

[0082] As edge computing becomes ubiquitous and computation moves closer to mobile devices, methods and apparatuses are needed for scaling edge network resources. Cloud computing autoscaling is not adequate to handle the fine-grained, limited, and distributed computation at the edge.

[0083] Mobile edge computing may require on-demand scaling with individual device context, as opposed to mass cloud-based auto-scaling.

[0084] Similarly, SON has become a core concept in wireless network technology. Therefore, it is expected that Self-Organizing Edge Compute (SOEC) will become widespread in future edge technologies.

[0085] 2 is a diagram illustrating an example SA6 architecture for enabling edge applications. Examples for autoscaling and load balancing are described herein. As described above, a cloud-based autoscaling architecture is not suitable when this autoscaling architecture is used in an edge computing environment. Therefore, WTRU-based edge autoscaling and this edge autoscaling architecture are needed.

[0086] The WTRU 202 may include one or more application clients (ACs) 204. The application clients 204 may be user applications. The ACs 204 may communicate with one or more edge application servers (EASs) 206. The EASs 206 may be implemented as standalone servers or may be software modules implemented on general-purpose servers in the edge data network. The EASs may be implemented using any combination of hardware and software. Thus, when implemented as software on general-purpose servers, the edge application servers themselves may be instantiated and / or de-instantiated on demand. Similarly, applications running on the edge application servers may be instantiated and / or de-instantiated on demand. The WTRU 202 may use one or more ACs 204 simultaneously. Information communicated between the ACs 204 and the EASs 206 may be application data traffic 208. The application data traffic 218 may be transmitted across a 3GPP core network 218. The EAS 206 and the 3GPP core network 218 may communicate via the Edge 7 reference point.

[0087] One or more edge enabler clients (EECs) 210 may reside on the WTRU 202 along with the ACs 204. The EECs 210 provide edge support to the ACs 204 on the WTRU 202. One or more ACs 204 and one or more EECs 210 may reside on the WTRU 202, but one AC 204 may receive support from one EEC 210. The EECs 210 may communicate with the ACs 204 via an Edge-5 node.

[0088] The edge configuration server (ECS) 212 may provide support functions needed by the EEC 210 and / or the edge enabler server (EES) 214. For example, the ECS 212 may discover one or more ESSs 214, provide edge configuration information to the EEC 210 and / or the EES 214, and / or register the ESSs 214. A network may include one or more ECSs 212.

[0089] The EEC 210 and the ECS 212 may communicate via an Edge-4 node. The ECS 212 and the EES 214 may communicate via an Edge-6 node. The EES 214 and the 3GPP core network 218 may communicate via an Edge-7 node. The ECS 212 and the 3GPP core network 218 may communicate via an Edge-8 node.

[0090] The EES 214 may provide necessary support functions for the EAS 206 and the EEC 210. For example, the EES 214 may provide EAS 206 configuration information to the EEC 210, publish application context transfer events, perform EEC 210 context transfers, publish 3G (3G) core network and service capabilities to the EAS 206, and / or register the EEC 210 and / or the EES 214. When the WTRU 202 is mobile and / or relocating, the EES 214 may have separate functionality. For example, before WTRU 202 mobility / relocation occurs, a source EES (S-EES) may be used. For example, after WTRU 202 mobility / relocation occurs, a target EES (T-EES) may be used. A network may include one or more EESs 214 per edge data network (EDN) 216.

[0091] The EES 214 and the EEC 210 may communicate through the Edge-1 node. The EES 214 and the EAS 206 may communicate through the Edge-3 node. The EES 214 may communicate with another EES 214 in the EDN 216 through the Edge-9 node.

[0092] The EAS 206 may function as a server residing within the EDN 216. In this capacity, the EAS 206 may operate as software that provides services to the AC 204. When the WTRU 202 is mobile and / or relocating, the EAS 206 may have separate functionality. For example, before the WTRU 202 mobility / relocation occurs, a source EAS (S-EAS) may be used. For example, after the WTRU 202 mobility / relocation occurs, a target EAS (T-EAS) may be used. A network may include one or more EASs 206 per edge data network (EDN) 216. Each EDN 216 may include a different set of EASs 206. For example, some EASs 206 may serve a group of WTRUs 202 and / or ACs 204. For example, some EASs 206 may exclusively serve a single WTRU 202 and / or AC 204.

[0093] Figure 3 illustrates an exemplary high-level cloud service architecture 300. Figure 3 further depicts the cloud service architecture's ability to perform auto-scaling.

[0094] Autoscaling may include, for example, methods for automatically changing (e.g., scaling up or down) the number of computing resources (e.g., servers) allocated to cloud data center 302. For example, cloud data center 302 may include one or more servers 304.

[0095] Without autoscaling, a cloud data center may waste resources during idle time and become unresponsive when handling too many incoming requests 306. Autoscaling may address the need to optimize resource usage and support elastic computation that self-adjusts as demand increases. Autoscaling may be performed by an agent, for example, an autoscaler 308. The autoscaler 308 may collect KPIs and evaluate the KPIs when the amount of computation needs to change.

[0096] The autoscaler 308 may use different types of KPIs. In an example, scheduled autoscaling may use a time period to increase / decrease the capacity of a service. In an example, front-end traffic autoscaling may be used to scale based on the number of incoming requests 306. One or more load balancers 310 process front-end incoming traffic 312, including KPIs, in front of the cloud servers 304. In an example, back-end scaling can be based on load (e.g., the number of jobs in the queue) or time (how long a job has been queued). The cloud servers 304 receive back-end traffic 314, including KPIs, during back-end scaling. Depending on the implementation, the autoscaler may rely on temporal front-end and back-end KPIs to make autoscaling decisions.

[0097] The role of the load balancer 310 in a cloud system may include steering traffic generated at the WTRUs 316 to available server resources 304. The load balancer 310 may steer traffic in a predetermined manner (e.g., round robin). The load balancer 310 may dynamically steer traffic by considering server load KPIs to direct requests to less busy servers 304.

[0098] Together, the autoscaler 308, load balancer 310, and KPI acquisition framework (e.g., front-end traffic 312 and back-end traffic 314) may comprise the components of any cloud computing architecture found today. An example cloud computing architecture may include context-aware rule learning from smartphone data, as described herein. This disclosure describes a WTRU 316-based edge autoscaling architecture that may use and / or interact with a context-aware framework present on the WTRU 316.

[0099] Recent developments and increases in the processing power of the WTRU 316 have driven the popularity and interest in context-aware technologies. Intelligent context-aware applications can be built on the WTRU 316 using data analysis and building data-driven context-aware systems. This requires advanced data analysis techniques with high accuracy and intelligent decision-making strategies based on context. Machine learning-based techniques can provide effective and efficient results for smartphone data analysis and corresponding context-aware rule learning.

[0100] 4 illustrates an exemplary machine learning-based context-aware rule learning framework. Specifically, FIG. 4 presents an exemplary machine learning (ML) framework for deriving context-aware rules from WTRU raw data, where the raw data may be obtained from various sources and then manipulated using various techniques, e.g., ML techniques and artificial intelligence techniques. These techniques may then derive context rules that are used to influence the behavior of the WTRU.

[0101] For example, a learning technique may involve the WTRU 402 performing a series of steps (e.g., layers) that involve the WTRU acquiring data, analyzing the data, and learning rules from the data acquisition and analysis. For example, a first step, e.g., Layer 1, involves the WTRU 402 participating in context data acquisition 406. Relevant data acquired via context data acquisition 404 may include, for example, smartphone logs, sensors, and / or external sources. Then, in Layer 2, i.e., context discretization 410, the WTRU 402 may analyze the acquired data through the use of different techniques, for example, time series modeling and / or context data clustering.

[0102] From analyzing this data, the WTRU 402 may then generate several rules during the rule discovery 414 phase of level 3. To the discovered rules, the WTRU 402 may apply context preferences, rule-based learning techniques, and / or rule generalization parameters.

[0103] When the WTRU 402 has applied the described techniques during rule discovery 414, the WTRU 402 may refine the learned rules at level 4, known as dynamic updating and management 418. The WTRU may apply recency analysis and mining techniques in refining the WTRU's learned rules. The WTRU 402 may also perform rule updates to keep the learned rules up-to-date using the acquired data and modeling techniques used in context discretization 410.

[0104] The WTRU 402 may apply the newly learned and defined rules when serving real-world applications and services 422. At this stage, the WTRU may serve applications while supporting the WTRU's newly learned and defined rules.

[0105] As explained above, cloud autoscaling may not meet the properties required to realize a self-organizing edge compute (SOEC) architecture.

[0106] As illustrated in FIG. 2, the 3GPP SA6 architecture defines an edge-enabled architecture that may provide a means for a terminal to discover and use an edge application server (EAS). This architecture combines EAS discovery with EAS instantiation, causing a WTRU that attempts to perform discovery of available EASs (e.g., to select the best available option) to instantiate computations in an undesirable manner. As explained below, a WTRU behaving in this manner violates the fine-grained resource management principles required for edge computing. In examples, combining EAS discovery with EAS instantiation may cause unnecessary EAS instantiation and waste computational resources. A WTRU needs to discover and / or request instantiation of possible EASs and use EASs independently.

[0107] The current 3GPP SA6 architecture lacks the ability to terminate EAS when it is not needed. This lack of ability leaves resources unused, thereby contradicting the fine-grained resource management principles required for edge computing. Unused EAS resources remain unused, thereby wasting computational resources. The WTRU must indicate that it has stopped using the edge computational resources.

[0108] Compute overprovisioning is driving public cloud waste to $26.6 billion in 2021, up from $17.6 billion in 2020, and the trend is accelerating. This illustrates the coarse-grained nature of cloud autoscaling methods, which can be disastrous when used in distributed, resource-constrained edge environments. Therefore, cloud-based autoscaling is coarse-grained and may not meet the fine-grained autoscaling requirements of resource-limited edge environments.

[0109] Examples of related architectures include, for example, enabling SOEC in a 3GPP edge architecture, enabling WTRU-based edge compute management for a 3GPP edge architecture, and / or enabling fine-grained autoscaling in a 3GPP edge architecture.

[0110] As explained above, to achieve SOEC, WTRU-based edge auto-scaling may be required.

[0111] In examples, the capabilities of the 3GPP edge-enabled architecture required to support the WTRU-based edge auto-scaling architecture are described herein. These capabilities may include, for example, Error! Reference Source Not Found, Error! Reference Source Not Found, Error! Reference Source Not Found, and / or Error! Reference Source Not Found.

[0112] Also described herein are example WTRU-based edge autoscaling architectures based on 3GPP edge enablement layers, WTRU-based autoscaling, and WTRU methods for on-demand EAS upscaling.

[0113] On-demand EAS upscaling may occur when a terminal (e.g., a network node, a network device, and / or a WTRU) attempts to discover an EAS to consume an edge service. The procedure may include discovering an on-demand EAS that has not yet been executed and requesting execution of the on-demand EAS.

[0114] In an example, an edge compute node may have sufficient compute resources to over-provision EASs at the edge. When over-provisioning occurs, more EASs than necessary may be created, and needed resources may go unused and wasted until needed. Over-provisioning is common in cloud environments where resources are abundant. Computational elasticity may be achieved using cloud auto-scaling algorithms and / or procedures.

[0115] A typical edge computing environment is resource constrained and therefore optimized so that only the required EASs are instantiated. A terminal needs to be able to discover uninstantiated EASs and trigger their instantiation when the terminal attempts to use the resource and for the duration the terminal needs to use the resource.

[0116] Figure 5 illustrates an example high-level overview of WTRU on-demand EAS instantiation 500. As illustrated in Figure 5, network components comprising EAS instantiation may include a WRTU 502, an EDN 504, and a Resource Management System (RMS) 506. The WTRU 502 may include an AC 508 and an EEC 510. The EDN 504 may include an EES 512 and an EAS 514. The RMS 506 may comprise an orchestrator and / or an EAS registry 516 (e.g., a 3GPP management system).

[0117] As illustrated in FIG. 5, the on-demand edge EAS 514 instantiation of the WTRU 502 may include four phases: EDN initialization 530, EAS discovery 540, EAS instantiation 550, and EAS usage 560.

[0118] EDN initialization 530 may occur during creation and / or configuration of the EDN 504. During EDN initialization 530, the RMS 506 may create and initialize an edge-enablement layer. The RMS 506 may indicate to the newly created EES 512 which EASs 514 are available for on-demand instantiation of the WTRU 502.

[0119] EAS discovery 540 may occur at EDN 504 runtime when an AC 508 needs to use the EAS 514. The AC 508 may trigger EAS 514 discovery carried by the EEC 510. The WTRU 502 may discover available EAS 514 instances in the EDN 504. The EEC 510 residing on the WTRU 502 may discover to run the on-demand EAS 514.

[0120] The EAS instantiation 550 may occur at the EDN 504 runtime when the WTRU 502 decides to perform the on-demand EAS instantiation 550. This may be performed by the EEC 510 residing on the WTRU 502. The WTRU 502 may perform signaling with the edge enablement layer to trigger the on-demand EAS instantiation 550. This may be performed by the EEC 510 residing on the WTRU 502. The EES 512 may perform signaling with the RMS 506 to perform the on-demand EAS instantiation 550.

[0121] EAS usage 560 may occur at EDN 504 runtime, for example, when a newly created EAS 514 becomes available to the WTRU 502. The WTRU 502 may access and use the newly created EAS 514. The access and usage may be performed by the AC 508 resident on the WTRU 502.

[0122] Figure 6 illustrates an example procedure 600 for on-demand EAS instantiation for a WTRU 602. Figure 6 provides details of the on-demand EAS instantiation procedure introduced in Figure 5. Figure 6 illustrates detailed messaging flows between the WTRU 602, the EDN 604, and / or the RMS 606 required for the WTRU 602 to perform the on-demand EAS instantiation required for terminal-based edge auto-scaling.

[0123] The pre-conditions, conditions, configurations, network-configured information, pre-configuration, and / or pre-configured information to the WTRU 602 may include, for example, the WTRU 602 having a valid subscription that enables communication and use of edge services present in the mobile network, the WTRU 602 being attached to the mobile network, the WTRU 602 establishing a PDU session to the source EDN 604, and / or the WTRU 602 being provisioned with the security and authorization credentials necessary to communicate with elements that comprise the edge-enabled layer (e.g., ECS, EES, etc.).

[0124] Exemplary PDU session establishment procedures may be outlined in 3GPP standards. EDN 604 (also known as DNN) selection may typically be provided by the PCF using URSP rules. EDN 604 may also be provisioned via other methods (e.g., fixed, user profile, EEC, etc.).

[0125] During EDN initialization 630, the RMS 606 may have previously instantiated (not shown in FIG. 6 ) components of the edge enablement layer, such as the EES 612. If the EDN 604 is configured for EAS 614 over-provisioning, one or more EASs 614 may be created by the RMS 606 associated with the EDN 604. When an EAS 614 begins running, the EAS 614 may register with its associated EES 612.

[0126] In step 1a of 632, the orchestrator and / or registry 616 may cause the EDN 604 to fetch an EAS image from the orchestrator registry 616 (not shown in FIG. 6). The EDN 604 may begin execution of the fetched EAS 614 on a hardware platform present in the EDN 604. The EDN 604 configuration may trigger step 1a of 632, thereby instructing the RMS 606 to instantiate a predefined EAS 614. Alternatively or additionally, the EES 612 may trigger step 1a of 632 by requesting over-provisioning of one or more EASs 614.

[0127] In step 1b of 633, upon startup, each EAS 614 may register with its EAS 612. As a result, each registered EAS 614 may be discovered as a running EAS. Each registered EAS 614 may provide service to the WTRU 602.

[0128] In step 2, as part of the EDN initialization 630 procedure and to support on-demand EAS instantiation from the WTRU 602, the EES 612 may learn of the EASs 614 available for on-demand instantiation.

[0129] In an example, step 2a of 634 may include a message providing a list of on-demand EASs 614. The RMS 606 may provide the list of on-demand EASs. The orchestrator and / or registry 616 may know the list. The RMS 606 and / or orchestrator and / or registry 616 may provide the EES 612 via an API call to the EES 612.

[0130] Alternatively or additionally, at 635, the EES 612 may access and inspect the RMS 606 to learn the list of on-demand EASs 614. An API call to the RMS 606 and / or orchestrator and / or registry 616 may discover the EASs 614 list.

[0131] Alternatively or additionally, at 636, the EES 612 may have a pre-configured on-demand EAS 614 list.

[0132] Although not shown in FIG. 6, if the EES 612 was previously registered with the ECS, the EES 612 may update the EES 612's registration with the ECS by providing an on-demand EAS 614 list.

[0133] In step 3, when the WTRU 602 needs to use an edge service, the WTRU 602 may request to perform EAS discovery 640. For example, the AC 608 running on the WTRU 602 may request the EEC 610 to perform EAS 614 discovery.

[0134] In step 3a of 641, the AC 608 may notify the EEC 610 that the AC 608 wishes to use the EAS 614. This may be done via different techniques. For example, AC 608 can issue a DNS request that is intercepted by EEC 610. Alternatively or additionally, AC 608 can make an API call to EEC 610. Alternatively or additionally, AC 608 can use a software library that ultimately notifies EEC 610. Alternatively or additionally, AC 608 can make an OS call that notifies EEC 610.

[0135] In step 3b of 642, the EEC 610 may issue an EAS discovery request including the AC 608 identifier and an EAS 614 selection filter to the EES 612. Upon receiving the request, the EES 612 may perform a search for EASs 614 that can fulfill the AC 608 requirements. The EES 612 may consider running EASs 614 (e.g., registered EASs) and / or on-demand EASs 612 (e.g., a list of on-demand EASs) to perform the search for EASs 614 based on the request parameters. Both running and on-demand EASs 614 may be considered in the search for EASs 614 based on the request parameters.

[0136] 6, instead of or in addition to issuing an EAS discovery 640 request, the WTRU 602 and / or EEC 610 may subscribe to receive EAS 614 discovery notifications. The subscription may include an AC 608 identifier and / or an EAS 614 selection filter.

[0137] The information included in the EAS discovery 640 request is defined in 3GPP 23.558 v17.1.0, section 8.5.3.2. The information included in the EAS discovery 640 subscription is defined in 3GPP 23.558 v17.1.0, section 8.5.3.4. The discovery filters defined in 3GPP 23.558 v17.1.0, table 8.5.3.2-2, may be further provided with additional information, such as EAS614 categories and / or EAS614 on-demand discovery filters. The contents of 3GPP 23.558 v17.1.0 are incorporated herein by reference.

[0138] The EAS 614 category may indicate whether the requester wants to be notified about only EAS 614s (e.g., registered EASs), only on-demand EASs 614s (e.g., a list of on-demand EASs), and / or both types of execution. Alternatively or additionally, the EAS 614 status field may be extended to specify the EAS 614 category.

[0139] The EAS 614 on-demand discovery filter may include filter information indicating requested KPIs for on-demand instantiation. Alternatively or additionally, the EAS discovery 640 filter may be extended to specify an EAS 614 on-demand discovery filter. For example, an average instantiation duration may be used to specify that the average EAS instantiation 650 time will not be longer than the indicated duration for instantiating an EAS 614. An instantaneous instantiation duration may be used to specify that the EAS instantiation 650 time will not be longer than the indicated duration for instantiating an EAS 614 in the current platform state. An instantiation failure rate may specify that the average EAS instantiation 650 failure rate will not exceed the indicated failure rate when this EAS 614 is instantiated. Implicit on-demand instantiation using existing “AC Schedule” and “EAS Schedule” parameters may be used to provide a matching window that implicitly triggers the instantiation of one or more EAS 614 instances.

[0140] In step 3c of 643, the EES 614 may return a list of EASs 614 to the WTRU 602, which may include running (e.g., registered EASs) and / or on-demand (e.g., a list of on-demand EASs). Alternatively or additionally (not shown in FIG. 6), the EES 612 may send an EAS 614 discovery notification to the WTRU 602 if an EAS discovery 640 subscription is used.

[0141] The EAS discovery 640 response or notification may include a list of EASs 614, which should include the necessary information needed for EAS 614 selection and subsequent EAS 614 communication. The information provided to perform the EAS 614 (e.g., registered EASs) is defined in 3GPP 23.558 v17.1.0, Section 8.5.3.3 when using a request, and in 3GPP 23.558 v17.1.0 and Section 8.5.3.6 when using a notification. EAS profiles are defined in 3GPP 23.558 v17.1.0, Section 8.2.4.

[0142] The EAS profile, EAS discovery 640 response, and EAS discovery 640 notification are provided with information to support on-demand EAS 614, such as the EAS profile, EAS discovery 640 response, and / or EAS discovery 640 notification. The EAS 614 profile may include, for example, an EAS 614 category and / or an EAS 614 on-demand KPI. Alternatively or additionally, the EAS category and / or EAS status may indicate whether the EAS 614 is running EAS (e.g., registered EAS) or on-demand (e.g., list of on-demand EAS). Alternatively or additionally, the EAS 614 on-demand KPI and / or EAS service KPI may indicate on-demand EAS KPIs for instantiation. These EAS service KPIs may be the same as the EAS 614 on-demand discovery filter defined in step 3b of 642. The EAS discovery 640 response and / or EAS discovery 640 notification may include an existing lifetime parameter, which may be set to "0" to indicate an "on-demand" EAS 614.

[0143] In step 4 of 651, upon receiving the list of EASs 614 (as shown in step 3c of 643), the WTRU 602 may perform EAS 614 selection. The EEC 612 may perform this selection. As illustrated in FIG. 6, the EEC 612 may select an on-demand EAS 614 from the received list. The EEC 612 may send an on-demand EAS instantiation request 651 to the EES 612 indicating the selected EAS 614.

[0144] The on-demand EAS instantiation request 651 may be performed by invoking an API of the EES 612. Information in the request may include, for example, a requestor identifier, a WTRU 602 identifier, security credentials, a WTRU 602 location, requested service continuity (SC) support, a requested SC plan, EAS 614 characteristics, and / or EAS 614 instantiation information.

[0145] The requestor identifier may be the ID of the requestor (EECID). The WTRU 602 identifier may be a GPSI or an identity token. The security credentials may be the result of successful authorization to use the edge computing service. The WTRU 602 location may be described in 3GPP 23.558 v17.1.0 section 7.3.2. The requested SC support may be the application context relocation (ACR) type requested by the EEC 610. The requested SC plan may indicate whether the EES 612 implements SC planning for this application. The EAS 614 characteristics may correspond to the EAS 614 discovery filters described in 3GPP 23.558 v17.1.0 table 8.5.3.2-2 and further provided in step 3b of procedure 642.

[0146] The EAS instantiation information may indicate whether the EAS instantiation 650 can be performed synchronously or asynchronously with the on-demand EAS instantiation request 651. The EAS notification endpoint is an endpoint exposed by the EEC 610 to receive EAS 614 information when using asynchronous EAS instantiation. The EAS instantiation 650 timeout may be the duration allowed by the WTRU 602 to perform the instantiation. After this duration, the WTRU 602 may consider the instantiation to have failed and should cancel the instantiation.

[0147] In step 5 of 652, upon receiving the EAS instantiation request 651 from the WTRU 602, the EES 612 may send the EAS instantiation request 651 to the RMS 606. The request to the RMS 606 may include, for example, the EAS 614 identifier obtained in step 2 of this procedure and / or information received from the EAS instantiation request 651 from step 4. The request to the RMS 606 may optionally, alternatively, and / or additionally indicate the hardware resources on which the EAS 614 should be instantiated.

[0148] In the example shown in step 6, EAS instantiation 650 may be performed synchronously from on-demand EAS instantiation request 651. EES 614 may maintain the on-demand EAS instantiation response in step 6c of 655 until the newly requested EAS 614 is instantiated in EDN 604 in step 6a of 653 and registered with EES 612 in step 6b of 654. In this example model, details about the newly created EAS 614 may be included in on-demand EAS instantiation response 655 in step 6c.

[0149] The data included in the EAS instantiation response 655 may be similar to the data in the EAS discovery response described in step 3 of 643. The EAS instantiation response 655 includes a result code for the EAS instantiation 650. If successful, the result code may describe the newly instantiated EAS 614 as an EAS being executed (e.g., a registered EAS).

[0150] In an example such as that shown in step 7, the EAS instantiation 650 may be performed asynchronously from the on-demand EAS instantiation request 651, for example due to long instantiation times for a particular application. In step 7a at 656, the EES 612 may immediately return a response to the WTRU 602 indicating success or failure of the request. The EAS 614 may be created in the EDN 604 in step 7b at 657. The EAS 614 may be registered with the EES 612 in step 7c at 658. The EES 612 may issue a notification to the WTRU 602 in step 7d at 659 indicating details of the newly created EAS 612 in the notification body. The WTRU 602 may need to subscribe to the EES 612 to receive EAS 614 notifications as a prerequisite for using asynchronous mode.

[0151] The information included in the EAS instantiation response 656 provides the status that the request of step 4 of 651 was received. The information included in the EAS instantiation response 656 may further indicate whether the request can be processed at this time. A failure may indicate that the request is not accepted, and a reason may be provided. The request may be resubmitted.

[0152] The information included in the EAS instantiation notification 659 may be similar to the data in the EAS instantiation response 655 described in step 6. The EAS instantiation notification 659 may include a result code of the EAS instantiation 650. If successful, the result code may describe the newly instantiated EAS 614 as the EAS 614 to be executed.

[0153] In step 8 of 662, depending on the method used to request EAS usage 660, the EAS information may be relayed back to the requesting WTRU 602. For example, the AC 608 running on the WTRU 602 may receive the EAS IP address in a DNS response. Alternatively and / or additionally, the AC 608 may receive the EAS IP address in an API response, for example, issued by the EEC 610. Alternatively or additionally, the AC 608 may receive the EAS IP address from a function call return value. Alternatively and / or additionally, the AC 608 may receive the EAS IP address in an OS call response.

[0154] In step 9 of 664, the WTRU 602 may use the received IP address to access the on-demand EAS 614. The AC 608 running on the WTRU 602 may obtain this access.

[0155] 7 presents an example selection procedure 700 that may be performed on a WTRU, for example, by an EEC. The example selection procedure 700 illustrates how an EAS discovery response may be evaluated when combining both an implemented EAS (e.g., a registered EAS) and an on-demand EAS (e.g., a list of on-demand EASs). The example selection procedure 700 illustrates how an on-demand EAS may be selected for WTRU-based edge autoscaling. The example selection procedure 700 illustrates a fallback path if EAS selection fails.

[0156] 7 illustrates an example procedure for WTRU on-demand EAS selection. For example, FIG. 7 may present an example method for selecting a WTRU that may be performed by an EEC.

[0157] In step 1 of 702, the WTRU may send an EAS discovery request and receive an EAS discovery response. Alternatively or additionally, if the WTRU has subscribed to EAS discovery, the WTRU may receive an EAS discovery notification. Upon receiving the EAS discovery information, the WTRU may update its internal EAS cache. These actions may be performed, for example, by the EEC on the WTRU. These actions may be triggered as described in step 3 of FIG. 6 (e.g., specifically in step 3b of 642 and step 3c of 643, and / or for periodic updates). If the AC running on the WTRU requires the use of EAS, the WTRU may proceed to step 2 of 704.

[0158] In step 2 of 704, the WTRU may first verify whether the EAS to be implemented (e.g., the registered EAS) meets the AC requirements. If an EAS to be implemented is found and meets the requirements, the WTRU may select the EAS and proceed to step 6 of 712. If the WTRU does not find an EAS to be implemented (e.g., the registered EAS), the WTRU may proceed to step 3 of 706. These actions may be performed, for example, by an EEC running on the WTRU.

[0159] In step 3 of 706, the WTRU may elect to instantiate an on-demand EAS because no EAS was found to be implemented and / or did not meet the requirements. If an on-demand EAS is found and meets the requirements, the WTRU may select an EAS and attempt to instantiate the EAS in step 4 of 708. If no EAS meets the requirements, the WTRU may attempt re-evaluation in step 5 of 710. These actions may be performed, for example, by an EEC running on the WTRU.

[0160] In step 4 of 708, the WTRU may attempt to instantiate the selected EAS by forming an EAS instantiation request, as described in step 4 of 651 of Figure 6. Contextual WTRU information, such as application usage, platform state, and / or connectivity conditions, may affect the request content. Further details regarding WTRU conditions are described in Figure 10.

[0161] The WTRU may send an on-demand EAS instantiation request and receive a response. If the response is successful, the WTRU may select the offered EAS and notify the AC in step 6 of 712. If the instantiation fails, the WTRU may attempt re-evaluation in step 5 of 710. The EEC running on the WTRU may perform these actions.

[0162] In step 5 of 710, the WTRU in this state may be in a dormant state. The WTRU may periodically (e.g., at a certain period) decide to re-evaluate its current condition. Alternatively or additionally, the WTRU may receive a wake event, for example, from an AC running on the WTRU to request an EAS, from a cache validity expiration timer, and / or from a network event such as an ECS notification and / or an EES notification.

[0163] The WTRU may decide to resolve the request by using its EAS discovery cache, if appropriate, and the WTRU may proceed to perform a re-evaluation using the cache in step 2 of 704. Alternatively or additionally, if the WTRU cache is invalid or the WTRU determines that it needs to refresh the cache, the WTRU may proceed to step 1 of 702 to query the network and perform EAS discovery again. An EEC running on the WTRU may perform these actions.

[0164] In step 6 of 712, the WTRU may select an EAS and begin using the selected EAS, as described in steps 8 and 9 of 662 and 664, respectively, of Figure 6. The selection may be performed by the EEC and the use may be performed by the AC, both of which may be performed on the WTRU.

[0165] The 3GPP architecture for enabling edge computing does not support EAS termination from the WTRU. Rather, a WTRU method for on-demand EAS downscaling is required. Embodiments of the WTRU method for on-demand EAS downscaling may occur when the WTRU does not need to use on-demand EAS. This procedure may include termination of on-demand EAS that may have been previously instantiated by the WTRU. In addition to the WTRU being able to use one or more on-demand EASs, the prerequisites and / or configurations described in FIG. 6 may apply.

[0166] 8 illustrates an example procedure 800 for on-demand EAS termination 810 of a WTRU 802. In step 1 of 812, the WTRU 802 may periodically (time-based) perform a runtime validation of the EASs 814 used by the WTRU 802. The WTRU 802 may decide to terminate some EASs 814 to minimize the edge consumption footprint of the WTRU 802. Alternatively or additionally, the WTRU 802 may be notified that the EASs 814 are no longer needed and proceed with termination. The EEC 810 may perform the EAS 814 termination.

[0167] The WTRU 802 may elect to terminate an EAS 814 that the WTRU 802 instantiated on demand. Alternatively and / or additionally, the WTRU 802 may elect to terminate an executing EAS 814 that the WTRU 802 discovered. The WTRU 802 may issue a termination request at any time for any EAS 814 that the WTRU 802 previously discovered or instantiated.

[0168] The detection and notification of an unused EAS 814 may be performed via different techniques. For example, the WTRU 802 may detect that the AC 808 has stopped working via the WTRU's 802 OS, and the WTRU 802 may then terminate its associated EAS 814. Alternatively or additionally, the AC 808 may notify the EEC 810 via an API call that the EAS 814 is not needed. Alternatively or additionally, the WTRU 802 may perform traffic detection to detect that the EAS 814 has not been used for a period of time. Other ways of achieving a similar result are possible.

[0169] The network may perform EAS termination at 820. In step 2 at 822, the WTRU 802 may issue an EAS termination request 822 toward the EES 812 associated with the EAS 814 indicating the EAS identifier for which termination is requested. The EEC 810 may make the request.

[0170] In step 3 of 830, upon receiving the EAS termination request from the WTRU 802, the EES 812 may send an EAS termination request 822 to the RMS 806. The request to the RMS 806 may include the EAS identifier received from the EAS termination request 822 from step 2 of this procedure.

[0171] The EAS termination request 822 may include one or more values ​​indicating whether immediate or delayed termination is requested. In the case of delayed termination, the termination may be sent after a timer expires.

[0172] The EAS termination request 822 may indicate whether the termination should be graceful or forced. A graceful termination may require the EES 812 to verify that no other active users are currently using the EAS 814. A forced termination may require the EES 812 to perform the termination regardless of EAS 814 usage. The WTRU 802 may require permission to terminate the EAS 814. For example, the WTRU 802 may not be authorized to force the termination of the EAS 814.

[0173] In a graceful termination example, the EES812 may verify with the EAS814 whether the EAS814 can be terminated and / or still has active users. The EES812 may learn of usage by making API calls to the EAS814. Alternatively or additionally, the EES812 may learn of usage by keeping track of EAS814 usage by WTRU802 instances. In an example where usage prevents graceful termination, the EES812 may choose an action that enables graceful termination. For example, the EES812 may trigger an ACR for remaining users and graceful termination of the EAS814 once the user context of the EAS814 is relocated. If graceful termination cannot be performed, the EES812 may choose to retry the EAS814 termination later or may choose not to perform the EAS814 termination at all.

[0174] In an example of a forced termination, the EES 812 may not validate the use of the EAS 814 and may immediately terminate the EAS 814. Alternatively or additionally, the EES 812 may follow graceful termination logic, except that the EAS 814 is eventually terminated.

[0175] In step 4, for example, EAS termination 820 may be performed synchronously from on-demand EAS termination request 822. Accordingly, EES 812 may maintain on-demand EAS termination response 843 in step 4c, which EES 812 may maintain until EAS termination 820 is completed in step 4a and deregistered from EES 812 in step 4b, as seen at 841 and 842, respectively.

[0176] The data included in the EAS termination response 843 may be status information regarding the termination request 822. For example, the response 843 may indicate that the EAS 814 has terminated, that the termination was not allowed, that the termination was delayed, and / or that the termination was denied. The WTRU 802 may use the termination response to update its internal EAS 814 cache. The EEC 812 running on the WTRU 802 may use the termination response to update its internal EAS 814 cache.

[0177] In step 5, in the example, the EAS termination 820 may be performed asynchronously from the on-demand EAS termination request 822, for example, due to a long termination time of a particular application. Thus, the EES 812 may immediately return a response to the WTRU 802, as in step 5a of 851. The response may indicate success or failure of the request. For example, the request may indicate that the termination 820 is not authorized.

[0178] If the termination is successful, the EAS 814 is terminated in step 5b at 853 and deregistered from the EES in step 5c. Indicators of EAS termination and deregistration are found at 852 and 853, respectively. The EES may issue a notification to the EEC 810 in step 5d at 854 indicating the status of the EAS termination 820. In the instance of an unsuccessful termination, the notification may indicate that the termination was delayed and / or denied.

[0179] The WTRU 802 may subscribe to EAS notification as a prerequisite for using asynchronous mode. The data included in the EAS termination notification may be status information regarding the termination request.

[0180] Figure 9 illustrates an EES on-demand EAS instantiation of an example procedure 900. As depicted in Figure 9, a WTRU may have discovered and used an S-EAS 908 located in an S-EDN 902. All S-EESs 910 and T-EESs 912 may have permission to perform the described procedure.

[0181] An example of an EES method for on-demand EAS upscaling over another EES may include the 3GPP edge enablement layer, which defines an ACR procedure that may require a source EES (S-EES) 910 to request instantiation of EAS resources on a target EES (T-EES) 912.

[0182] These procedures relate to service continuity as defined in 3GPP 23.558 v17.1.0 Section 8.8. ACR may require the instantiation of a target EAS (T-EAS) 914 located at a target location according to the movement of the WTRU. Service continuity planning (SCP) may require the instantiation of several possible T-EASs located at one or more target locations according to the predicted future movement of the WTRU.

[0183] Some ACR procedures may rely on the EEC running on the WTRU to discover and instantiate the T-EAS 914, as reflected in 3GPP 23.558 v17.1.0 sections 8.8.2.2, 8.8.2.3, and 8.8.2.6. These procedures can benefit from the methods introduced earlier in Figures 5-8.

[0184] Some ACR procedures may require the EES (source or target) to perform T-EAS914 discovery, as reflected in 3GPP 23.558 v17.1.0 sections 8.8.2.4 and 8.8.2.5.

[0185] In the example, conceptually for WTRU on-demand EAS instantiation, but EAS upscaling requested by another EES, may occur between two EDNs: a source EDN (S-EDN) 902 and a target EDN (T-EDN) 904. The upscaling procedure has some preconditions, conditions, configurations, or pre-configurations; for example, the WTRU may have a valid subscription that enables communication and use of edge services present in the mobile network. The WTRU may be attached to the mobile network. The WTRU may have established a PDU session to the S-EDN 902. An exemplary PDU session establishment procedure is outlined in 3GPP 23.502 v17.2.1 section 4.3.2.2.1. EDN (also known as DNN) selection is typically provided by the PCF using URSP rules. The exemplary PDU session may also be provisioned via other methods (e.g., fixed, user profile, EEC, etc.). The contents of 3GPP 23.502 v17.2.1 are incorporated herein by reference.

[0186] In step 1 of 921, the EDN initialization procedure 920 may be similar to the procedure described above. Both EDNs, e.g., S-EDN 902 and T-EDN 904, may be provisioned with edge-enablement layer applications. The RMS 906 may provide a list of on-demand EASs to each EES, e.g., S-EES 910 and T-EES 912. The RMS 606 may instantiate applications required for edge data network operation.

[0187] In step 2, the EAS or EES may decide to perform ACR for a given WTRU. The S-EES 910 may attempt EAS discovery 930 of the T-EAS 914 according to 3GPP 23.558 v17.1.0 section 8.8.3.2.

[0188] In step 2a, the S-EAS 908 may notify the S-EES 910 of the ACR decision 932. Alternatively and / or additionally, the S-EES 910 may determine that an ACR is required.

[0189] In step 2b, the S-EES 910 may issue an EAS discovery request 934 to the T-EES 912 indicating the EAS requirements initially provided by the WTRU. Upon receiving the request, the T-EES 912 may perform a search for an EAS that can satisfy the requirements. Both implemented EASs (e.g., registered EASs) and on-demand EASs (e.g., a list of on-demand EASs) may be considered in the EAS search based on the request parameters. The information included in the EAS discovery request 934 may be the same as that previously described in FIG. 6.

[0190] In step 2c, the T-EES 912 may return a response 936 to the S-EES 910 that is a list of EASs, which may include EASs to be performed (e.g., registered EASs) and on-demand EASs (e.g., a list of on-demand EASs). The information included in the EAS discovery response 936 may be the same as that previously described in FIG. 6.

[0191] In step 3, upon receiving the EAS discovery response 936, the S-EES 910 may perform EAS selection. As illustrated in Figure 9, the S-EES 910 may select an on-demand EAS from the received list. The S-EES 910 may send an on-demand EAS instantiation request 941 to the T-EES 912 indicating the selected EAS.

[0192] In the example, EAS instantiation 940 begins with an on-demand EAS instantiation request 941, which may be performed by calling an API of T-EES 912. The information provided by EAS instantiation request 941 may be the same as that described in FIG.

[0193] In step 4 of 942, upon receiving the EAS instantiation request 941 from the S-EES 910, the T-EES 912 may send the EAS instantiation request 942 to the RMS 906. The request to the RMS 906 may include the EAS identifier obtained in step 1 of 921, the information received from the EAS instantiation request 941 from step 3, and / or may optionally indicate the hardware resource on which the EAS should be instantiated.

[0194] In step 5, EAS instantiation 940 may be performed synchronously when used for the ACR procedure. Thus, the T-EES 912 may maintain an on-demand EAS instantiation response 945 in step 5c until a newly requested T-EAS 914 is created in step 5a at 943 and the T-EAS 914 is registered with the T-EES 912 in step 5b at 944. Details about the newly created T-EAS 914 may be included in the on-demand EAS instantiation response 945 in step 5c at 945. The data included in the EAS instantiation response 945 may be the same as that described in FIG. 6.

[0195] An example ECS method for supporting on-demand EAS provisioning is described herein. For example, during a service provisioning procedure defined in 3GPP 23.558 v17.1.0 Section 8.3.3, the EEC of the WTRU may attempt to discover, via the ECS, a list of EESs suitable for providing the service required by the AC of the WTRU. Thus, the ECS service provisioning response may include a list of EESs, which includes a list of registered EAS identifiers corresponding to the EASs to be performed.

[0196] To support on-demand EAS instantiation, the ECS service provisioning request may indicate the WTRU's EEC if the ECS should consider executed EAS, on-demand EAS, or both categories when establishing the EAS list. The ECS service provisioning response may include a list of available on-demand EAS identifiers provided by the EES. The on-demand EAS identifiers may be mixed with executed EAS identifiers, in which case the response format may remain the same and the list of EAS identifiers may include both executed EAS identifiers and on-demand EAS identifiers. Alternatively or additionally, the response format may include an indicator that allows the WTRU to distinguish between executed and on-demand EAS. For example, the list of on-demand EAS identifiers may be a separate list that allows the WTRU to distinguish between executed and on-demand EAS available in the EES.

[0197] The list of on-demand EASs can be obtained by the ECS during EES registration or EES registration update, as defined in 3GPP 23.558 v17.1.0, Section 8.4.4. More specifically, when registering with the ECS, the EES issues a registration request including an EES profile according to 3GPP 23.558 v17.1.0, Section 8.4.4.3.2. The EES profile can include a list of EASIDs, which can include both implemented EASs and on-demand EASs. Alternatively or additionally, the identifiers of implemented EASs and on-demand EASs can be distinguished, for example, using separate lists. When the EES profile changes, the EES can issue an EES registration update according to 3GPP 23.558 v17.1.0, Section 8.4.4.3.4, which can include requests for the identifiers of implemented EASs and on-demand EASs, which can also be distinguished.

[0198] During the ACR procedure, the S-EES may perform T-EES discovery with the ECS. The ECS may then return to the S-EES a list of EES profiles, which may include identifiers of on-demand EASs, as described above for the WTRU.

[0199] Examples of WTRU-based edge autoscaling architectures are described herein. For example, Figure 10 is a diagram illustrating an example WTRU-based edge autoscaling architecture 1000. This architecture 1000 may comprise various components described below, such as an edge enabler client (EEC) 1010 residing on a WTRU 1002.

[0200] The EEC 1010 may be an edge enabler function of the WTRU 1002 that provides access to edge computing network 1015 resources. The functionality of the EEC 1010 may include retrieving edge computing data from the network 1015, maintaining the EEC 1010 configuration according to the retrieved edge computing (EC) data, providing discovery capabilities for EC resources, and / or providing access to EC resources.

[0201] Alternatively and / or additionally, as described above, the EEC 1010 may act as a gateway towards the EDN to provide on-demand upscaling and downscaling functionality. Alternatively and / or additionally, the EEC 1010 may act as an edge computing data source for deriving the WTRU 1002 edge computing context. For example, information such as available EDN, available EES, available EAS, EAS usage by the WTRU 1002, and / or EAS KPIs retrieved from the network may be used to establish the WTRU 1002 edge computing context. The EEC 1010 may provide the EC context on the WTRU 1002 using different methods. For example, the information may be exposed via the EEC's API, stored in a file, provided via a shared database, retrieved via the WTRU OS, and / or exposed via a library package.

[0202] The Application Client (AC) 1020 may be an application that requires the use of an EC. The AC 1020 may interface with the EEC 1010 via the EDGE-5 reference point to discover the endpoint addresses of EASs available in the network. The AC 1020 may also act as a context data source for deriving the WTRU 1002 context. Information such as application configuration, application logs, and / or application notifications are examples of AC 1020 information that may be used to establish the WTRU 1002 application context.

[0203] The context data sources 1030 may be different sources of data used to establish the WTRU 1002 context. In an example, such data may be used as a source for understanding a user's behavioral activity patterns in different contexts. Alternatively and / or in addition to the illustrated context data sources 1030, EC data may be used to establish the edge context and behavior of the WTRU 1002. The data sources may be obtained from a variety of sources, such as, for example, sensors, logs, hardware, OS, etc.

[0204] The WTRU context awareness function 1040 may use the context data source 1030 to derive context-aware rules used to adapt the behavior of the WTRU 1002 in different contexts. As an example, the WTRU 1002 may implement context-aware user notifications. These notifications may be muted when the user is sleeping, attending a meeting, at work, and / or driving, etc. The use of artificial intelligence (AI) and machine learning (ML) techniques may be common in this type of context awareness function. In WTRU-based edge autoscaling, the context awareness function may generate the context data and rules used to make edge autoscaling decisions. The WTRU context awareness function 1040 may be implemented as a standalone application, may be part of a context awareness framework, may be part of the OS, may be provided by a hardware component on the WTRU 1002, may be implemented as a function provided by the EEC 1010 and / or the WTRU-based edge autoscaling function 1050, etc.

[0205] The WTRU-based edge autoscaling function 1050 may use the context information generated by the WTRU context awareness function 1040 to make decisions regarding upscaling or downscaling of edge computing resources. Alternatively and / or additionally, the WTRU-based edge autoscaling function 1050 may use the raw context data directly. The WTRU-based edge autoscaling function 1050 may be implemented as a standalone application, may be part of an edge autoscaling framework, may be part of the OS, may be provided by a hardware component on the WTRU 1002, and / or may be implemented as a function provided by the EEC 1010, etc.

[0206] 11 and 12 are exemplary variations of the WTRU-based autoscaling architecture 1000 illustrated in FIG.

[0207] FIG. 11 illustrates an example WTRU-based edge autoscaling architecture 1100 within an EEC 1110. FIG. 11 represents a compact variation of the WTRU 1102 element in which autoscaling and context awareness may both be implemented as part of the EEC 1110. Raw context data may be obtained by the EEC 1110, which may directly derive context rules and derive autoscaling decisions internally. Specifically, a WTRU-based edge autoscaling context awareness function 1140 located within the EEC 1110 may provide the context rules and autoscaling decisions to the EEC 1110.

[0208] FIG. 12 illustrates an example WTRU-based edge autoscaling architecture 1200 using network AI and / or ML. FIG. 12 is a variation in which context awareness can be delegated to the network side. Raw context data collected at the WTRU 1202 can be sent to the network-based AI / ML federated learning function 1250, for example, via a federated learning function 1260 residing on the WTRU 1202. The federated learning function 1260 can derive advanced models by combining internal WTRU 1202 data with external data sources obtained, for example, from other WTRUs, the network, the radio access network, and / or an edge computation framework. This model can then be used to derive rules used by the WTRU-based edge autoscaling function 1240.

[0209] In an example, an autonomous drone may be used for infrastructure inspection operations and may require an edge service to perform real-time video analytics. The edge computation requirements of a video analytics service may be high (e.g., high compute, GPU, significant RAM, and / or high bandwidth). The edge computation requirements may have a high usage cost. Due to these constraints, a user may only provision the video analytics service at the time of the inspection. Example WTRU context awareness information and / or rules may indicate that a drone (e.g., WTRU 1202) is in flight, has arrived at the inspection, and its camera is turned on and / or is ready to transmit a video feed toward the edge service. In response, the WTRU-based edge auto-scaling function 1240 may request instantiation of an edge service when the context requirements are met by requesting the EEC 1210 to perform EAS instantiation, as described in FIG. 6.

[0210] In an example, several drones (e.g., multiple WTRUs 1202) may join to perform inspections in a coordinated manner. The joined drones (e.g., multiple WTRUs 1202) may initially share a single video analytics edge service. In such a case, the joined drones (e.g., multiple WTRUs 1202) may perform routine EAS discovery. The joined drones may discover the existing video analytics service. As more drones join, the video analytics service may become saturated. As more drones join, the video analytics service may not meet performance requirements, and discovery may not be returned to the EAS to be performed. The WTRU-based edge autoscaling function 1240 on the newly joined drone may trigger service upscaling as described in FIG. 6 to increase edge video analytics capabilities.

[0211] When the drone completes its inspection and returns to its home base, the drone may stop using the video analytics service. Each drone may send a graceful EAS termination request, as described in FIG. 8. The EES may terminate the EAS if the drone is no longer using the EAS, or may alternatively and / or additionally choose to maintain the EAS.

[0212] Once the inspection is complete, the drone may leave the area and return to its home base. The WTRU-based edge autoscaling function 1240 may recognize that the inspection has ended (e.g., camera off). Upon learning that the inspection has ended, the WTRU-based edge autoscaling function 1240 for that drone may send a graceful EAS termination request, as described in FIG. 8. The EES may choose to downscale the video analytics service if the drone is no longer using it, and alternatively or additionally, maintain the service or perform ACR for another instance of the service, after which the service may terminate. When the last drone completes the inspection, the WTRU-based edge autoscaling function 1240 may send a graceful EAS termination request, which causes termination of the edge video analytics service.

[0213] In an example, an autonomous vehicle (e.g., WTRU 1202) may use edge services to perform calculations that assist in collision avoidance. As the vehicle moves, sensor data may be sent to the edge and combined with other vehicle information. In this example, each vehicle has its own edge service, and data may be shared between the edge services. Assuming the vehicle is parked, collision avoidance services may no longer be needed. The WTRU context awareness function may provide information that the user is driving or parked, and the WTRU-based edge autoscaling function 1240 can downscale the driving assistance edge services until the driver begins to move again.

[0214] In an example, a game on the WTRU 1202 may require a gaming edge service instance for each individual player. When played collaboratively, a second edge service that serves as a session rendezvous point may be required for each collaborative session. When a first player (e.g., Player 1) begins play, the WTRU-based edge autoscaling function 1240 may upscale the gaming edge service instance. When a second player (e.g., Player 2) arrives, the WTRU-based edge autoscaling function 1240 may upscale the gaming edge service instance and instantiate a rendezvous edge service because it is not yet available. When a third player (e.g., Player 3) joins, the WTRU-based edge autoscaling function 1240 may choose to simply instantiate a gaming edge service because a rendezvous point service already exists.

[0215] While features and elements are described above in particular combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with the other features and elements. Additionally, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via 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 versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: receiving a message from a network device, the message including a list of one or more edge application server identifiers, each edge application server identifier associated with an uninstantiated application; selecting one or more edge application server identifiers from the list of edge application server identifiers associated with uninstantiated applications; sending a message to an edge data network, the message indicating a request to instantiate one or more uninstantiated applications on the edge data network; receiving a response from the edge data network, the response indicating that the uninstantiated application has been instantiated on the selected edge data network and including information for accessing the newly instantiated application instance on the edge data network.

2. 10. The method of claim 1, further comprising: sending an edge application server discovery request to the edge data network, the edge application server discovery request indicating one or more edge application server requirements, and the message comprising an edge application server discovery response received in response to the edge application server discovery request.

3. The method of claim 1 or 2, wherein the message includes a list of one or more edge application server identifiers associated with already-instantiated versions of the instantiated application.

4. 4. The method of claim 1, wherein the information for accessing the newly instantiated application indicates whether the newly instantiated application was instantiated synchronously or asynchronously.

5. 5. The method of claim 4, wherein the information for accessing the newly instantiated application indicates that the newly instantiated application is instantiated synchronously, and the edge application server instantiation response includes edge application server information that enables the WTRU to access the newly instantiated application.

6. The method of any one of claims 1 to 5, further comprising receiving the selected edge application server Internet Protocol (IP) address, URL, or FQDN in the response.

7. The method of any one of claims 1 to 6, wherein each uninstantiated application corresponds to an uninstantiated edge application server included in the edge data network.

8. 1. A wireless transmit / receive unit (WTRU) comprising a processor and a memory, the processor and the memory comprising: receiving a message from a network device, the message including a list of one or more edge application servers associated with an uninstantiated application; selecting an edge application server from the list of one or more edge application servers associated with the uninstantiated application; sending a request to an edge data network, the request indicating a request to instantiate the uninstantiated application on the selected edge application server; a wireless transmit / receive unit (WTRU) configured to receive a response from the edge data network, the response indicating that the uninstantiated application has been instantiated at the selected edge application server and indicating information for accessing the currently instantiated application at the edge application server.

9. 10. The WTRU of claim 8, wherein the processor and memory are configured to send an edge application server discovery request to the edge data network, the edge application server discovery request indicating one or more edge application server requirements, and the message includes an edge application server discovery response received in response to the edge application server discovery request.

10. The WTRU of claim 8 or 9, wherein the request is sent to an edge enabler server of the edge data network.

11. The WTRU of any one of claims 8 to 10, wherein the message comprises a service provisioning message.

12. 12. The WTRU of claim 8, wherein the information for accessing the currently instantiated application indicates that the currently instantiated application is instantiated synchronously, and the edge application server instantiation response includes edge application server information associated with the selected edge application server.

13. The WTRU of any one of claims 8 to 12, wherein an Internet Protocol (IP) address of the selected edge application server is included in the response.

14. 1. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: transmitting an application server discovery request to a data network, the application server discovery request indicating one or more application server requirements; receiving an application server discovery request message from a network device, the message including a list of one or more application servers associated with an application that satisfies the one or more application server requirements, the application server discovery request indicating that the application is not currently instantiated on the one or more application servers; selecting an application server from the list of one or more application servers associated with the application; sending a request to the data network, the request indicating a request to instantiate the application on the selected application server; receiving a response from the data network, the response indicating that the application has been instantiated on the selected application server and indicating information for accessing the application on the application server.

15. The method of claim 14 , wherein the message includes a list of one or more application servers associated with the application if the application is currently instantiated.

16. 1. A wireless transmit / receive unit (WTRU) comprising a processor and a memory, the processor and memory comprising: sending an edge application server discovery request to an edge data network, the edge application server discovery request indicating one or more edge application server requirements; receiving an edge application server discovery response message from an edge data network, the message including a list of one or more edge application servers that satisfy the one or more edge application server requirements, the edge application server discovery request indicating that the edge application server is not currently instantiated; selecting an edge application server from said list of one or more edge application servers; sending a request to the edge data network, the request indicating a request to instantiate the selected edge application server; a wireless transmit / receive unit (WTRU) configured to receive a response from the edge data network, the response indicating that the selected edge application server has been instantiated and indicating information for accessing the selected edge application server.

17. 1. A wireless transmit / receive unit (WTRU) comprising a processor and a memory, the processor and the memory comprising: receiving an edge service provisioning procedure message from the network device, the edge service provisioning procedure message including a list of one or more edge application servers that are not currently instantiated; selecting an edge application server from said list of one or more edge application servers that are not currently instantiated; sending a request to an edge data network, the request indicating a request to instantiate the selected edge application server; a wireless transmit / receive unit (WTRU) configured to receive a response from the edge data network, the response indicating that the selected edge application server has been instantiated and indicating information for accessing the selected edge application server.

18. The WTRU of claim 17 , wherein the request is sent to an edge enabler server of the edge data network, and the response is received from an edge enabler server of the edge data network.

19. The WTRU of claim 17 or 18, wherein the message includes a list of one or more already instantiated edge application servers.

20. 20. The WTRU of claim 16, wherein the information for accessing the currently instantiated edge application server indicates whether the current edge application server was instantiated synchronously or asynchronously.

21. 20. The WTRU of claim 19, wherein the information for accessing the currently instantiated edge application server indicates that the currently instantiated edge application server was instantiated synchronously and the service provisioning procedure message.

Images