Application aware and configurable device edge services

Abstract

A wireless transmit / receive unit (WTRU) may include a processor. The WTRU may be configured to receive a configuration request from a multi-access edge computing (MEC) application client. The WTRU may be configured to determine a host on which the service instance is running based on one or more of the service URL or the service instance identifier. The WTRU may be configured to send a configuration request to a host for sending to a service instance. The configuration request may include one or more application characteristics and configuration information. The WTRU may be configured to receive a configuration response message indicating a service profile identifier associated with a service instance configured for the application client.

Description

[0001] Cross-reference to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 508,365, filed June 15, 2023, the entire contents of which are incorporated herein by reference. Background Technology

[0002] Multi-access edge computing (MEC), also known as mobile edge computing, deployed at the edge of mobile networks, can facilitate efficient and / or dynamic service delivery to mobile users. The European Telecommunications Standards Institute (ETSI) Industry Specification Group (ISG) MEC Working Group, which began operating in late 2014, aims to define an open environment for integrating MEC capabilities with service provider networks, including applications from third parties. These distributed computing capabilities enable IT infrastructure such as cloud environments to be used for functional deployment in mobile access networks. Summary of the Invention

[0003] A Wireless Transmit / Receive Unit (WTRU) may include a processor. The WTRU can be configured to receive configuration requests from Multi-Access Edge Computing (MEC) application clients. The configuration request may include configuration information and one or more application features associated with the MEC application client. The configuration request may indicate a Service Uniform Resource Locator (URL) or a Service Instance Identifier. One or more application features and configuration information can configure a service instance for the application client. The WTRU can be configured to determine the host on which the service instance is running based on one or more of the service URL or service instance identifier. The WTRU can be configured to send the configuration request to the host for delivery to the service instance. The configuration request may include one or more application features and configuration information. The WTRU can be configured to receive a configuration response message indicating a service profile identifier associated with the service instance configured for the application client.

[0004] WTRU can be configured to communicate with a service instance using one or more of the service URL or service instance identifier.

[0005] The WTRU can be configured to receive queries to discover configurable services. The query may include service instance-specific capability requirements and one or more application features associated with the MEC application client. The WTRU can be configured to identify and / or select one or more service instances that match the service instance-specific capability requirements and support one or more application features associated with the MEC application client. Service instance-specific capability requirements may include requirements for the queried service. Requirements for the queried service may include one or more of the following: a specific host (e.g., host capabilities, such as device type, model, etc.), the ability to reach a specific domain, and / or processing capabilities.

[0006] The WTRU can be configured to send queries to network nodes and / or adjacent Multi-Access Edge Platforms (MEPs) to discover service instances. The query may include one or more capability requirements and one or more application characteristics. The WTRU can be configured to receive a first response message associated with the query. The first response message may include one or more discovered service instances, service capability information, service configuration information, MEP ID or host ID, and / or MEC host location. The service configuration information may indicate whether the service requires configuration information from the consuming MEC application. The WTRU can be configured to select one or more service instances from the one or more discovered service instances upon receiving the first response message. The WTRU can be configured to send a second response message to the MEC application client. The second response may include one or more selected service instances.

[0007] A WTRU can be configured to receive registration requests from a configurable service. The registration request may include application-specific service capability information and one or more configuration requirements. A WTRU can be configured to share application-specific service capability information or one or more configuration requirements with other WTRUs or the network. Other WTRUs may be constrained MEC hosts (CMHs). Application-specific service capability information may include one or more of the following: the specific host hosting the configurable service, the ability to reach a specific domain, processing capacity, other service-specific capabilities, and / or application-specific service capabilities, indicating the service consumption application characteristics supported by the configurable service.

[0008] The host running a service instance can be identified by processing the service URL or the service instance identifier.

[0009] One or more application characteristics may include one or more of the following: application name, identifier, application type, application priority, quality of service (QoS), service type, one or more expected service characteristics, and / or location information associated with the location where the MEC application is running. Attached Figure Description

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

[0011] Figure 1B The illustration shows a method according to one embodiment. Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system.

[0012] Figure 1C The illustration shows a method according to one embodiment. Figure 1ASystem diagram of an example radio access network (RAN) and an example core network (CN) used in the illustrated communication system.

[0013] Figure 1D is a system diagram illustrating an example multi-access edge computing (MEC) infrastructure, according to one embodiment. Figure 1A System diagram of yet another example RAN and yet another example CN used in the illustrated communication system.

[0014] Figure 2 is a system diagram showing an example multi-access edge computing (MEC) infrastructure.

[0015] Figure 3 is a system diagram showing an example European Telecommunications Standards Institute (ETSI) multi-access edge (MEC) reference architecture.

[0016] Figure 4 is a system diagram showing an example constrained MEC (CMEC) host.

[0017] Figure 5 is a system diagram showing an example smart factory.

[0018] Figure 6 is a flow diagram showing an example process for configurable service registration.

[0019] Figure 7 is a flow diagram showing an example process for relay service registration.

[0020] Figure 8 is a flow diagram showing an example process for service discovery query using service capabilities.

[0021] Figure 9 is a flow diagram showing an example process for a relay service discovery query initiated by a multi-access edge (MEC) application.

[0022] Figure 10 is a flow diagram showing an example process for a service availability notification initiated by a multi-access edge platform (MEP).

[0023] Figure 11 is a flow diagram showing an example process for service configuration initiated by a MEC application hosted in a constrained MEC host (CMH).

[0024] Figure 12 is a flow diagram showing an example process for relay service configuration initiated by a MEC. DETAILED DESCRIPTION

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

[0026] As shown Figure 1A The communications system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which can be referred to as a “station” and / or a “STA”)

[0027] The communications system 100 can also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b can be any type of device configured to wirelessly interface to one or more WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b can be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a 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 can include any number of interconnected base stations and / or network elements.

[0028] The base station 114a can be part of the RAN 104 / 113, which can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b can be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which can be referred to as a cell (not shown). These frequencies can be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrums. A cell can provide service to a particular geographical area, which can be relatively fixed, or can vary, for example, based on signal strength or coverage. The cell can further be divided into cell sectors. For example, the cell associated with the base station 114a can be divided into three sectors. Thus, in one embodiment, the base station 114a can include three transceivers, one for each sector of the cell. In an embodiment, the base station 114a can employ multiple-input multiple-output (MIMO) techniques, and can use multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0029] The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over the air interface 116, which can 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 can be established using any suitable radio access technology (RAT).

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

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

[0032] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology such as NR Radio Access, which can establish the air interface 116 using New Radio (NR).

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

[0034] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c can 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 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0035] For example, Figure 1A The base station 114b in FIG. 1C can be a wireless router, Home Node B, Home eNode B, or access point, for example, and can utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b can not be required to access the Internet 110 via the CN 106 / 115. Figure 1A

[0036] The RAN 104 / 113 can be in communication with the CN 106 / 115, which can 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 can have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 can provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, a Figure 1A ​The RAN 104 / 113 and / or the CN 106 / 115 can also be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which can employ a NR radio technology, the CN 106 / 115 can also be in communication with another RAN (not shown) that employs a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0037] The CN 106 / 115 can also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide infrastructure for the provision of voice, video, and / or data services to users. The Internet 110 can 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) suite including TCP / IP, to communicate with each other. The networks 112 can include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 can include another CN connected to one or more RANs, which can employ the same RAT as the RAN 104 / 113 or a different RAT.

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

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

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

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

[0042] Although the transmit / receive element 122 is depicted in the WTRU 102 Figure 1B In one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) to facilitate increasing the WTRU's 102 capacity. For example, the WTRU 102 can include two transmit / receive elements 122, one for transmitting and one for receiving, or in a MIMO configuration, multiple transmit / receive elements 122 can be used to transmit and receive wireless signals.

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

[0044] The processor 118 of the WTRU 102 can be coupled to, and can receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 can include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can 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 can 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).

[0045] The processor 118 can receive power from the power source 134, and can be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 can be any suitable device for powering the WTRU 102. For example, the power source 134 can 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, and the like.

[0046] The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or

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

[0048] The WTRU 102 can include a full duplex radio for which transmission and reception of some or all signals (e.g., some or all signals associated with the UL (e.g., for transmission) and downlink (e.g., for reception) with respect to particular subframes) can be concurrent and / or simultaneous. The full duplex radio can include an interference management unit 139 to reduce and / or eliminate self-interference and / or cross- interference due to concurrent or simultaneous transmission and reception. In one embodiment, the WTRU 102 can include a half duplex radio for which transmission and reception of some or all signals (e.g., some or all signals associated with the UL (e.g., for transmission) or the downlink (e.g., for reception) with respect to particular subframes) are time divided and / or interleaved.

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

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

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

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

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

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

[0055] The SGW 164 can be connected to the PGW 166, which can 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.

[0056] The CN 106 can also serve as a gateway for the WTRUs 102a, 102b, 102c to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide

[0057] Although WTRUs are described in Figures 1A-1D representative embodiments as wireless terminals, it is contemplated that in certain representative embodiments such terminals can use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0058] In representative embodiments, the other network 112 can be a WLAN.

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

[0060] When using an 802.11 ac infrastructure mode of operation or similar, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., a wide bandwidth of 20 MHz) or a dynamically set width via signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, e.g., in an 802.11 system, carrier sense multiple access with collision avoidance (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, STAs, including the AP (e.g., each STA) can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, the particular STA can backoff. Only one STA can transmit at any given time in a given BSS.

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

[0062] Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data can be parsed into two streams by a segment parser. The inverse fast Fourier transform (IFFT) and time domain processing can be done on each stream separately. The streams can be mapped on to the two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above-described 80+80 configuration operations can be reversed, and the combined data can be sent to the medium access control (MAC).

[0063] 802.11af and 802.11ah support sub-1 GHz modes of operation. The channel operating bandwidths and carriers in 802.11af and 802.11ah are reduced relative to those used in 802.11η and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support metering type control / Machine Type Communication, such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, e.g., limited capabilities, including support (e.g., only support) for certain and / or limited bandwidths. MTC devices can include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

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

[0065] In the United States, the available frequency bands that 802.11ah can use are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available to 802.11ah is 6 MHz to 26 MHz, depending on the country code.

[0066] Figure 1D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As described above, the RAN 113 can employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 can also be in communication with the CN 115.

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

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

[0069] The gNBs 180a, 180b, 180c can be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, the WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize signal s in an unlicensed frequency band to communicate with gNBs 180a, 180b, 180c. In the non-standalone configuration, the WTRUs 102a, 102b, 102c can communicate / wirelessly couple to gNBs 180a, 180b, 180c with another RAN, such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c can implement DC principles to substantially simultaneously communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c can serve as the WTRUs' 102a, 102b, 102c mobility anchor point, and gNBs 180a, 180b, 180c can provide additional coverage and / or throughput to serving WTRUs 102a, 102b, 102c.

[0070] Each of the gNBs 180a, 180b, 180c can be associated with a certain Figure 1D As shown, the gNBs 180a, 180b, 180c can communicate with one another over an Xn interface.

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

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

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

[0074] The UPF 184a, 184b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which can 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 can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering of downlink packets, providing mobility anchoring, and the like.

[0075] The CN 115 can facilitate communications with other networks. For example, the CN 115 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c can be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0076] In view of Figures 1A-1D And Figures 1A-1D corresponding description, one or more or all of the functions described herein in relation to one or more of the following: WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein can be performed by one or more emulation devices (not shown). The emulation devices can be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices can be used to test other devices and / or to simulate a network and / or WTRU functionality.

[0077] The one or more emulation devices can perform one or more, or all, of the functions while implemented / deployed as part of a wired and / or wireless communication network to test other devices within the communication network. The one or more emulation devices can perform one or more, or all, of the functions while implemented / deployed temporarily in the communication network. The emulation devices can be directly coupled to the other devices under test and / or can perform testing using over-the-air, wireless communications.

[0078] The one or more emulation devices can perform one or more, or all, of the functions including all functions, without being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices can be used in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement test scenarios for testing one or more components. The one or more emulation devices can be test equipment. The emulation devices can transmit and / or receive data using direct RF coupling and / or wireless communications via RF circuitry (e.g., which can include one or more antennas).

[0079] Figure 2 is a system diagram illustrating an example multi-access edge computing (MEC) infrastructure 200. Example MEC infrastructures can provide an open environment for integrating MEC capabilities within a service provider network, including third parties.

[0080] Figure 3 is a system diagram illustrating an example ETSI MEC reference architecture 300. In Figure 3 , an ETSI MEC reference architecture is shown with functional elements including mobile edge systems and reference points between them.

[0081] Different groups of reference points can be defined between system entities. As Figure 3 illustrated, there can be reference points (Mp) regarding mobile edge platform functions. There can be management reference points (Mm). There can be reference points (Mx) connecting to external entities.

[0082] Mobile edge systems can include multi-access edge hosts and / or multi-access edge management necessary to run mobile edge applications within an operator network or a subset of an operator network.

[0083] A multi-access edge host can be an entity that contains a multi-access edge platform and a virtualization infrastructure that provides compute, storage, and network resources for running multi-access edge applications. It is assumed that a multi-access edge host is deployed at a fixed location of a mobile network operator (MNO) or an edge service provider data center. It can not be possible to dynamically add a multi-access edge host to a MEC system through standardized methods.

[0084] A multi-access edge platform (MEP) can be a collection of basic functions needed to run mobile edge applications on a specific virtualization infrastructure and to enable them to provide and consume mobile edge services.

[0085] A multi-access edge application (MEC application) can be instantiated on the virtualization infrastructure of a multi-access edge host based on a configuration request validated by a mobile edge management.

[0086] A multi-access edge service (MEC service) can be a service provided and consumed by a MEC platform and / or a MEC application. When provided by a MEC application, it can be registered in the service list of the MEC platform through the Mpi reference point. A certain number of MEC services can be necessary, such as RNIS (Radio Network Information Service), location services, and traffic management services. Mobile edge management can include mobile edge system level management and / or mobile edge host level management.

[0087] Mobile edge system level management can include a multi-access edge orchestrator (MEO) as its core component, which has an overview of the complete mobile edge system.

[0088] Mobile edge host level management can include a multi-access edge platform manager (MEPM) and a virtualization infrastructure manager (VIM). Mobile edge host level management can handle the management of mobile edge specific functions of a specific mobile edge host and / or applications running on it.

[0089] There is ongoing work in the ETSI MEC (DGR / MEC-0036 Constrained Devices) entitled "MEC in resource-constrained terminals (fixed or mobile)," which aims to study how to use terminal units, mobile hosts, and personal devices to support cloud computing at the edge.

[0090] Figure 4 is a system diagram illustrating an example constrained MEC (CMEC) host 400.

[0091] ETSI MEC investigates how to use terminal units, mobile hosts, and personal devices to support cloud computing at the edge. The European Telecommunications Standards Institute (ETSI) MEC study focuses on the limited availability of computing resources for running MEC applications and its impact on lifecycle management of VMs, containers, or other forms of virtual instances; the mobility of constrained terminals that impacts reachability, maintenance of reasonable connectivity, device availability, and discovery of appropriate services; the impact of unavailable reliable high-bandwidth backhaul connections (e.g., wired or wireless); and security and authorization using constrained terminals for the privacy of user data.

[0092] There can be different scenarios where it is advantageous to enable a reduced-capability MEC platform (constrained MEC, CMEC) to be deployed on a constrained device, allowing MEC applications to be instantiated on these constrained devices.

[0093] A CMEC host or constrained MEC host (CMH) can be an ETSI MEC host with a MEC platform that supports reduced functionality and features compared to a full-featured telecommunication or infrastructure MEC platform (CMEC platform). CMEC applications, like MEC applications, can interact with the CMEC platform using the Mp1 interface. In one example, a CMEC can be defined as a host (e.g., CMH) without any MEC platform. A CMEC can have a generic virtualization infrastructure capable of deploying and running MEC applications.

[0094] A CMH can support ETSI MEC interfaces (e.g., all ETSI MEC interfaces), such as Mp1 (full-standardized interface), Mp3, Mm5, and Mm7, and / or a subset of these interfaces. Mp3 / Mm5 / Mm7 interfaces can not be specified by MEC ETSI but can be open for implementation. For a constrained MEC host, the implementer can implement a reduced set of functionality for these interfaces. A constrained MEC host can not provide certain MEC services, e.g., RNIS can be provided but BWM can not be provided. A constrained MEC host can have a limit on the number of services running at a certain moment. A constrained MEC host can have a limit on the number of requests it can handle, and / or it can try to save power by going into a sleep mode.

[0095] MEC and / or CMH implementations can provide benefits for multiple use case scenarios. For example, in a vehicular scenario, where a CMH embedded in a vehicle can run applications for the vehicle (e.g., on-board processing of sensor data), other proximate vehicles (e.g., in a queuing situation), or the edge network (for safety and traffic efficiency applications).

[0096] For example, in an Industry 4.0 scenario, mobile robots or robotic arms and mobile cameras can host MEC applications to minimize latency required for certain use cases.

[0097] For example, in a home gaming scenario, cloud-based gaming applications using AR / VR can require ultra-low latency and / or extended compute capabilities, which can be provided by a CMH in the same home.

[0098] Figure 5 is a system diagram illustrating an example smart factory 500. Figure 5 The illustrated system contemplates constrained MEC hosts that can be mobile, such as mobile cameras or robots equipped with CMHs.

[0099] Production lines in a smart factory can include stationary or mobile machines (e.g., robots, robotic arms, etc.) that act continuously and / or on demand. Additional sensors, including video cameras, can be used for real-time monitoring and subsequent intervention by machines, such as stopping the production line and / or removing defective products. Such intervention by machines can generally be instructed / commanded by remote factory workers based on real-time data received from sensors and cameras over a local or wide area network (e.g., over a 5G network).

[0100] It can be assumed that machines and devices in a smart factory have networking, computing, and / or storage capabilities. Computing power on local machines and devices in the factory can support distributed data telemetry and intelligent functions locally. Many cameras and sensors can continuously monitor the production line, with some cameras possibly being on wheels (e.g., carried by guided vehicles). These cameras and sensors are capable of data storage and fast data analysis, including real-time extraction and / or leveraging of corresponding knowledge. Federated learning (FL) combined with advances in deep learning (DL) across multiple participating end devices provides possibilities for optimizing manufacturing processes in a smart factory. Intelligent manufacturing processes can require real-time inferences on collected data to prevent delays, avoid errors, and improve efficiency. To provide factory managers with the ability to quickly parse real-time data, make more informed decisions, and identify potential defects in production, a distributed localized edge computing solution can be utilized.

[0101] Local device capabilities can be combined with additional (more complex but mostly stationary) capabilities available in the end-to-end infrastructure connecting the smart factory and remote digital workers (e.g., telco edge, remote cloud). Running data analysis and detection in these devices can enable real-time detection services. In one example, if data from a smart manufacturing unit is offloaded to a telco edge or any cloud service provider platform, a response can require 50 to 200 milliseconds.

[0102] The mobile camera and sensors can include a CMH, which can provide a far edge service. The mobile camera and robots can run FL agents on the CMH and / or update FL applications on the telco edge. The mobile constrained MEC host can provide FL local model updates to the FL MEC application of the telco edge. Similarly, the FL MEC application of the telco edge can also provide FL global updates to the FL agent MEC application of the CMH.

[0103] The mobile CMH can move on the floor of a factory. As a result, the MEC application (e.g., federated learning agent) hosted on the CMH can become unavailable as it is out of communication coverage and can not be able to communicate with other MEC applications running on the telco edge. If the MEC application in the CMH is providing FL model updates to another MEC application of the telco edge, and vice versa, then the FL application can be impacted.

[0104] The MEC applications running on the CMH in the far edge can use various edge services developed and / or operated by the MNO or third-party application developers. The device edge (or far edge) use cases and applications can require configurable edge services that can be used by many MEC applications (deployed on the CMHs in the far edge or telco edge locations).

[0105] The configurable edge services can require the service-specific capabilities to be advertised (which can not be applicable for any MEC service) and can require the service consuming applications to configure any required service-specific parameters to utilize the service.

[0106] Examples of the configurable edge services can include data cleaning for AI / ML applications, data formatting for FL applications, and / or a relay service to relay data from one MEC application to another MEC application in case the MEC applications cannot directly communicate.

[0107] The MEC applications can require discovery of the configurable services based on the service capabilities and MEC application requirements. The service capabilities and MEC application requirements can vary for each service and MEC application instance. For example, the MEC applications can require a data cleaning service that can understand visual data and location data, or can require a service that can import data from a server.

[0108] MEC applications can also need to configure services as per their requirements and provide the required application specific information. The configuration can be different for each MEC application instance. For example, a MEC application can need to configure a data cleansing service to remove any visual data between 9 AM to 11 AM, remove any location data in a certain location (e.g., city location such as zip code), and import data from a specific server (e.g., abc.com).

[0109] To facilitate discovery of configurable services, a service can need to provide service capabilities and any required configuration information during service registration with the MEC system. For example, a service can inform the MEC system that it supports importing data from a server. The service can also inform the MEC system of specific configuration information that needs to be provided by the service consuming MEC application.

[0110] To use configurable services by MEC applications hosted in a mobile CMH, some issues can need to be addressed. An issue can be how a MEC application can register as a configurable service by providing service specific capabilities and required configuration information to the MEC system. Another issue can be how a service consuming MEC application can discover a configurable service by providing its required service specific capabilities and informing the customization application requirements. Another issue can be how a service of a consuming MEC application can configure a configurable service.

[0111] For example, a relay service can be needed when the communication between a FL MEC application in a CMH and another FL MEC application in a telecom edge is lost. A relay service hosted on another MEC host can be selected to relay model updates between the CMH and the telecom edge. It can be assumed that a CMH that loses connectivity to a telecom edge can use a D2D type connection to interact with an intermediate CMH host or other MEC host.

[0112] A relay service can have certain issues. One issue can be how a MEC application that can be hosted on a CMH can discover a configurable relay service, such as a desired MEC application that can relay data, by providing the desired service capabilities and application requirements.

[0113] Another issue can be how a MEC application hosted on a CMH can register as a configurable relay service provider, such as a relay service needs to know the destination MEC application that data can be relayed to, by specifying the customization capabilities and requirements of using the service.

[0114] Another issue can be how a MEC application hosted on a CMH can configure a relay service so that application specific requirements are supported.

[0115] Registration of service producing MEC applications (e.g., such as relay services) hosted in a CMH (e.g., WTRU) or other MEC host as configurable services can include the following. A service producing MEC application in a CMH or other MEC host that wishes to provide a configurable service can register with a MEP by providing service capability information and service configuration information of the MEC application. The MEP can validate the registration request and can check authorization. If the service is authorized for registration, the MEP can add registration details in a service registry and can send a response to the MEC application indicating success. The MEP can advertise or update other MEPs in other CMHs and MEC hosts about the configurable service. The MEP can also send an advertisement message to the MEO through the MEPM.

[0116] Discovery of configurable services (e.g., relay services) initiated by a MEC application in a CMH (e.g., WTRU) can include the following. A MEC application hosted in a CMH can initiate discovery of a service by sending a query to a MEP in the CMH providing service capability requirements and application characteristics of the MEC application. The MEP can identify and / or select service instances that match the requested service capability information and support the application characteristics. The MEP in the CMH can send the query to one or more other MEPs (e.g., hosted in other CMHs) that can be reachable and nearby. In one example, the MEP in the CMH can send the query to the MEO through the MEPM. The MEO or MEP can select one or more services by comparing the service capability requirements and application characteristics. The MEO or MEP can respond to the MEC application by sending an OK response message. The response message can include a list of one or more discovered services.

[0117] Notification of available configurable services (e.g., such as relay services) to a MEC application in a CMH (e.g., WTRU) can include the following. A MEC application (e.g., in a CMH or in a telecommunication edge node) can create a service availability notification subscription with a MEP by providing service capability requirements and application characteristics. The MEC platform can validate the received subscription request and can create the service availability subscription and can send a success notification to the MEC application. When a service producing MEC application registers a configurable MEC service in the MEC system, the MEC platform can publish service availability notifications to the service consuming MEC application.

[0118] In a CMH (e.g., WTRU), the configuration of a configurable service (e.g., a relay service) by an MEC application can include the following: An MEC application can initiate service configuration by sending a service configuration request message to a MEP that includes service configuration information and application characteristic information. The MEP can forward the service configuration information to other MEPs (e.g., the MEC Platform Manager and MEO). The configuration request can include information received in the service configuration request message (e.g., all information). The MEP hosting the service can receive the configuration information directly from the initiating MEP or from the MEO. The MEP can send a configuration service message to a selected service instance, which can include service configuration information and / or application characteristic information. The service instance can use the service configuration information and / or application characteristics to configure the service for the requesting MEC application.

[0119] Figure 6 This is a flowchart illustrating an example process 600 for configurable service registration. This example process demonstrates how a configurable service 602 can provide service capabilities and the required consumption MEC application configuration information during registration with MEP 604 (e.g., hosted in a CMH or MEC host) to enable the service to be discovered by MEC applications (e.g., running on the same or different CMH or MEC hosts).

[0120] like Figure 6 As shown in 608, configurable service 602 can register with MEP 604 hosted on a CMH or MEC host. In one example, configurable service 602 can register with MEP 604 hosted on a different host than the host running the service instance. The purpose of this registration may be to inform MEP 604 of the service, its capabilities, and the configuration requirements for operation. As part of the registration, configurable service 602 can become discoverable by other MEC applications in the MEC system via the MEP. MEC applications can discover the service regardless of whether the MEC application is running on the same or a different host as the registered service.

[0121] Configurable service 602 can register with MEP 604 by sending a service registration request message to MEP 604. The service registration request message may include a service name identifying the service; a service instance ID identifying the service instance; a service category, used to identify the group or category of the service; a service version; a service status; a service URL indicating how other MEC applications and services can reach the service; service capability information indicating the service-specific capabilities provided; and / or service configuration information indicating whether the service requires any configuration information from consuming MEC applications in order to provide the service.

[0122] The service capability information can be specific to each configurable service and can include a specific host hosting the service; a capability to reach a specific domain; a processing capability, such as the ability to process certain types of data; other service-specific capabilities; and / or application-specific service capabilities indicating service consumption application-specific properties supported by the service.

[0123] The application-specific service capability information can include an application name and ID to identify a specific MEC application instance supported by the service; an application type indicating a type of application supported by the service (e.g., FL application, ML application, streaming, interactive, etc.); an application priority and QoS indicating a priority and quality of service supported by the service; a traffic type indicating a type of application traffic supported by the service; a traffic limit indicating individual and aggregate thresholds on application data transfer rates, size, latency, packet loss, update interval, and frequency supported by the service; and / or a service area indicating a location of the application supported by the service, which can be specified as a set of city addresses, a set of geographic coordinates, a topological network location, etc.

[0124] The MEP 604 can verify the registration request and can check authorization. If the configurable service 602 is authorized to register, the MEP 604 can add the registration details to the service registry with additional information provided in the service capability information and service configuration information. If the registration is successful, the MEP 604 can send a result OK message to the configurable service 602.

[0125] Returning to Figure 6 At 610, the MEP 604 can advertise or update about the service to other MEPs 606 hosted in other CMHs and MEC hosts. The advertisement of the configurable service will make the MEPs 606 aware of the configurable service availability and make the MEC applications faster to service discovery. The MEP 604 can send the advertisement message to other MEPs 606 (e.g., broadcast, multicast, or to selected few MEPs decided by the MEO or the MEPM). The MEP 604 can also send the advertisement message to the MEO.

[0126] The advertisement message can include a service name identifying the service; a service instance ID identifying the service instance; a service category identifying a group or class of the service; a service version; a service status; a service URL indicating how other MEC applications and services can reach the service; a MEP ID / host ID where the service is available; a location of the MEC host (e.g., including the CMH) indicating the service capability information of the provided service-specific capabilities; and / or service configuration information indicating whether the service needs any configuration information from the consuming MEC applications.

[0127] The location information included in the advertisement message can include network location (e.g., access point ID); geographic location; civic location; indoor location; mobility path(s); and / or location accuracy.

[0128] The service capability information can indicate service-specific capabilities that are provided. The service capability information included in the advertisement message can be specific to each configurable service and can include information (e.g., all information) from the service capability information received in the service registration request message.

[0129] The service configuration information can indicate whether the service requires any configuration information from the consuming MEC application. The service configuration information included in the advertisement message can include information (e.g., all information) from the service configuration information received in the service registration request message. The service configuration information can be omitted from the advertisement message to save traffic bandwidth (e.g., if the advertisement is sent via broadcast or multicast) and can instead be communicated during service discovery.

[0130] The process for configurable service registration can also be used to dynamically update service parameters, if needed by the MEC application producing the configurable service. The configurable service producing MEC application can update the full set of parameters of its registration, or update (e.g., only update) those parameters that can have changed. For example, the service producing MEC application can add or remove service-specific parameters in the service capability information; add or delete configuration parameters in the service configuration information; and / or change the service state (e.g., active, inactive, suspended, etc.). The process can also be used to unregister, remove, and / or delete a configurable service registration.

[0131] In the ETSI MEC framework, the configurable service registration process (e.g., including updates and unregistration) can be implemented by enhancing the MEC service management API, as specified in the GS MEC-011 data model.

[0132] In the MEC-011 data model, the service capability information and service configuration information can be added to the ServiceInfo resource data type. ServiceInfo can be used in the MEC service management API to register and update services with the MEP.

[0133] Configurable service registration, updates, and unregistration can be implemented as shown in Table 1.

[0134] Table 1 Figure 7is a flow diagram illustrating an example procedure 700 for relay service registration. The example procedure describes an implementation of configurable service registration in the context of a particular service. The particular service can be a relay service. For example, in the event of a connection loss, a relay service (RS) 702 supports the transfer of application data from one MEC application to another.

[0135] The relay service 702 can transfer data to a particular MEC application instance in a telecommunication edge. The relay service 702 can transfer data to a particular MEC application instance in a CMH. The relay service 702 can transfer data to a requested MEC application type in a telecommunication edge or other CMH.

[0136] As Figure 7 shown, at 708, the relay service 702 can register with a MEP 704 hosted in a CMH or another host. The purpose of this registration is for the MEP 704 to know about the relay service 702 and the capabilities and operational requirements of the service. As part of the registration, the relay service 702 can become discoverable by other MEC applications in the MEC system. The relay service 702 can register with the MEP 704 by sending a service registration request message to the MEP 704.

[0137] Relay service specific parameters can include service capability information indicating what the relay service can provide (e.g., relay to telecommunication edge, relay to CMH1, relay for FL applications, and / or relay for streaming / interactive sessions, etc.). The relay service specific parameters can include service configuration information to indicate whether the relay service needs any information to provide the service or any configuration information. For example, the relay service 702 can indicate that it will need information about the destination MEC application to which data will be relayed. It can also indicate what information about the MEC application relaying the data is needed, such as the application type (e.g., FL application), the application data size to be relayed, the frequency of data updates, and / or the priority of updates, etc.

[0138] The MEP 704 can validate the registration request and can accept the registration.

[0139] Returning to Figure 7 , at 710, the MEP 704 can advertise or update other MEPs 706 hosted in other CMHs and MEC hosts about the service.

[0140] Relay service-specific parameters may include service capability information indicating what the relay service can provide (e.g., relaying to the telecom edge, relaying to CMH1, relaying for FL applications, and / or relaying for streaming / interactive sessions, etc.). Relay service-specific parameters may include service configuration information to indicate whether the relay service requires any information to provide the service or any configuration information. For example, the relay service may indicate that it will need information about the destination MEC application to which the data will be relayed. It may also indicate what information about the MEC application to which the relayed data is needed, such as the application type (e.g., FL application), the size of the application data to be relayed, the frequency of data updates, update priority, etc.

[0141] Figure 8 This is a flowchart illustrating an example process 800 for service discovery queries using service capabilities. This example process 800 describes how MEC applications can discover configurable services using platform services provided by an edge platform (such as MEP) through a query process.

[0142] like Figure 8 As shown, in 808, MEC application 802 can initiate the discovery of configurable services. MEC application 802 can also initiate the discovery of MEP 804 in different MEC hosts. MEC application 802 can send service discovery query messages to discover services.

[0143] Service discovery queries may include: the service name that identifies the service; the service instance ID that identifies the service instance; the service category, used to identify the group or category of the service; the service version; the service status; the service capability requirements, used to indicate the requirements for the queried service; and / or the application characteristics of the consuming MEC application.

[0144] Service capability requirements may include specific hosts for the hosted service; host capabilities (e.g., such as device type, model, etc.), the ability to reach a specific domain; processing capabilities (e.g., the ability to process certain types of data); and / or other service-specific requirements.

[0145] Application characteristic information may include the application name and ID that identify the MEC application instance and can be used to determine whether the application is authorized and can use the service; application type (e.g., FL application, ML application, streaming, interactive, etc.); application priority and QoS, used to indicate the priority and quality of service of the requested application and data transmission; service type (e.g., TCP, UDP, etc.); expected service characteristics (e.g., data transmission rate, size, latency, packet loss, update interval and frequency); and / or location information (e.g., where the source MEC application is running, such as city address, geographic location information, etc.), enabling the discovery of services near the MEC application.

[0146] Service capability requirements and application characteristics can be used to discover services, as requested by MEC applications 802.

[0147] In 810, MEP 804 can identify and / or select a service instance that matches the requested service capability information and supports the application characteristics. The application characteristics can be compared to application-specific capabilities of service instances to determine whether the service instance supports the requesting MEC application 802.

[0148] MEP 804 can query MEO 806 to discover services. ETSI MEC can not specify a MEP that queries service information. This interaction can be supported by the Mm5 interface, where the MEP sends a query to the MEPM, which can forward the query to the MEO; and / or a new interface between MEP 804 and MEO 806 can be used to support APIs between MEP 804 and MEO 806.

[0149] In one example, MEP 804 can query a neighboring MEP 818 (e.g., over the Mp3 interface).

[0150] MEP 804 can send a query to MEO 806 or a neighboring MEP 818 to discover services. The query can include a service name that identifies a service; a service instance ID that identifies a service instance; a service category that identifies a grouping or category of services; a service version; a service status; service capability requirements that indicate details of the service; and / or application characteristics of a MEC application.

[0151] The service capability requirements can include information (e.g., all information) from the service capability requirements received in the service discovery query message.

[0152] The application characteristics can include information (e.g., all information) from the application characteristics received in the service discovery query message.

[0153] In 812, MEO 806 or neighboring MEP 818 can select one or more services by comparing the service capability requirements and application characteristics received in the discovery query message to service capability information of registered services. MEO 806 can have obtained the service capability information from a MEP 804 that registered the service. Neighboring MEP 818 can have obtained the service capability information directly during service registration or from another MEP (e.g., MEP 804) that registered the service.

[0154] The MEO 806 or neighboring MEP 818 can respond by sending an OK response message. The response message can include a list of one or more discovered services. The discovered service information can include a service name identifying the service; a service instance ID identifying the service instance; a service category identifying a grouping or category of services; a service version; a service status; a service URL indicating how other MEC applications and services can reach the service; service capability information indicating service-specific capabilities offered; service configuration information indicating whether the service requires any configuration information from the consuming MEC application; a MEP ID / host ID identifier that the service is available at; and / or a location of the MEC host (including the CMH).

[0155] The service capability information can be specific to each configurable service and can include information (e.g., all information) from the service capability information provided by the service during service registration or registration update.

[0156] The service configuration information can include information (e.g., all information) from the service configuration information provided by the service during service registration or registration update.

[0157] The location information can include a network location, a geographic location, a city location, a mobile path(s), and / or a location precision.

[0158] At 814, the initiating MEP 804 can select a single service from the received list of services or forward the complete list of discovered services to the initiating MEC application 802 by sending an OK response message. The response message can include a list of one or more discovered services. The discovered service information can include information (e.g., all information) from the discovered service information received in the discovery query response message.

[0159] At 816, the service consuming MEC application 802 can select a discovered configurable service instance (e.g., if a list was provided), can configure the selected configurable MEC service instance, and can interact with the selected configurable MEC service instance via its service URL. The MEC host (e.g., CMH) hosting the consuming MEC application 802 can determine (e.g., via a MEC application or MEP trigger) that the selected configurable MEC service is available on another MEC host within D2D range and can establish a D2D connection with that MEC host prior to interacting with the selected configurable MEC service instance.

[0160] In the ETSI MEC framework, the configurable service discovery query procedure can be implemented by enhancing the MEC service management APIs specified in the GS MEC-011 data model.

[0161] In the MEC-011 data model, service capability requirements and application characteristics can be defined as dedicated resource data types or attached to other data resources defined in the MEC-011 data model. The Servicelnfo resource data type can include service capability information and service configuration information.

[0162] Configurable service discovery queries can be implemented, as shown in Table 2.

[0163] Table 2 Figure 9 is a flow diagram illustrating an example procedure 900 for a relay service discovery query initiated by a multi-access edge (MEC) application 902. The example procedure 900 describes an implementation of configurable service discovery (e.g., via a query procedure) in the context of a particular configurable service. The particular configurable service can be a relay service.

[0164] The example procedure 900 can be utilized when a MEC application 902 hosted in a CMH involves interaction with another MEC application in a telecommunication edge or other CMH. The MEC application 902 in the CMH detects that a communication path (e.g., 5G NR, Wifi, etc.) between the CMH and the telecommunication edge or to the other CMH is lost. The MEC application 902 can detect that there is an available D2D type connection with other CMHs in the local area. The availability of the D2D connection can trigger the MEC application to discover a relay service that can forward application data to the MEC application 902 with which it was interacting prior to the loss of connection.

[0165] As shown at 908, the connection between the MEC application 902 and the telecommunication edge in the MEC host or CMH is lost. The MEC application 902 can detect the availability of a direct (e.g., D2D) type connection with other CMHs and can trigger service discovery of a relay service. Figure 9

[0166] At 910, the MEC application 902 can query the MEP 904 for a relay service by sending a service discovery query message to the MEP 904. Relay service specific parameters can include service capability requirements to indicate requirements for the queried relay service and application characteristics of the consuming MEC application 902.

[0167] ​Service capability requirements may include the specific host hosting the relay service (if the MEC application knows it); host capabilities (e.g., such as device type, model, etc.); the relay service's ability to reach a specific domain (e.g., abc.com, xyz.com); the ability to reach the specific host hosting the destination MEC application used for relaying; and / or processing capabilities (e.g., the ability to process FL / ML data, the ability to forward data at a specific rate).

[0168] The application characteristics of a relay service may include the application type (e.g., FL application); the rate at which data is generated; the size of the generated data; the tolerable latency for obtaining a response; and / or the location information of the source MEC application (e.g., city address, geographic location information, etc.) that allows services to be found near the MEC application.

[0169] In 912, MEP 904 can identify and / or select service instances that match the requested service capability information and support application characteristics.

[0170] MEP 904 can query MEO 906 or MEP 920 to find the service and indicate the relay service-specific parameters for service capability requirements and / or application characteristics.

[0171] In 914, MEO 906 or MEP 920, one or more relay service instances can be selected by comparing the service capability requirements and application characteristics received in the discovery query message. In this case, the relay service capability information is compared with that of the registered relay services.

[0172] For example, if the service supports the requested trunk type (e.g., trunk to the telecom edge, trunk to CMH1, trunk for FL applications, trunk for streaming / interactive sessions), then the MEO 906 or MEP 920 can match the capability requirements and capabilities. For example, if the service can reach a domain or specific application for trunking, then the MEO 906 or MEP 920 can match the capability requirements and capabilities. For example, if the service can reach an application hosted on a specific host or domain for trunking, then the MEO 906 or MEP 920 can match the capability requirements and capabilities.

[0173] For example, if the service supports FL / ML type applications and / or can handle specific amounts, sizes, and relay frequencies of data, then the MEO 906 or MEP 920 can match the application characteristics.

[0174] In step 916, the initiating MEP 904 can select a single service from the received service list, or forward the complete list of discovered services to the initiating MEC application 902 by sending an OK response message.

[0175] At 918, the service consuming MEC application 902 can select a discovered relay service instance (e.g., if a list is provided), can configure (e.g., using the previously described production configuration), and / or can interact with the selected relay service instance via its service URL.

[0176] Figure 10 is a flow diagram illustrating an example process 1000 of service availability notification initiated by a multi-access edge platform (MEP). The example process 1000 describes how a MEC application can asynchronously discover a configurable MEC service using a subscription and notification service provided by an edge platform, such as a MEP. The MEP can notify the MEC application when a configurable MEC service that meets certain criteria becomes available.

[0177] As a prerequisite, a MEC application can be interested in consuming a configurable MEC service (e.g., in a CMH device at a far edge or a telco edge). However, an instance of that service can not currently be available. If the configurable service becomes available to the MEC application, the MEC application can want to receive a notification.

[0178] At 1008, to consume the configurable MEC service, the MEC application 1002 (e.g., in a CMH or telco edge node) can create a service availability notification subscription with the MEP 1004. The MEC application 1002 can provide the MEP 1004 with information needed for the MEP 1004 to evaluate whether the configurable MEC service meets the needs of the MEC application 1002.

[0179] The information can include a service name that identifies the service; a service instance ID that identifies an instance of the service; a service class that identifies a grouping or class of services; a service version; a service status; a service capability requirement that indicates a service-specific capability requested by the MEC application; an application characteristic of the consuming MEC application; and / or a notification callback URL of a communication endpoint for the MEP platform to publish notifications to, as applicable.

[0180] The service capability requirement can include a specific host that hosts the service; a host capability (e.g., such as a device type, model, etc.), a capability to reach a specific domain; a processing capability (e.g., a capability to process a certain type of data); and / or other service-specific requirements.

[0181] The application characteristics can include an application name and ID identifying the MEC application instance, which can also be used to determine whether the application is authorized and able to use the service; an application type (e.g., FL application, ML application, streaming, interactive, etc.); an application priority and QoS to indicate the requested application and data transfer priority and QoS; a traffic type (e.g., TCP, UDP, etc.); expected traffic characteristics (e.g., data transfer rate, size, latency, packet loss, update interval and frequency); and / or location information where the source MEC application is running (e.g., city address, geo-location information, etc.) so that services in the vicinity of the MEC application can be found.

[0182] At 1010, the MEP 1004 can validate the received subscription request and create a service availability subscription.

[0183] At 1012, the MEP 1004 can return a success indication to the MEC application 1002, including a reference to the created subscription resource. The MEC platform can publish service availability notifications if the configurable MEC service is available.

[0184] At 1014, a service producing MEC application can register a configurable MEC service in the MEC system that meets the configurable MEC service availability notification subscription criteria and is available to request (e.g., service consume) MEC applications.

[0185] At 1016, the MEP 1004 can issue a service availability notification to the service consuming MEC application 1002 at the callback URL received in the service availability notification subscription request.

[0186] In the notification, the MEP 1004 can provide information about the configurable MEC service, which can be a list of available instances that can include a service name identifying the service; a service instance ID identifying the service instance; a service category to identify a grouping or class of services; a service version; a service status; a service URL indicating how other MEC applications and services can reach the service; service capability information indicating service-specific capabilities offered; service configuration information to indicate whether the service requires any configuration information from the consuming MEC application; a MEP ID / host ID where the service is available; and / or a location of the MEC host (e.g., including a CMH).

[0187] The service capability information can be specific to each configurable service and can include information (e.g., all information) from the service capability information provided by the service during service registration or registration update.

[0188] The service configuration information can include information (e.g., all information) from the service configuration information provided by the service during service registration or registration update.

[0189] The location information can include network location, geographical location, city location, mobile path(s), and location accuracy.

[0190] At 1018, the service consuming MEC application 1002 can select a discovered configurable service instance 1006 (e.g., if a list is provided), can configure (e.g., using the previously described service configuration procedure), and / or can interact with the selected configurable MEC service 1006 instance via its service URL. The MEC host hosting the consuming MEC application (e.g., a CMH) can determine (e.g., by a MEC application or MEP trigger) that the selected configurable MEC service is available on another MEC host within D2D range, and can establish a D2D connection with that MEC host prior to interacting with the selected configurable MEC service instance.

[0191] In the ETSI MEC framework, the configurable service discovery subscription / notification procedure can be implemented by enhancing the MEC service management API as specified in the GS MEC-011 data model.

[0192] In the MEC-011 data model, service capability requirements and application characteristics can be defined as dedicated resource data types or be attached to other data resources defined in the MEC-011 data model. The Servicelnfo resource data type can include service capability information and service configuration information.

[0193] The configurable service discovery subscription / notification can be implemented as shown in Table 3.

[0194] Table 3 Figure 11 is a flowchart illustrating an example procedure 1100 for service configuration initiated by a MEC application 1102 hosted in a CMH. The example procedure 1100 describes how a MEC application 1102 can use platform services provided by an edge platform, such as a MEP, to configure a configurable service. This procedure 1100 can allow the MEC application 1102 to provide requirements and specific configuration information to a configurable service.

[0195] At 1112, a MEC application client 1102 that wants to use a discovered configurable service can initiate configuration of the service. Configuration of the service by the application can be required so that the MEC application client 1102 can use the service as intended. For example, at 1112, the MEP 1104 can receive a configuration request from the MEC application client 1102.

[0196] The request to initiate service configuration (e.g., configuration request) can include a service to be configured indicating which service the application is requesting to configure; configuration information (e.g., service configuration information) for configuring the service; and / or application characteristics associated with the consuming MEC application client 1102. The one or more application characteristics and configuration information can enable configuration of a service instance of the MEC application client 1102.

[0197] The configuration request can indicate a service URL or a service instance ID. For example, the service configuration information can include the service URL or the service instance ID. The MEP 1104 can reach the service based on the URL or the service instance ID.

[0198] The MEP 1104 can receive a query to discover a configurable service. The query can include service instance specific capability requirements and one or more application characteristics associated with the MEC application client 1102. The service configuration information can include information (e.g., all information) from the service configuration information received in the service discovery query response or the service discovery notification. The service instance specific capability requirements can include requirements for the queried service. The requirements for the queried service can include one or more of host capabilities (e.g., such as device type, model, etc.), reachability to a specific domain, and / or processing capabilities. The MEP 1104 can also identify and / or select one or more service instances that match the service instance specific capability requirements and support the one or more application characteristics associated with the MEC application client 1102.

[0199] The one or more application characteristics can include an application name and ID to identify the MEC application instance and can be used to determine whether the application is authorized and able to use the service; an application type (e.g., FL application, ML application, streaming, interactive, etc.); an application priority and QoS to indicate the requested application and data transfer priority and quality of service; a traffic type (e.g., TCP, UDP, etc.); expected traffic characteristics (e.g., data transfer rate, size, latency, packet loss, update interval and frequency); and / or location information (e.g., city address, geographic location information, etc.) where the source MEC application is running so that services near the MEC application can be found.

[0200] The application characteristics and the service configuration information can enable configuration of a service instance of the MEC application client 1102.

[0201] In the ETSI MEC framework, the service configuration request message can be implemented as a new API (e.g., Service_Configuration_Request over Mp1); and / or by extending the MEC application registration message over Mp1 by including the configuration information.

[0202] At 1114, the MEP 1104 can process the service URL or service instance ID to determine the selected service and determine how to reach the service instance. For example, the MEP 1104 can determine the host on which the service instance is running based on one or more of the service URL or service instance identifier. At 1114, the MEP 1104 can send a configuration request to the MEP 1106 (e.g., the determined host). It is possible that the MEP 1104 can determine (e.g., only determine) the correct MEP 1106 to reach and will allow the MEP to forward the configuration information to the correct service instance. The MEP 1104 can forward the configuration information for the service to the MEP 1106 (or to the MEC platform manager and the MEO). The configuration request can include the information (e.g., all of the information) received in the service configuration request message.

[0203] In the ETSI MEC architecture, the message can be directly forwarded to another MEP over Mp3, towards the Mm5 interface of the MEP M, and the MEPM forwards it to the MEO and / or a new interface between the MEPM and the MEO.

[0204] The MEP 1104 can send a query to a network node or a neighboring MEP to discover service instances. The query to the network or neighboring MEP can include one or more capability requirements and one or more application characteristics. The MEP 1104 can receive a first response message associated with the query. The response can include one or more discovered service instances, service capability information, service configuration information, a MEP ID or a host ID, and / or a MEC host location. The service configuration information can indicate whether the service requires configuration information from a consuming MEC application. Upon receiving the first response message, the MEP 1104 can select one or more service instances from the one or more discovered service instances. The MEP 1104 can send a second response message to the MEC application client 1102. The second response can include the one or more selected service instances.

[0205] At 1116, the MEP 1106 hosting the service can receive the configuration information directly from the initiating MEP or from the MEO.

[0206] MEP 1106 can process the service instance ID to determine the service instance to which configuration information must be sent. After the service instance is identified, MEP 1106 can forward the configuration information to the service instance 1108.

[0207] At 1116, MEP 1106 can send a configure service message to the selected service instance 1108. The message can include service configuration information to configure the service and application characteristics of the requesting MEC application client 1102.

[0208] The service configuration information can include information (e.g., all information) from the service configuration information received in the configuration request directly from the initiating MEP 1104 or from the MEO.

[0209] The application characteristics can include information (e.g., all information) from the application characteristics received in the configuration request directly from the initiating MEP 1104 or from the MEO.

[0210] At 1118, the service instance 1108 can use the service configuration information and the application characteristics to configure the service for the requesting MEC application client 1102. For example, the service can create an application context or service profile for each requesting MEC application name and application ID. The service can store the service profile or configuration information for each requesting MEC application. The service can create a PROFILE ID (profile ID) or SERVICE ID (service ID) related to each profile and send it back to the requesting MEC application. The requesting MEC application can use the SERVICE ID to send future requests to the service with the SERVICE ID. The service can retrieve the service profile and can use it as needed by the application.

[0211] The service can accept the configuration and can send an OK response message with the SERVICE ID to the MEP 1106.

[0212] At 1120 and 1122, the OK response message with the configuration can be accepted and the SERVICEJD can be forwarded to the MEC application client 1102 that initiated the configuration of the selected service. For example, the MEP 1104 can receive a configuration response (e.g., from the MEP 1106) at 1120 that indicates a service profile identifier associated with the service instance configured for the MEC application client 1102. The service profile identifier can identify a service profile. The service profile can be a set of information describing service configuration details, such as a consuming MEC application, service configuration details like allocated compute, storage, connectivity, connectivity to remote MEC applications, application filters for sensing, and / or application-specific features that can be supported. For example, the service profile identifier can be a SERVICEJD and / or a PROFILEJD.

[0213] The MEP 1104 can receive a service configuration request from the MEC application client 1102. The MEP 1104 can receive a registration request from the configurable MEC service instance 1108. The registration request can include application-specific service capability information and one or more configuration requirements. The MEP 1104 can share the application-specific service capability information and / or the one or more configuration requirements with other WTRUs or networks. In one example, the other WTRU can be a constrained MEC host (CMH). The application-specific service capability information can include one or more of a specific host hosting the configurable service, a capability to reach a specific domain, processing capability, other service-specific capabilities, and / or application-specific service capability to indicate service consuming application features supported by the configurable service.

[0214] At 1124, the service consuming MEC application client 1102 can interact with the configured MEC service instance 1108 via its service URL. For example, at 1124, the MEP 1104 can communicate with the service instance using one or more of a service URL or a service instance identifier. The service instance identifier can identify a deployed running service instance. For example, in a cloud system, an application package (e.g., application software) can be used for an orchestrator. The orchestrator can deploy and / or instantiate the application software as a virtual machine (VM) or a container in one or more locations. Thus, each VM can be identified by a unique service instance identifier.

[0215] Figure 12 is a flow diagram illustrating an example procedure 1200 for MEC-initiated relay service configuration. The example procedure describes implementation of a configurable service “configuration” in the context of a particular configurable service. The particular configurable service can be a relay service.

[0216] As Figure 12As shown, at 1212, the MEC application 1202 can initiate configuration of the relay service.

[0217] The relay service configuration information can include a TargetMECApp parameter that indicates a target MEC application to which data is to be relayed. The relay service can store this information for use in relaying application data to the target MEC application.

[0218] The relay service configuration information can include a TargetHost parameter that indicates a host on which the target MEC application can be hosted.

[0219] The relay service configuration information can include a CallbackURL parameter that indicates how to reach the MEC application for information and notifications related to the service.

[0220] The relay service configuration information can include an ApplicationDataSize parameter that indicates a data size that the relay service can expect from the MEC application, so that sufficient buffer and storage can be allocated to handle the application data.

[0221] The relay service configuration information can include an AppUpdateInterval parameter that indicates a frequency of relay data updates that the relay service can expect.

[0222] The relay service configuration information can include an ApplicationRelayData parameter that indicates a current snapshot (if available) of the application data to be relayed. For example, it indicates the last known state / profile of the FL data update of the MEC application that needs to be relayed.

[0223] At 1214, after receiving the configuration request, the MEP 1204 can process the relay service URL or relay instance ID to determine the relay service and how to reach the service instance for configuration.

[0224] The MEP 1204 can forward the relay service configuration information to another MEP 1206 (or to the platform manager and MEO), and can include the relay service configuration information initiated earlier at step 1212.

[0225] At 1216, the MEP 1206 hosting the relay service can receive the relay configuration information directly from the initiating MEP 1204 or from the MEO.

[0226] The MEP 1206 can send a configuration service message to the selected relay service instance 1208, which includes the relay service configuration information.

[0227] At 1218, the relay service instance 1208 can receive the configuration information (e.g., all configuration information) and create a service profile for each requesting MEC application name and application ID.

[0228] A relay service profile can be created for each application ID. The relay service profile can include a TargetMECApp parameter that indicates the target MEC application to which data is to be relayed. The relay service can store this information for use in relaying application data to the target MEC application.

[0229] The relay service profile can include a TargetHost parameter that indicates the host that hosts the target MEC application.

[0230] The relay service profile can include a CallbackURL parameter that indicates how to reach the MEC application for information and notifications related to the service.

[0231] The relay service profile can include an ApplicationDataSize parameter that indicates the data size that the relay service can expect from the MEC application so that sufficient buffer and storage can be allocated to handle the application data.

[0232] The relay service profile can include an AppUpdateInterval parameter that indicates the frequency of relay data updates that the relay service can expect.

[0233] The relay service profile can include an ApplicationRelayData parameter that indicates a current snapshot (if available) of the application data to be relayed. For example, it indicates the last known state / profile of the FL data update of the MEC application that needs to be relayed.

[0234] The relay service can store the relay service profile or configuration information for each requesting MEC application. The relay service can create a PROFILE ID or SERVICE ID related to each profile and can send it back to the requesting MEC application. The requesting MEC application can use the SERVICE ID to send future requests to the service with the SERVICE ID. The service can retrieve the relay service profile and can use it to forward the application data to the target MEC application hosted in the target host.

[0235] The relay service 1208 can accept the configuration and can send an OK message with the SERVICE ID to the MEP 1206.

[0236] At 1220 and 1222, the OK message with the configuration acceptance and the SERVICE ID can be forwarded to the MEC application 1202, which initiated the configuration of the desired relay service.

[0237] At 1224, the service consuming MEC application 1202 can interact with the configured MEC relay service instance 1208 via its service URL.

Claims

1. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: receiving a configuration request from a multi-access edge computing (MEC) application client, the configuration request comprising configuration information and one or more application characteristics associated with the MEC application client, the configuration request indicating a service uniform resource locator (URL) or a service instance identifier, wherein the one or more application characteristics and the configuration information enable configuration of a service instance of the MEC application client; determining a host on which a service instance is running based on one or more of the service URL or the service instance identifier; sending the configuration request to the host for transmission to the service instance, wherein the configuration request comprises the one or more application characteristics and the configuration information; and receiving a configuration response message indicating a service profile identifier associated with the service instance configured for the MEC application client.

2. The method of claim 1, further comprising communicating with the service instance using one or more of the service URL or the service instance identifier.

3. The method of claim 1, further comprising: receiving a query to discover a configurable service, the query comprising service instance specific capability requirements and one or more application characteristics associated with a MEC application client; and identifying one or more service instances that match the service instance specific capability requirements and support the one or more application characteristics associated with the MEC application client. The service instance specific capability requirements comprise requirements for a queried service, and wherein the requirements for the queried service comprise one or more of host capabilities, capability to reach a specific domain, or processing capabilities.

5. The method of claim 1, further comprising:

4. The method of claim 3, wherein, sending a query to a network node or a neighboring multi-access edge platform (MEP) to discover service instances, wherein the query comprises one or more capability requirements and one or more application characteristics; receiving a first response message associated with the query, the first response message comprising one or more discovered service instances, service capability information, service configuration information, a MEP ID or a host ID, and a MEC host location, wherein the service configuration information indicates whether the service requires configuration information from a consuming MEC application; upon receiving the first response message, selecting one or more service instances from the one or more discovered service instances; and sending a second response message to the MEC application client, wherein the second response message comprises the one or more selected service instances.

6. The method of claim 1, further comprising: receiving a registration request from a configurable service, the registration request comprising application specific service capability information and one or more configuration requirements; and sharing the application specific service capability information or the one or more configuration requirements with other WTRUs or a network. The other WTRU is a constrained MEC host (CMH). ​ ​ 7. The method of claim 6, wherein, ​ 8. The method of claim 6, wherein, The application-specific service capability information includes one or more of a specific host hosting the configurable service, a capability to reach a specific domain, a processing capability, other service-specific capabilities, or application-specific service capabilities indicating service consumption application features supported by the configurable service.

9. The method of claim 1, wherein, The host on which the service instance is running is determined by processing the service URL or the service instance identifier.

10. The method of claim 1, wherein, The one or more application features include one or more of an application name, an identifier, an application type, an application priority, a quality of service (QoS), a traffic type, one or more expected traffic characteristics, or location information associated with a location where the MEC application is running.

11. A wireless transmit / receive unit (WTRU) comprising a processor configured to: receive a configuration request from a multi-access edge computing (MEC) application client, the configuration request including configuration information and one or more application features associated with the MEC application client, the configuration request indicating a service uniform resource locator (URL) or a service instance identifier, wherein the one or more application features and the configuration information enable configuration of a service instance of the MEC application client; determine a host on which the service instance is running based on one or more of the service URL or the service instance identifier; send the configuration request to the host for sending to the service instance, wherein the configuration request includes the one or more application features and the configuration information; and receive a configuration response message indicating a service profile identifier associated with the service instance configured for the MEC application client.

12. The WTRU of claim 11, wherein, The WTRU is further configured to communicate with the service instance using one or more of the service URL or the service instance identifier.

13. The WTRU of claim 11, wherein, The WTRU is further configured to: receive a query to discover a configurable service, the query including service instance-specific capability requirements and one or more application features associated with a MEC application client; and identify one or more service instances that match the service instance-specific capability requirements and support the one or more application features associated with the MEC application client.

14. The WTRU of claim 13, wherein the service instance-specific capability requirements include requirements for a queried service, and wherein the requirements for the queried service include one or more of a host capability, a capability to reach a specific domain, or a processing capability.

15. The WTRU of claim 11, wherein, The WTRU is further configured to: send a query to a network node or a neighboring multi-access edge platform (MEP) to discover a service instance, wherein the query includes one or more capability requirements and one or more application features; receive a first response message associated with the query, the first response message including one or more discovered service instances, service capability information, service configuration information, a MEP ID or a host ID, and a MEC host location, wherein the service configuration information indicates whether the service requires configuration information from a consuming MEC application; upon receiving the first response message, selecting one or more service instances from the one or more discovered service instances; and sending a second response message to the MEC application client, wherein the second response message includes the one or more selected service instances.

16. The WTRU of claim 11, wherein, The WTRU is further configured to: receive a registration request from a configurable service, the registration request including application-specific service capability information and one or more configuration requirements; and share the application-specific service capability information or the one or more configuration requirements with other WTRUs or a network.

17. The WTRU of claim 16, wherein, The other WTRU is a constrained MEC host (CMH).

18. The WTRU of claim 16, wherein, The application-specific service capability information includes one or more of a specific host hosting the configurable service, a capability to reach a specific domain, a processing capability, other service-specific capabilities, or an application-specific service capability indicating service consumption application characteristics supported by the configurable service.

19. The WTRU of claim 11, wherein, The host on which the service instance is running is determined by processing the service URL or service instance identifier.

20. The WTRU of claim 11, wherein, The one or more application characteristics include one or more of an application name, an identifier, an application type, an application priority, a quality of service (QoS), a traffic type, one or more expected traffic characteristics, or location information associated with a location where the MEC application is running.

Images