Wireless transmit / receive unit (WTRU) and method implemented thereby

Abstract

A wireless transmit / receive unit (WTRU) and a method implemented thereby are described herein. The method includes transmitting an edge application server (EAS) discovery request to an edge data network (EDN), wherein the EAS discovery request includes one or more EAS requirements; receiving an EAS discovery response from the EDN, the EAS discovery response comprising a list of one or more EASs associated with an uninstantiated application, the uninstantiated application satisfying the one or more EAS requirements; selecting an EAS from the list of the one or more EASs; transmitting an EAS instantiation request to the EDN, wherein the EAS instantiation request indicates the selected EAS; and receiving an EAS instantiation response from the EDN, the EAS instantiation response indicating that the selected EAS has been instantiated at the EDN, where the EAS instantiation response includes instantiation information associated with the selected EAS.

Description

[0001] This application is a divisional application of the invention patent application with application number 202280080720.6 filed on November 7, 2022, and invention name "Method and device for implementing edge computing scaling based on wireless transmission / receiving unit (WTRU)".

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This patent application claims the benefit of U.S. Provisional Patent Application No. 63 / 277,391, filed on November 9, 2021, the entire contents of which are incorporated herein by reference. Background Art

[0004] Self-organizing networks (SON) belong to the concept defined as automation technology that aims to make the planning, configuration, management, optimization and repair of mobile radio access networks simpler and faster. The SON concept also exists in cloud computing; the key aspect of cloud computing self-organization is called autoscaling. Autoscaling is a method of dynamically adjusting the number of servers in a group using the computing load of the group, with the goal of allowing cloud applications to scale up as usage increases. Cloud scaling techniques typically rely on key performance indicators (KPIs) measured at the servers and KPIs provided by load balancers that direct incoming traffic to these servers. Autoscaling is coarse-grained and is usually applied passively based on demand. This technology is well suited to computing data center environments, where resources are abundant and co-located. As edge computing becomes ubiquitous and computing moves closer to mobile terminals, the scaling of edge network resources needs to continue to evolve. However, cloud computing autoscaling is not suitable for handling fine-grained, limited distributed computing at the edge. Therefore, methods and devices that can automatically scale mobile edge computing are needed. Summary of the invention

[0005] Methods and apparatus for edge computing auto-scaling based on a wireless transmit / receive unit (WTRU) are described herein. For example, a WTRU may transmit an edge application server (EAS) discovery request to an edge data network (EDN), the request including one or more EAS requirements. The WTRU may receive an EAS discovery response from the EDN, the response including a list of executed EAS and on-demand EAS (e.g., non-executed EAS). Based on selecting an on-demand EAS from the list of executed EAS and on-demand EAS, the WTRU may transmit an on-demand EAS instantiation request to the EDN, the request indicating the selected on-demand EAS. The WTRU may receive an on-demand EAS instantiation response from the EDN, the response indicating the EAS instantiation synchronously or asynchronously. In the case where the EAS instantiation is indicated synchronously, the on-demand EAS instantiation response may include EAS information associated with the selected on-demand EAS. In the case where 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, the notification including 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.

[0006] The method implemented 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 application. The method may include transmitting a message to an EDN. The message may provide an indication of a request to instantiate one or more uninstantiated applications at the EDN. The method may include receiving a response from the EDN. The response may include an indication that the uninstantiated application has been instantiated at the selected EDN and information for accessing the newly instantiated application instance at the EDN.

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

[0008] The method may include a list of one or more EAS identifiers associated with the instantiated version of the instantiated application.

[0009] The method may provide for sending information for accessing the newly instantiated application. The information may indicate whether the newly instantiated application has been instantiated synchronously or asynchronously.

[0010] The method may provide sending information for accessing the newly instantiated application, the information indicating that the newly instantiated application has been synchronously instantiated. The method may provide sending information that the EAS instantiation response includes EAS information, the EAS information allowing the WTRU to access the newly instantiated application.

[0011] The method may include receiving an Internet Protocol (IP) address, URL, or FQDN of the selected EAS in the response.

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

[0013] The WTRU may be configured to receive a message from a network device. The message may provide a list of one or more edge application servers associated with an uninstantiated application. The WTRU may select an EAS from the list of one or more EASs associated with the uninstantiated application. The WTRU may transmit a request to an EDN. The request may request that the uninstantiated application be instantiated at the selected EAS. The WTRU may receive a response from the EDN. The response may indicate that the uninstantiated application has been instantiated at the selected EAS and / or indicate information for accessing the now instantiated application at the EAS.

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

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

[0016] The WTRU may transmit a message including a service configuration message.

[0017] For the WTRU, the information for accessing the now instantiated application indicates that the now instantiated application has been synchronously instantiated, and the edge application server instantiation response includes edge application server information associated with the selected edge application server.

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

[0019] A method implemented by a WTRU may include transmitting an application server discovery request to a data network. The application server discovery request may include an indication of one or more application server requirements. The method may also provide receiving an application server discovery request message from a network device. The message may include a list of one or more application servers associated with applications that meet the one or more application server requirements. The application server discovery request may provide an indication that the application is not currently instantiated at the one or more application servers. The method may provide selecting an application server from the list of the one or more application servers associated with the application. The method may include transmitting a request to the data network. The request may include an indication of a request to instantiate the application at the selected application server. The method may include receiving a response from the data network. The response may include an indication that the application has been instantiated at the selected application server and information for accessing the application at the application server.

[0020] The method may include a list of one or more application servers associated with the application, the application currently instantiated.

[0021] The WTRU may be configured to transmit an EAS discovery request to an 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, the message including a list of one or more EASs that meet the one or more EAS requirements. The EAS discovery request may indicate that the EAS is not currently instantiated. The WTRU may select an EAS from the list of one or more EASs. The WTRU may transmit a request to the EDN. The request may indicate 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 indicate information for accessing the selected application server.

[0022] The WTRU may be configured to receive an edge service configuration procedure message from a network device. The edge service configuration 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 transmits a request to an 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 indicate information for accessing the selected EAS.

[0023] The WTRU may send requests to and / or receive responses from an edge enabling server (EES) of the EDN.

[0024] The WTRU may provide a message including a list of one or more EASs.

[0025] The WTRU may include information for accessing an existing EAS, the information indicating whether the existing EAS has been instantiated synchronously or asynchronously.

[0026] The WTRU may include information for accessing the now instantiated EAS. The information may indicate that the now instantiated EAS and / or the service configuration procedure message have been synchronized and instantiated. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate like elements, and in which:

[0028] Figure 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

[0029] Figure 1B It is shown that according to one embodiment, Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) for use within the communication system shown;

[0030] Figure 1C It is shown that according to one embodiment, Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the illustrated communication system;

[0031] Figure 1D It is shown that according to one embodiment, Figure 1A A system diagram of another exemplary RAN and another exemplary CN used in the communication system shown;

[0032] Figure 2 is a diagram illustrating an exemplary SA6 architecture for implementing edge applications;

[0033] Figure 3 is a diagram illustrating an exemplary high-level cloud services architecture;

[0034] Figure 4 is a diagram illustrating an exemplary machine learning-based context-aware rule learning framework;

[0035] Figure 5 is a diagram illustrating an exemplary high-level overview of an on-demand edge application server (EAS) instantiation for a WTRU;

[0036] Figure 6 is a diagram illustrating an exemplary process for on-demand EAS instantiation for a WTRU;

[0037] Figure 7is a diagram illustrating an exemplary process for on-demand EAS selection for a WTRU;

[0038] Figure 8 is a diagram illustrating an exemplary procedure for on-demand EAS termination for a WTRU;

[0039] Fig. 9 is a diagram illustrating an exemplary process for on-demand EAS instantiation for an edge enablement server (EES);

[0040] Fig.10 is a diagram illustrating an exemplary WTRU-based edge auto-scaling architecture;

[0041] Fig.11 is a diagram illustrating an exemplary WTRU-based edge auto-scaling architecture in an edge enabled client (EEC); and

[0042] Fig.12 is a diagram illustrating an exemplary WTRU-based edge auto-scaling architecture using network artificial intelligence (AI) / machine learning (ML). DETAILED DESCRIPTION

[0043] Figure 1A 1 is a diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The 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 employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0044] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110 and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d 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 cellular phone, a personal digital assistant (PDA), a smart phone, 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 device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0045] The communication 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 that is 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 Node B, an evolved Node B (eNB), a Home Node B, a Home evolved Node B, a next generation Node B such as a gNode B (gNB), a New Radio (NR) Node B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0046] 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), a relay node, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrums. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Therefore, 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 for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0047] 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).

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

[0049] 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 Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro).

[0050] 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.

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

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

[0053] Figure 1AThe base station 114b in the may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In 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 another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a micro-micro cell base station or a femto cell base station. As Figure 1A As shown, the base station 114b may have a direct connection to the Internet 110. Therefore, the base station 114b may not be required to access the Internet 110 via the CN 106.

[0054] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not described in detail in the specification, the CN 106 may be configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Figure 1A Although not shown in the figure, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ 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 be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0055] The CN 106 may also act 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 that provides 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) in the TCP / IP Internet protocol suite. The networks 112 may include wired communication networks and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0056] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication 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 via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0057] Figure 1B is a system diagram illustrating an exemplary WTRU 102. Figure 1B As shown, 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 appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

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

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

[0060] Although the transmit / receive element 122 Figure 1B 102 as a single element, but 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.

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

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

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

[0064] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over 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 acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

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

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

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

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

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

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

[0071] The MME 162 may be connected to each of the evolved Node-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, 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.

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

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

[0074] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication 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 networks and / or wireless networks owned and / or operated by other service providers.

[0075] Although the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may (eg, temporarily or permanently) use a wired communication interface with a communication network.

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

[0077] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STA) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic away from the BSS. Traffic originating from outside the BSS and leading to the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be sent to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be sent by the AP, for example, wherein the source STA may send traffic to the AP, and the AP may deliver traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be sent between the source STA and the destination STA (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

[0078] When using the 802.11ac infrastructure operating mode or a similar operating mode, the AP may transmit a beacon on a fixed channel (such as a primary channel). The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (including the AP) may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0079] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0080] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channel can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and data can be transmitted by transmitting STA. At the receiver of the receiving STA, the above-mentioned operation for 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0081] 802.11af and 802.11ah support operating modes below 1GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter type control / machine type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0082] WLAN systems that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah include channels that can be designated as primary channels. The primary channel 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 set and / or limited by a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (supporting only the 1MHz operating mode) is transmitting to the AP, all available frequency bands may be considered busy even if most of the available frequency bands remain idle.

[0083] In the United States, the available frequency band for 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.

[0084] Figure 1D1 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 to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

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

[0086] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, 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., containing varying numbers of OFDM symbols and / or varying absolute time lengths over time).

[0087] 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 while also not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use 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 an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNBs 180a, 180b, 180c while also communicating / connecting with another RAN, such as the evolved Node-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more evolved Node-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the evolved Node-Bs 160a, 160b, 160c may serve 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.

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

[0089] Figure 1DThe illustrated CN 106 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although the aforementioned elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

[0093] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks 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 DNs 185a, 185b via the UPFs 184a, 184b via the N3 interfaces to the UPFs 184a, 184b and the N6 interfaces between the UPFs 184a, 184b and the local DNs 185a, 185b.

[0094] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU 102a-d, base station 114a-b, evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b and / or any other device described herein. The simulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the simulation device can be used to test other devices and / or simulate network and / or WTRU functions.

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

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

[0097] A key feature of modern mobile networks is their self-organizing capability; Self-Organizing Networks (SON) are a concept defined as automation technology that aims to make the planning, configuration, management, optimization and repair of mobile radio access networks simpler and faster. As the terminal moves in the network, the SON concept can be applied to the radio resources and the network continuously adjusts the terminal mobility to provide the best user experience.

[0098] SON concepts can also be found in cloud computing; a key aspect of cloud computing self-organization is called autoscaling. Autoscaling can be defined as dynamically adjusting the number of servers in a group using the group's computational load, with the goal of allowing cloud applications to scale up as usage increases. Cloud scaling techniques typically rely on key performance indicators (KPIs) measured at the servers and provided by the load balancers that direct incoming traffic to those servers. Autoscaling is coarse-grained and is typically applied reactively based on demand; this technique is well suited to computing data center environments, where resources are plentiful and co-located.

[0099] As edge computing becomes ubiquitous and computing moves closer to mobile terminals, methods and devices for scaling edge network resources are needed. Cloud computing autoscaling is not suitable for handling fine-grained, limited distributed computing at the edge.

[0100] Mobile edge computing may need to involve on-demand scaling of individual end-point environments, as opposed to large-scale, cloud-based autoscaling.

[0101] Likewise, SON becomes the core concept of radio network technology. Therefore, it is expected that self-organizing edge computing (SOEC) will become the mainstream in future edge technology.

[0102] Figure 2 is a system diagram illustrating an exemplary SA6 architecture for implementing edge applications. Examples of autoscaling and load balancing are described herein. As described above, cloud-based autoscaling architectures are not suitable when used in edge computing environments. Therefore, there is a need for WTRU-based edge autoscaling and architectures thereof.

[0103] The WTRU 202 may include one or more application clients (ACs) 204. The application clients 204 may be user applications. The AC 204 may communicate with one or more edge application servers (EASs) 206. The EAS 206 may be implemented as a standalone server or may be a software module implemented on a general-purpose server of an edge data network. The EAS may be implemented using any combination of hardware and software. Therefore, if implemented as software on a general-purpose server, the edge application server itself may be instantiated and / or uninstantiated as needed. Similarly, the applications running on the edge application server may be instantiated and / or uninstantiated as needed. The WTRU 202 may use one or more ACs 204 simultaneously. The information communicated between the AC 204 and the EAS 206 may be application data traffic 208. The application data traffic 218 may be sent on the 3GPP core network 218. The EAS 206 and the 3GPP core network 218 may communicate with each other via reference point edge-7.

[0104] One or more edge enabled clients (EECs) 210 may reside on the WTRU 202 with the AC 204. The EEC 210 provides edge support to the AC 204 on the WTRU 202. When one or more ACs 204 and one or more EECs 210 may reside on the WTRU 202, one AC 204 may receive support from one EEC 210. The EEC 210 may communicate with the AC 204 via Node-Edge-5.

[0105] Edge configuration server (ECS) 212 may provide support functions required by EEC 210 and / or edge enablement server (EES) 214. For example, ECS 212 may discover one or more EES 214, may provide edge configuration information to EEC 210 and / or EES 214, and / or may register EES 214. A network may include one or more ECS 212.

[0106] EEC 210 and ECS 212 may communicate with each other via Node Edge-4. ECS 212 and EES 214 may communicate with each other via Node Edge-6. EES 214 and 3GPP core network 218 may communicate with each other via Node Edge-7. ECS 212 and 3GPP core network 218 may communicate with each other via Node Edge-8.

[0107] EES214 may provide support functions required by EAS206 and EEC 210. For example, EES214 may provide configuration information of EAS206 to EEC 210, may disclose application context transfer events, may perform context transfer of EEC 210, may disclose 3G)) core network and service capabilities to EAS206, and / or may register EEC 210 and / or EES214. EES214 may have separate functions when WTRU 202 is movable and / or relocated. For example, a source EES (S-EES) may be used before WTRU 202 moves / relocates. For example, a target EES (T-EES) may be used after WTRU 202 moves / relocates. The network may include one or more EES214 for each edge data network (EDN) 216.

[0108] The EES 214 and the EEC 210 may communicate with each other via the node edge-1. The EES 214 and the EAS 206 may communicate with each other via the node edge-3. The EES 214 may communicate with another EES 214 in the EDN 216 via the node edge-9.

[0109] The EAS 206 may be used as a server residing in the EDN 216. Thus, the EAS 206 may be considered as software that provides services to the AC 204. When the WTRU 202 may be mobile and / or relocated, the EAS 206 may have separate functions. For example, the source EAS (S-EAS) may be used before the WTRU 202 is moved / relocated. For example, the target EAS (T-EAS) may be used after the WTRU 202 is moved / relocated. The 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 serve a single WTRU 202 and / or AC 204 exclusively.

[0110] Figure 3 An exemplary high-level cloud services architecture 300 is shown. Figure 3 The ability of the cloud service architecture to perform autoscaling is also depicted.

[0111] For example, autoscaling may include a method of automatically changing (eg, scaling up or down) the number of computing resources (eg, servers) allocated to a cloud data center 302. For example, a cloud data center 302 may include one or more servers 304.

[0112] Without autoscaling, cloud data centers waste resources during idle time and can become unresponsive when processing too many incoming requests 306. Autoscaling can meet the needs of optimizing resource usage and supporting elastic computing that adapts as demand grows. Autoscaling can be performed by an agent (e.g., autoscaler 308). Autoscaler 308 can collect KPIs and evaluate the KPIs when the amount of computing needs to change.

[0113] The autoscaler 308 can use different types of KPIs. In an example, scheduled autoscaling can use time periods to increase / decrease service capacity. In an example, front-end traffic autoscaling can be used to scale based on the number of incoming requests 306. One or more load balancers 310 process front-end incoming traffic 312 in front of the cloud server 304, which includes KPIs. In an example, back-end scaling can be based on load (e.g., the number of jobs in the queue) or time (how long the job has been queued). The cloud server 304 obtains back-end traffic 314 when scaling the back-end, which includes KPIs. Depending on the implementation, the autoscaler can rely on time, front-end KPIs, and back-end KPIs to perform autoscaling decisions.

[0114] The role of the load balancer 310 in the cloud system may include directing traffic originating from the WTRU 316 to available server resources 304. The load balancer 310 may direct traffic in a predetermined manner (e.g., round-robin). The load balancer 310 may direct traffic in a dynamic manner in view of server load KPIs to direct requests to less busy servers 304.

[0115] The autoscaler 308, load balancer 310, and KPI acquisition framework (e.g., front-end traffic 312 and back-end traffic 314) together may include any cloud computing architecture components found today. Examples of cloud computing architectures may include context-aware rules learned from smartphone data as described herein. The present 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.

[0116] Recent developments and improvements in the processing power of the WTRU 316 have driven the popularity and interest in context-aware technologies. Data analysis and building data-driven context-aware systems can be used to build intelligent context-aware applications on the WTRU 316. This requires high-precision advanced data analysis techniques and context-based intelligent decision strategies. Machine learning-based techniques can provide effective and efficient results for smartphone data analysis and corresponding context-aware rule learning.

[0117] Figure 4 An exemplary context-aware rule learning framework based on machine learning is shown. Specifically, Figure 4 An exemplary machine learning (ML) framework is presented 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 and artificial intelligence techniques). These techniques may then derive contextual rules that are used to influence WTRU behavior.

[0118] For example, the learning technique may involve the WTRU 402 performing a series of steps (e.g., layers) involving the WTRU acquiring data, analyzing the data, and learning rules from the data acquisition and analysis. For example, the first step (e.g., layer 1) involves the WTRU 402 engaging in context data acquisition 406. For example, the relevant data obtained via context data acquisition 404 may include smartphone logs, sensors, and / or external sources. Then, at layer 2, context discretization 410, the WTRU 402 may analyze the acquired data by using different techniques (e.g., time series modeling and / or context data clustering).

[0119] By analyzing this data, the WTRU 402 may then generate some rules during the Level 3 rule discovery 414 phase. To discover the rules, the WTRU 402 may apply contextual preferences, rule-based learning techniques, and / or rule generalization parameters.

[0120] When the WTRU 402 has applied the techniques described during rule discovery 414, the WTRU 402 may refine the learned rules at level 4, which is referred to as dynamic updating and management 418. In refining its learned rules, the WTRU may apply recent analysis and mining techniques. The WTRU 402 may also perform rule updates to synchronize the learned rules with the acquired data and modeling techniques used at context discretization 410.

[0121] 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 the applications with the support of its newly learned and defined rules.

[0122] As mentioned above, cloud autoscaling may not satisfy the characteristics required to implement a self-organizing edge computing (SOEC) architecture.

[0123] like Figure 2 As described, the 3GPP SA6 architecture defines an edge-enabled architecture that provides components for terminal discovery and use of edge application servers (EAS). The architecture couples EAS discovery with EAS instantiation, which causes the WTRU to seek to discover available EAS (e.g., to select the best available option) for instantiation computation in an undesirable manner. As described below, operating the WTRU in this manner violates the fine-grained resource management principles required for edge computing. In the example, coupling EAS discovery with EAS instantiation can result in unnecessary EAS instantiation and waste of computing resources. The WTRU needs to discover possible EAS and / or request instantiation, as well as use the EAS independently.

[0124] The current 3GPP SA6 architecture lacks the ability to terminate EAS when it is not needed. This lack of capability results in resources remaining unused, violating the fine-grained resource management principle required for edge computing. Unused EAS resources may remain unused, wasting computing resources. The WTRU needs to indicate that it has stopped using edge computing resources.

[0125] Compute overprovisioning will result in $26.6 billion in public cloud waste in 2021, up from $17.6 billion in 2020, and this trend is accelerating. This illustrates the coarse nature of cloud autoscaling approaches, which would be disastrous if used in distributed and resource-limited edge environments. As a result, cloud-based autoscaling is coarse-grained and may not meet the fine-grained autoscaling requirements of resource-limited edge environments.

[0126] For example, examples of relevant architectures include enabling SOEC in a 3GPP edge architecture, enabling WTRU-based edge computing management for a 3GPP edge architecture, and / or enabling fine-grained autoscaling in a 3GPP edge architecture.

[0127] As described above, WTRU-based edge auto-scaling may be required to implement SOEC.

[0128] In an example, the capabilities of the 3GPP edge-enabled architecture are described herein, which are required to support a WTRU-based edge auto-scaling architecture. These capabilities may include, for example, a WTRU method for on-demand EAS expansion, a WTRU method for on-demand EAS reduction, an EES method for on-demand EAS expansion, and / or an ECS method for supporting on-demand EAS configuration.

[0129] Based on the 3GPP edge enabling layer, WTRU-based auto-scaling, and WTRU methods for on-demand EAS expansion, an example of a WTRU-based edge auto-scaling architecture is also described herein.

[0130] When a terminal (eg, a network node, a network device, and / or a WTRU) attempts to discover EAS to use edge services, on-demand EAS augmentation may occur. The process may include discovering that on-demand EAS has not yet been implemented and requesting that on-demand EAS be implemented.

[0131] In an example, edge computing nodes may have sufficient computing resources to overprovision EAS at the edge. When overprovisioning occurs, more EAS may be created than needed, and the required resources may remain unused and wasted until needed. Overprovisioning is common in resource-rich cloud environments. Cloud autoscaling algorithms and / or processes may be used to achieve computing elasticity.

[0132] Typical edge computing environments have limited resources and are therefore optimized to instantiate only the required EAS. The terminal needs to be able to detect that the EAS is not instantiated and trigger its instantiation when the terminal intends to use the resource and for the duration that the terminal needs to use the resource.

[0133] Figure 5 An exemplary high-level overview of an on-demand EAS instantiation 500 for a WTRU is shown. Figure 5 As shown, network components including an 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 include an orchestrator and / or an EAS registry 516 (e.g., a 3GPP management system).

[0134] like Figure 5 As shown, WTRU 502 on-demand edge EAS 514 instantiation may include four phases: EDN initialization 530 , EAS discovery 540 , EAS instantiation 550 , and EAS usage 560 .

[0135] 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 the edge enablement layer. The RMS 506 may indicate to the newly created EES 512 which EAS 514 is available for the WTRU 502 to instantiate on demand.

[0136] When the AC 508 needs to use EAS 514, EAS discovery 540 may occur while the EDN 504 is running. The AC 508 may trigger the EAS 514 discovery carried by the EEC 510. The WTRU 502 may discover the EAS 514 instances available in the EDN 504. The EEC 510 present on the WTRU 502 may discover and perform EAS 514 on demand.

[0137] When the WTRU 502 decides to perform on-demand EAS instantiation 550, the EAS instantiation 550 may occur while the EDN 504 is running. This may be performed by the EEC 510 present on the WTRU 502. The WTRU 502 may perform signaling of the edge enabling layer to trigger the on-demand EAS instantiation 550. This may be performed by the EEC 510 present on the WTRU 502. The EES 512 may perform signaling of the RMS 506 to perform the on-demand EAS instantiation 550.

[0138] The EAS usage 560 may occur while the EDN 504 is running, 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 use may be performed by the AC 508 present on the WTRU 502.

[0139] Figure 6 An example process 600 for on-demand EAS instantiation for a WTRU 602 is shown. Figure 6 Presented Figure 5 Details of the on-demand EAS instantiation process are described in . Figure 6 Detailed message flows between the WTRU 602, EDN 604, and / or RMS 606 are shown for the WTRU 602 to perform on-demand EAS instantiation required for terminal-based edge autoscaling.

[0140] For example, the prerequisites, conditions, configurations, network configuration information, pre-configuration and / or pre-configuration information for the WTRU 602 may include that the WTRU 602 has a valid subscription that allows the use of and communication with edge services present in the mobile network; the WTRU 602 is connected to the mobile network; the WTRU 602 has established a PDU session to the source EDN 604; and / or the WTRU 602 is equipped with security credentials and authorization credentials that are required to communicate with elements that make up the edge enabling layer (e.g., ECS and EES, etc.).

[0141] An exemplary PDU session establishment process may be outlined in the 3GPP standard. EDN 604 (also referred to as DNN) selection may generally be provided by the PCF using URSP rules. EDN 604 may also be configured by other methods (e.g., fixed profile, user profile, EEC, etc.).

[0142] At EDN initialization 630, RMS 606 may have been instantiated ( Figure 6 612. If the EDN 604 is configured for EAS 614 over-provisioning, one or more EAS 614 may be created by the RMS 606 associated with the EDN 604. When the EAS 614 begins execution, the EAS 614 may register with its associated EES 612.

[0143] In step 1a at 632, the orchestrator and / or registry 616 may cause ( Figure 6 (not shown) EDN 604 retrieves the EAS image from orchestrator registry 616. EDN 604 may begin executing the retrieved EAS 614 on a hardware platform present in EDN 604. EDN 604 configuration may trigger step 1a at 632, thereby instructing RMS 606 to instantiate a predefined EAS 614. Alternatively or in addition, EES 612 may trigger step 1a at 632 by requesting an over-configuration of one or more EAS 614.

[0144] In step 1b at 633, upon startup, each EAS 614 may register with its EES 612. As a result, each registered EAS 614 may be discovered as an executing EAS. Each registered EAS 614 may provide services to the WTRU 602.

[0145] In step 2, as part of the EDN initialization 630 process, and in order to support on-demand EAS instantiation from the WTRU 602, the EES 612 may learn of the EAS 614 that may be used for on-demand instantiation.

[0146] In an example, step 2a at 634 may include a message providing a list of on-demand EAS 614. RMS 606 may provide a list of on-demand EAS. Orchestrator and / or registry 616 may be informed of the list. RMS 606 and / or orchestrator and / or registry 616 may provide EES 612 via an API call to EES 612.

[0147] Alternatively or in addition, at 635, EES 612 may access and check RMS 606 for a list of on-demand EAS 614. An API call to RMS 606 and / or orchestrator and / or registry 616 may discover the list of EAS 614.

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

[0149] although Figure 6 Not shown, but if the EES 612 was previously registered with the ECS, the EES 612 may update its registration with the ECS by providing a list of on-demand EASs 614 .

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

[0151] In step 3a at 641, AC 608 may notify EEC 610 that it wants to use EAS 614. This may be performed by different techniques. For example, AC 608 may issue a DNS request that EEC 610 intercepts. Alternatively or in addition, AC 608 may perform an API call to EEC 610. Alternatively or in addition, AC 608 may use a software library that ultimately notifies EEC 610. Alternatively or in addition, AC 608 may perform an OS call that will notify EEC 610.

[0152] In step 3b at 642, the EEC 610 may issue an EAS discovery request to the EES 612, which includes the AC 608 identifier and the EAS 614 selection filter criteria. Upon receiving the request, the EES 612 may search for an EAS 614 that can meet the requirements of the AC 608. The EES 612 may consider the EAS 614 in execution (e.g., registered EAS) and / or the EAS on demand 614 (e.g., a list of EAS on demand) to complete the EAS 612 search based on the request parameters. Both the EAS in execution and the EAS on demand 614 may be considered in the EAS 614 search based on the request parameters.

[0153] Although in Figure 6 640 requests, the WTRU 602 and / or the EEC 610 may subscribe to receive EAS 614 discovery notifications. The subscription may include an AC 608 identifier and / or EAS 614 selection filter criteria.

[0154] The information included in the EAS discovery 640 request is defined in 3GPP 23.558v17.1.0 clause 8.5.3.2. The information included in the EAS discovery 640 subscription is defined in 3GPP 23.558v17.1.0 clause 8.5.3.4. The discovery filter conditions are defined in 3GPP23.558v17.1.0 table 8.5.3.2-2, for which additional information may also be provided, such as EAS614 categories and / or EAS 614 on-demand discovery filter conditions. The contents of 3GPP 23.558v17.1.0 are incorporated herein by reference.

[0155] The EAS 614 category may indicate whether the requester wants to be notified of only an executed EAS 614 (e.g., a registered EAS), an on-demand EAS 614 (e.g., a list of on-demand EAS), and / or both types. Alternatively or in addition, the EAS 614 status field may be extended to specify an EAS 614 category.

[0156] The EAS 614 on-demand discovery filter condition may include filter condition information indicating the requested KPI for on-demand instantiation. Alternatively or in addition, the EAS discovery 640 filter condition may be extended to specify the EAS 614 on-demand discovery filter condition. For example, the average instantiation duration may be used to specify that the average EAS instantiation 650 time spent instantiating the EAS 614 does not exceed the indicated duration. The instantaneous instantiation duration may be used to specify that the EAS instantiation 650 time spent instantiating the EAS 614 in the current platform state does not exceed the indicated duration. The instantiation failure rate may specify that when the EAS 614 is instantiated, the average EAS instantiation 650 failure rate does not exceed the indicated failure rate. Implicit on-demand instantiation using existing "AC scheduling" and "EAS scheduling" parameters may be used to provide a matching window that implicitly triggers the instantiation of one or more EAS 614 instances.

[0157] In step 3c at 643, the EES 614 may return a list of EAS 614 to the WTRU 602, which may include an executed EAS (e.g., a registered EAS) and / or an on-demand EAS 614 (e.g., a list of on-demand EAS). Alternatively or in addition ( Figure 6 ), if EAS discovery 640 subscription is used, the EES 612 may send an EAS 614 discovery notification to the WTRU 602.

[0158] The EAS discovery 640 response or notification may include a list of EAS 614, which should include the necessary information required for EAS 614 selection and subsequent EAS 614 communication. The information provided to the EAS 614 (e.g., registered EAS) for execution is defined in 3GPP 23.558v17.1.0 clause 8.5.3.3 (if request is used) and 3GPP 23.558v17.1.0 clause 8.5.3.6 (if notification is used). EAS profiles are defined in 3GPP 23.558v17.1.0 clause 8.2.4.

[0159] Provide information for EAS profiles, EAS discovery 640 responses, and EAS discovery 640 notifications to support on-demand EAS 614, e.g., EAS profiles, EAS discovery 640 responses, and / or EAS discovery 640 notifications. For example, an EAS 614 profile may include an EAS 614 category and / or an EAS 614 on-demand KPI. Alternatively or in addition, the EAS category and / or EAS state may indicate whether the EAS 614 is an executed EAS (e.g., a registered EAS) or an on-demand EAS (e.g., a list of on-demand EAS). Alternatively or in addition, the EAS 614 on-demand KPI and / or the EAS service KPI may indicate an on-demand EAS KPI for instantiation. These EAS service KPIs may be the same as the EAS 614 on-demand discovery filter conditions defined in step 3b at 642. The EAS discovery 640 response and / or the EAS discovery 640 notification may include an existing lifetime parameter. The existing lifetime parameter may be set to “0” to indicate an “on demand” EAS 614 .

[0160] In step 4 at 651, upon receiving the list of EAS 614 (as shown in step 3c at 643), the WTRU 602 may perform EAS 614 selection. The EEC 612 may perform the selection. Figure 6 As shown, 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.

[0161] The on-demand EAS instantiation request 651 may be performed by calling an API of the EES 612. For example, the information in the request may include 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.

[0162] The requestor identifier may be an 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 a successful authorization of an edge computing service. The WTRU 602 location may be described in 3GPP 23.558v17.1.0 clause 7.3.2. The requested SC support may be an application context relocation (ACR) type requested by the EEC 610. The requested SC planning may indicate whether the EES 612 performs SC planning for the application. The EAS 614 characteristic may correspond to the EAS 614 discovery filter condition described in 3GPP 23.558v17.1.0 Table 8.5.3.2-2 and is further provided in step 3b at 642 of the process.

[0163] The EAS instantiation information may indicate whether the execution of the EAS instantiation 650 may be performed synchronously or asynchronously with the on-demand EAS instantiation request 651. The EAS notification endpoint refers to the endpoint that the EEC 610 exposes to receive EAS 614 information if asynchronous EAS instantiation is used. The EAS instantiation 650 timeout may be the duration that the WTRU 602 is allowed to perform the instantiation. After this duration, the WTRU 602 may consider that the instantiation has failed and needs to be canceled.

[0164] In step 5 at 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. For example, the request sent to the RMS 606 may include the EAS 614 identifier obtained in step 2 of the process and / or the information received from the EAS instantiation request 651 of step 4. Optionally, alternatively, and / or in addition, the request sent to the RMS 606 may indicate hardware resources of the EAS 614 that need to be instantiated.

[0165] In the example, as seen in step 6, EAS instantiation 650 may be performed synchronously with on-demand EAS instantiation request 651. EES 614 may hold the on-demand EAS instantiation response in step 6c at 655 until the newly requested EAS 614 has been instantiated in EDN 604 in step 6a at 653 and registered with EES 612 in step 6b at 654. In this exemplary model, details about the newly created EAS 614 may be included in on-demand EAS instantiation response 655 in step 6c.

[0166] The data included in the EAS instantiation response 655 may be similar to the data of the EAS discovery response described in step 3 at 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 executing EAS (e.g., a registered EAS).

[0167] In an example, as seen in step 7, the EAS instantiation 650 may be performed asynchronously with the on-demand EAS instantiation request 651 due to, for example, the longer instantiation time of certain applications. In step 7a at 656, the EES 612 may immediately return a response to the WTRU 602 indicating the success or failure of the request. In step 7b at 657, the EAS 614 may be created in the EDN 604. In step 7c at 658, the EAS 614 may have been registered with the EES 612. In step 7d at 659, the EES 612 may issue a notification to the WTRU 602 indicating the details of the newly created EAS 612 in the notification body. As a prerequisite to using asynchronous mode, the WTRU 602 may need to subscribe to the EES 612 to receive EAS 614 notifications.

[0168] The information included in the EAS instantiation response 656 provides status regarding the request in step 4 at 651 having been received. The information included in the EAS instantiation response 656 may also indicate whether the request can be processed at this time. A failure may indicate that the request was not accepted and a reason may be provided. The request may be resubmitted.

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

[0170] In step 8 at 662, the EAS information may be relayed back to the requesting WTRU 602 in accordance with the method for requesting EAS use 660. For example, the AC 608 executing on the WTRU 602 may receive the EAS IP address in a DNS response. Alternatively and / or in addition, the AC 608 may receive the EAS IP address in, for example, an API response issued from the EEC 610. Alternatively or in addition, the EAS IP address may be received in a function call return value. Alternatively and / or in addition, the EAS IP address may be received in an OS call response.

[0171] In step 9 at 664, the WTRU 602 may use the received IP address to access the on-demand EAS 614. The AC 608 executing on the WTRU 602 may gain access.

[0172] Figure 7 An exemplary selection process 700 that may be performed on a WTRU by, for example, an EEC is presented. The exemplary selection process 700 illustrates how an EAS discovery response may be evaluated when both an implemented EAS (e.g., a registered EAS) and an on-demand EAS (e.g., a list of on-demand EAS) are combined. The exemplary selection process 700 illustrates how an on-demand EAS may be selected for WTRU-based edge autoscaling. The exemplary selection process 700 illustrates a fallback path when EAS selection fails.

[0173] Figure 7 An exemplary process for on-demand EAS selection for a WTRU is shown. For example, Figure 7 An exemplary WTRU selection method that may be performed by the EEC may be presented.

[0174] In step 1 at 702, the WTRU may send an EAS discovery request and receive an EAS discovery response. Alternatively or in addition, if the WTRU is 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 on the WTRU by, for example, the EEC. These actions may be as follows: Figure 6 3 (e.g., specifically, in step 3b at 642, in step 3c at 643 and / or due to periodic updates). If the AC executed on the WTRU requires the use of EAS, the WTRU may proceed to step 2 at 704.

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

[0176] In step 3 at 706, the WTRU may choose to instantiate an on-demand EAS because an executing EAS was not found and / or it does not meet the requirements. If an on-demand EAS is found and it meets the requirements, then in step 4 at 708, the WTRU may select that EAS and attempt to instantiate that EAS. If the EAS does not meet the requirements, then in step 5 at 710, the WTRU may attempt to re-evaluate. These actions may be performed, for example, by an EEC executing on the WTRU.

[0177] In step 4 at 708, the WTRU may attempt to instantiate the selected EAS by forming an EAS instantiation request, such as Figure 6 Contextual WTRU information (such as application usage, platform status and / or connection conditions) may affect the request content. More details on WTRU conditions are described in step 4 at 651 of FIG. Fig.10 Described in.

[0178] The WTRU may send an on-demand EAS instantiation request and receive a response. If the response is successful, then in step 6 at 712, the WTRU may select the provided EAS and may notify the AC. If the instantiation fails, then in step 5 at 710, the WTRU may attempt to re-evaluate. The EEC executing on the WTRU may perform these actions.

[0179] In step 5 at 710, a WTRU in this state may be dormant. The WTRU may periodically (e.g., within a time period) decide to re-evaluate its current status. Alternatively or in addition, the WTRU may receive a wake-up event, such as from an AC executing on the WTRU to request EAS, from a cache validity timeout timer, and / or from a network event such as an ECS notification and / or an EES notification.

[0180] If appropriate, the WTRU may decide to resolve the request by using its EAS discovery cache, and the WTRU may continue to use the cache to perform a re-evaluation in step 2 at 704. Alternatively or additionally, if the WTRU cache is invalid or the WTRU determines that the cache needs to be refreshed, it may proceed to step 1 at 702 to query the network and perform EAS discovery again. The EEC executing on the WTRU may perform these actions.

[0181] In step 6 at 712, the WTRU may select an EAS and begin using the selected EAS, such as Figure 6 8 at 662 and step 9 at 664, respectively. It can be selected by the EEC and used by the AC, both of which are executed on the WTRU.

[0182] The 3GPP architecture for implementing edge computing does not support EAS termination from the WTRU. Instead, a WTRU method for EAS on demand reduction is required. An implementation of the WTRU method for EAS on demand reduction may be used when the WTRU does not need to use EAS on demand. This process may include termination of the EAS on demand that the WTRU has previously instantiated. In addition to the WTRU being able to use, Figure 6 The prerequisites and / or configurations described in may also apply one or more on-demand EASs.

[0183] Figure 8 An exemplary process 800 for on-demand EAS termination 810 for a WTRU 802 is shown. In step 1 at 812, the WTRU 802 may periodically (on a time basis) perform runtime verification of the EAS 814 that the WTRU 802 uses. The WTRU 802 may decide to terminate some EAS 814 to minimize its edge consumption footprint. Alternatively or in addition, the WTRU 802 may be notified that the EAS 814 is no longer needed and terminated. The EEC 810 may perform EAS 814 termination.

[0184] The WTRU 802 may choose to terminate an EAS 814 that the WTRU 802 has instantiated as needed. Alternatively and / or in addition, the WTRU 802 may choose to terminate an executing EAS 814 that the WTRU 802 has discovered. The WTRU 802 may issue a termination request at any time for any EAS 814 that the WTRU 802 has previously discovered or instantiated.

[0185] The detection and notification of unused EAS 814 may be accomplished through different techniques. For example, the WTRU 802 may detect that the AC 808 is no longer running via the WTRU 802 OS, and the WTRU 802 may then terminate its associated EAS 814. Alternatively or in addition, the AC 808 may notify the EEC 810 via an API call that the EAS 814 is not needed. Alternatively or in addition, the WTRU 802 may perform traffic detection to detect that the EAS 814 has not been used for a period of time. Other methods may also achieve similar results.

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

[0187] In step 3 at 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 sent to the RMS 806 may include the EAS identifier received from the EAS termination request 822 from step 2 of the process.

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

[0189] The EAS termination request 822 may indicate whether the termination is optional or forced. An optional 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 whether the EAS 814 is in use. The WTRU 802 may require authorization to terminate the EAS 814. For example, the WTRU 802 may not be allowed to forcefully terminate the EAS 814.

[0190] In the example of optional termination, if EAS 814 can be terminated and / or there are still active users, EES 812 can verify EAS 814. EES 812 can learn the use by performing API calls to EAS 814. Alternatively or in addition, EES 812 can learn the use by tracking EAS 814 used by WTRU 802 instances. In the example of use preventing optional termination, EES 812 can select actions to allow optional termination. For example, once the EAS 814 user context has been relocated, EES 812 can trigger optional termination of ACR and EAS 814 for the remaining users. If optional termination is not executable, EES 812 can choose to retry EAS 814 termination later or can choose not to perform EAS 814 termination at all.

[0191] In the example of forced termination, EES 812 may not verify the use of EAS 814 and may immediately terminate EAS 814. Alternatively or in addition, EES 812 may follow optional termination logic unless EAS 814 is terminated eventually.

[0192] In step 4, in the example, EAS termination 820 may be performed synchronously with on-demand EAS termination request 822. Therefore, in step 4c, EES 812 may retain on-demand EAS termination response 843. EES 812 may retain the response until EAS termination 820 is completed in step 4a and the EAS termination has been deregistered from EES 812 in step 4b, as seen at 841 and 842, respectively.

[0193] The data included in the EAS termination response 843 may be status information about the termination request 822. For example, the response 843 may indicate that the EAS 814 has been terminated, that the termination has not been authorized, that the termination has been delayed, and / or that the termination has been 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.

[0194] In step 5, in an example, the EAS termination 820 may be performed asynchronously with the on-demand EAS termination request 822, for example due to the longer termination time of certain applications. Therefore, the EES 812 may immediately return a response to the WTRU 802, as shown in step 5a at 851. The response may indicate success or failure of the request. For example, the request may indicate that the termination 820 has not been authorized.

[0195] In the event of a successful termination, the EAS 814 is terminated in step 5b at 853 and the termination is deregistered from the EES in step 5c. Indication of EAS termination and deregistration is seen 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 example of a failed termination, the notification may indicate that the termination has been delayed and / or denied.

[0196] As a prerequisite to using asynchronous mode, the WTRU 802 may subscribe to EAS notifications. The data included in the EAS termination notification may be status information about the termination request.

[0197] Fig. 9 An exemplary process 900 for on-demand EAS instantiation of an EES is shown. Fig. 9 As depicted, the WTRU may have discovered and used the S-EAS 908 located in the S-EDN 902. All S-EES 910 and all T-EES 912 may have the authority to perform the described procedures.

[0198] An example of an EES method for on-demand EAS augmentation on another EES may include the 3GPP edge enabling layer. The 3GPP edge enabling layer 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.

[0199] These procedures are related to service continuity as defined in 3GPP 23.558 v17.1.0 clause 8.8. Depending on the WTRU mobility, the ACR may need to instantiate a target EAS (T-EAS) located at the target location 914. Depending on the predicted future mobility of the WTRU, the service continuity plan (SCP) may need to instantiate several possible T-EASs located in one or more target locations.

[0200] Certain ACR procedures may rely on the EEC executing on the WTRU to discover and instantiate the T-EAS 914, as described in 3GPP 23.558 v17.1.0 clauses 8.8.2.2, 8.8.2.3, and 8.8.2.6. These procedures may benefit from the previously described Figures 5 to 8 The method introduced in .

[0201] Certain ACR procedures may require the EES (source or target) to perform T-EAS 914 discovery as described in 3GPP 23.558 v17.1.0 clauses 8.8.2.4 and 8.8.2.5.

[0202] In the example, although conceptually an on-demand EAS instantiation for the WTRU, the EAS expansion requested by another EES may occur between two EDNs, the source EDN (S-EDN) 902 and the target EDN (T-EDN) 904. The expansion process has several prerequisites, conditions, configurations, or pre-configurations, for example, the WTRU may have a valid subscription that allows the use of edge services present in the mobile network and communication with it. The WTRU may be connected to the mobile network. The WTRU may have established a PDU session to the S-EDN 902. The exemplary PDU session establishment process is outlined in 3GPP 23.502v17.2.1 clause 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 configured by other methods (e.g., fixed profiles, user profiles, and EEC, etc.). The contents of 3GPP 23.502v17.2.1 are incorporated herein by reference.

[0203] In step 1 at 921, the EDN initialization process 920 can be similar to the process described above. Both EDNs (e.g., S-EDN 902 and T-EDN 904) can be equipped with edge enablement layer applications. RMS 906 can provide a list of on-demand EAS to each EES (e.g., S-EES 910 and T-EES 912). RMS 606 can instantiate applications required for edge data network operation.

[0204] 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 and T-EAS 914 discovery according to 3GPP 23.558 v17.1.0 clause 8.8.3.2.

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

[0206] 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 search for an EAS that can satisfy the requirements. In the EAS search based on the request parameters, both the active EAS (e.g., registered EAS) and the on-demand EAS (e.g., a list of on-demand EAS) may be considered. The information included in the EAS discovery request 934 may be the same as the information previously provided in the Figure 6 Same as described in .

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

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

[0209] In the example, EAS instantiation 940 begins with an on-demand EAS instantiation request 941, which may be executed by calling an API of T-EES 912. The information provided by the EAS instantiation request 941 may be used with Figure 6 Same as described in .

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

[0211] In step 5, when used for the ACR process, EAS instantiation 940 may be performed synchronously. Therefore, T-EES 912 may hold the on-demand EAS instantiation response 945 in step 5c until the newly requested T-EAS 914 has been created in step 5a at 943 and the T-EAS 914 may have been registered with T-EES 912 in step 5b at 944. In step 5c at 945, details about the newly created T-EAS 914 may be included in the on-demand EAS instantiation response 945. The data included in the EAS instantiation response 945 may be the same as the Figure 6 Same as described in .

[0212] An example of an ECS method for supporting on-demand EAS configuration is described herein. For example, during the service configuration process defined in 3GPP 23.558 v17.1.0 clause 8.3.3, the EEC of the WTRU may attempt to discover a list of EESs via the ECS that are suitable for providing the service requested by the AC of the WTRU. Thus, the ECS service configuration response may include a list of EESs, which in turn includes a list of registered EAS identifiers corresponding to the EAS being performed.

[0213] To support on-demand EAS instantiation, when creating the list of EESs, the ECS service configuration request may indicate the WTRU's EES if the ECS is required to consider implemented EAS, on-demand EAS, or both. The ECS service configuration response may include a list of available on-demand EAS identifiers provided by the EES. The on-demand EAS identifiers may be mixed with implemented EAS identifiers, in which case the response format may remain the same and the list of EAS identifiers may include both implemented EAS identifiers and on-demand EAS identifiers. Alternatively or in addition, the response format may include an indication that allows the WTRU to distinguish between implemented EAS 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 implemented EAS and on-demand EAS available at the EES.

[0214] At EES registration or EES registration update, ECS may obtain a list of on-demand EAS, as defined in 3GPP 23.558v17.1.0 clause 8.4.4. More specifically, when registering to ECS, EES issues a registration request that includes an EES profile according to 3GPP23.558v17.1.0 clause 8.4.4.3.2. The EES profile may include a list of EASIDs, which may include both executed EAS and on-demand EAS. Alternatively or in addition, a separate list may be used, for example, to distinguish between executed EAS identifiers and on-demand EAS identifiers. When the EES profile changes, EES may issue an EES registration update according to 3GPP 23.558v17.1.0 clause 8.4.4.3.4, which may include executed EAS identifier requests and on-demand EAS identifier requests, and may also distinguish between the two.

[0215] During the ACR process, the S-EESS may perform T-EES discovery using the ECS. The ECS may then return a list of EES profiles to the S-EES, which may include an on-demand EAS identifier as previously described for the WTRU.

[0216] This article describes an example of a WTRU-based edge auto-scaling architecture. For example, Fig.10 1 is a diagram illustrating an exemplary WTRU-based edge auto-scaling architecture 1000. The architecture 1000 may include various components described below, such as an edge enabled client (EEC) 1010 present on a WTRU 1002.

[0217] The EEC 1010 may be a WTRU 1002 edge-enabled function that provides access to resources of an edge computing network 1015. The functions of the EEC 1010 may include retrieving edge computing data from the network 1015, maintaining the EEC 1010 configuration based on the retrieved edge computing (EC) data, providing discovery capabilities for EC resources, and / or providing access to EC resources.

[0218] Alternatively and / or in addition, as described above, the EEC 1010 may act as a gateway towards the EDN to provide the ability to scale up on demand and the ability to scale down on demand. Alternatively and / or in addition, the EEC 1010 may act as an edge computing data source that is used to derive the WTRU 1002 edge computing context. Information such as available EDNs, available EESs, available EASs, EASs used 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 use different methods to provide the EC context on the WTRU 1002. For example, the information may be exposed via an EEC API, stored in a file, provided via a shared database, obtained via the WTRU OS, and / or exposed via a library package.

[0219] An application client (AC) 1020 may be an application that needs to use the EC. The AC 1020 may connect to the EEC 1010 via reference point EDGE-5 to discover the endpoint addresses of the EAS available in the network. The AC 1020 may also act as a context data source that is used to derive 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.

[0220] The context data source 1030 may be a different data source used to establish the context of the WTRU 1002. In an example, these data may be used as a source to understand the behavioral activity patterns of the user in different contexts. Alternatively and / or in addition to the described context data source 1030, EC data may be used to establish the WTRU 1002 edge context and behavior. The data source may be obtained from various sources such as sensors, logs, hardware, OS, etc.

[0221] The WTRU context-aware function 1040 may use the context data source 1030 to derive context-aware rules that are 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 if the user is sleeping, attending a meeting, working, and / or driving, etc. In such context-aware functions, artificial intelligence (AI) techniques and machine learning (ML) techniques are typically used. In WTRU-based edge auto-scaling, the context-aware function may generate context data and rules for making edge auto-scaling decisions. The WTRU context-aware function 1040 may be implemented as a standalone application, may be part of a context-aware framework, may be part of an 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 auto-scaling function 1050, etc.

[0222] The WTRU-based edge auto-scaling function 1050 may use the context information generated by the WTRU context awareness function 1040 to decide to scale up or scale down edge computing resources. Alternatively and / or in addition, the WTRU-based edge auto-scaling function 1050 may directly use the raw context data. The WTRU-based edge auto-scaling function 1050 may be implemented as a standalone application, may be part of an edge auto-scaling framework, may be part of an 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.

[0223] Fig.11 and Fig.12 yes Fig.10 An exemplary variation of the WTRU-based auto-scaling architecture 1000 is shown.

[0224] Fig.11 An exemplary WTRU-based edge auto-scaling architecture 1100 in an EEC 1110 is shown. Fig.11 A compact variant of the WTRU 1102 elements is presented, where both auto-scaling and context awareness can be implemented as part of the EEC 1110. The EEC 1110 can obtain raw context data, which can directly derive context rules and internal auto-scaling decisions. Specifically, the WTRU-based edge auto-scaling context awareness function 1140 located within the EEC 1110 can provide context rules and auto-scaling decisions to the EEC 1110.

[0225] Fig.12 An exemplary WTRU-based edge auto-scaling architecture 1200 using network AI and / or ML is shown. Fig.12is a variation where context awareness may be hosted on the network side. The raw context data collected at the WTRU 1202 may be sent to a network-based AI / ML federated learning function 1250, for example via a federated learning function 1260 present on the WTRU 1202. The federated learning function 1260 may derive a high-level model by combining internal WTRU 1202 data with external data sources obtained from, for example, other WTRUs, the network, the radio access network, and / or an edge computing framework. This model may then be used to derive rules used by the WTRU-based edge auto-scaling function 1240.

[0226] 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 computing requirements for the video analytics service may be high (e.g., high compute, GPU, large amounts of RAM, and / or high bandwidth). The edge computing requirements may result in a high cost of use. Due to these constraints, a user may configure the video analytics service only at the time of inspection. Examples of WTRU context-aware information and / or rules may indicate that a drone (e.g., WTRU1202) is in flight, has arrived at an inspection location, has activated its camera, and / or is ready to send a video feed to an edge service. In response, when the context requirements are met, the WTRU-based edge auto-scaling function 1240 may perform the following by requesting the EEC 1210: Figure 6 Request to instantiate an edge service by using the EAS instantiation described in .

[0227] In an example, a number of drones (e.g., multiple WTRUs 1202) may join together to perform inspections in a coordinated manner. The joining drones (e.g., multiple WTRUs 1202) may initially share a single video analytics edge service. In this case, the joining drones (e.g., multiple WTRUs 1202) may perform regular EAS discovery. The joining 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 be able to meet performance requirements and discovery results may not be returned to the executing EAS. The WTRU-based edge auto-scaling functionality 1240 on the newly joined drone may trigger expansion such as Figure 6 to improve edge video analytics capabilities.

[0228] When the drone terminates its inspection and returns to its base, it can stop using the video analysis service. Each drone can send Figure 8 Optional EAS termination request as described in . If no more drones are using the EAS, the EES may choose to terminate the EAS, or alternatively and / or in addition, maintain the EAS.

[0229] When the inspection is complete, the drone may leave the area and return to its base. The WTRU-based edge auto-scaling function 1240 may be aware that the inspection has been terminated (e.g., the camera is turned off). Upon learning that the inspection has been terminated, the WTRU-based edge auto-scaling function 1240 for the drone may send a message such as Figure 8 Optional EAS termination request as described in . If no more UAVs are using the video analytics service, the EES may choose to scale down the video analytics service. Alternatively or in addition, after the service is terminated, maintain the service or perform ACR for another instance of the service. Once the last UAV completes the inspection, the WTRU-based edge auto-scaling function 1240 may send an optional EAS termination request that terminates the edge video analytics service.

[0230] In an example, an autonomous vehicle (e.g., WTRU 1202) may use edge services to perform computations to 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 edge services. Assuming the vehicle is parked, the collision avoidance service may no longer be needed. The WTRU context-aware functionality may provide information about whether the user is driving or parked, and the WTRU-based edge auto-scaling functionality 1240 may scale down the driving assistance edge service until the driver starts moving again.

[0231] In an example, a game on the WTRU 1202 may require a game edge service instance for each individual player. When playing collaboratively, each collaborative session may require a second edge service that acts as a rendezvous point for the session. When a first player (e.g., player 1) starts a game, the WTRU-based edge auto-scaling functionality 1240 may scale up the game edge service instance. When a second player (e.g., player 2) arrives, the WTRU-based edge auto-scaling functionality 1240 may scale up the game edge service instance and instantiate the rendezvous point edge service since it is not yet available. When a third player (e.g., player 3) joins, the WTRU-based edge auto-scaling functionality 1240 may choose to instantiate only the game edge service since a rendezvous point service already exists.

[0232] Although features and elements are described above in specific combinations, it will be understood by those of ordinary skill in the art that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) 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 built-in hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: transmitting an edge application server (EAS) discovery request to an edge data network (EDN), wherein the EAS discovery request includes one or more EAS requirements; receiving an EAS discovery response from the EDN, the EAS discovery response comprising a list of one or more EASs associated with an uninstantiated application, the uninstantiated application satisfying the one or more EAS requirements; selecting an EAS from the list of one or more EASs; transmitting an EAS instantiation request to the EDN, the EAS instantiation request indicating the selected EAS; as well as An EAS instantiation response is received from the EDN, the EAS instantiation response indicating that the selected EAS has been instantiated at the EDN, wherein the EAS instantiation response includes instantiation information associated with the selected EAS. 2 . The method of claim 1 , wherein the instantiation information indicates whether the selected EAS has been instantiated synchronously or asynchronously. 3 . The method of claim 2 , wherein the instantiation information indicates that the selected EAS has been synchronously instantiated, and the EAS instantiation response includes EAS information associated with the selected EAS.

4. The method of claim 1, wherein the EAS instantiation response includes an Internet Protocol (IP) address, a fully qualified domain name (FQDN), or a uniform resource locator (URL) of the selected EAS.

5. The method of claim 4, wherein an application client (AC) resident on the WTRU accesses the selected EAS based on the IP address.

6. The method according to claim 1, further comprising: An edge enabled client (EEC) resident on the WTRU selects the EAS from the list of one or more EASs. 7 . The method of claim 1 , wherein the EAS discovery request includes one or more application client (AC) identifiers and EAS selection filter conditions.

8. The method of claim 1, wherein the EAS instantiation request includes one or more of a requestor identifier, a WTRU identifier, security credentials, a WTRU location, requested service continuity (SC) support, a requested SC plan, EAS characteristics, or EAS instantiation information.

9. The method of claim 1, wherein the EAS receives the instantiation response from the EDN via a Domain Name System (DNS) response, an Application Programming Interface (API) response, a function call return value, or an Operating System (OS) call response.

10. The method of claim 1, wherein the EAS discovery request includes one or more of application usage, WTRU platform status, or connection conditions.

11. A wireless transmit / receive unit (WTRU), the wireless transmit / receive unit (WTRU) comprising: A processor and a memory, the processor being configured to: transmitting an edge application server (EAS) discovery request to an edge data network (EDN), wherein the EAS discovery request includes one or more EAS requirements; receiving an EAS discovery response from the EDN, the EAS discovery response comprising a list of one or more EASs associated with an uninstantiated application, the uninstantiated application satisfying the one or more EAS requirements; selecting an EAS from the list of one or more EASs; transmitting an EAS instantiation request to the EDN, the EAS instantiation request indicating the selected EAS; as well as An EAS instantiation response is received from the EDN, the EAS instantiation response indicating that the selected EAS has been instantiated at the EDN, wherein the EAS instantiation response includes instantiation information associated with the selected EAS.

12. The WTRU of claim 11, wherein the instantiation information indicates whether the selected EAS has been instantiated synchronously or asynchronously.

13. The WTRU of claim 12, wherein the instantiation information indicates that the selected EAS has been synchronously instantiated, and the EAS instantiation response includes EAS information associated with the selected EAS.

14. The WTRU of claim 11, wherein the EAS instantiation response includes an Internet Protocol (IP) address, a fully qualified domain name (FQDN), or a uniform resource locator (URL) of the selected EAS.

15. The WTRU of claim 14, wherein an application client (AC) resident on the WTRU accesses the EAS based on the IP address.

16. The WTRU of claim 11 , wherein the processor is further configured to: An edge enabled client (EEC) resident on the WTRU selects the EAS from the list of one or more EASs.

17. The WTRU of claim 11, wherein the EAS discovery request includes one or more application client (AC) identifiers and EAS selection filter conditions.

18. The WTRU of claim 11, wherein the EAS instantiation request comprises one or more of a requestor identifier, a WTRU identifier, security credentials, a WTRU location, requested service continuity (SC) support, a requested SC plan, EAS characteristics, or EAS instantiation information.

19. The WTRU of claim 11, wherein the EAS receives the instantiation response from the EDN via a domain name system (DNS) response, an application programming interface (API) response, a function call return value, or an operating system (OS) call response.

20. The WTRU of claim 11 wherein the EAS discovery request includes one or more of application usage, WTRU platform status, or connection conditions.

21. A wireless transmit / receive unit (WTRU), the wireless transmit / receive unit (WTRU) comprising: A processor and a memory, the processor being configured to: receiving contextual data to apply to learning techniques; determining whether the received contextual data is applicable to the learning technique; generating one or more rules based on the determination; Dynamically update and manage the generated one or more rules; as well as The generated one or more rules are applied to the application.

22. The WTRU of claim 21, wherein one or more of time series modeling or context data clustering is used to determine whether the received context data is suitable for the learning technique.

23. The WTRU of claim 21, wherein the WTRU further applies one or more of contextual preferences, rule-based learning techniques, or rule generalization parameters to generate the one or more rules.

Images