Method and procedure for providing IEEE 802.11-based wireless network information services for ETSI MEC

Abstract

To provide a method of implementing a wireless local area network (WLAN)-based radio network information service (RNIS) for a mobile edge computing (MEC) service.SOLUTION: In a method: a response to a request for multi-domain network information transmitted to a mobile edge (ME) application (ME app) is received by a STA from a MEC service of the ME app which runs on an MEP; the ME app obtains the multi-domain network information from an RNIS; and the STA may be associated with an AP controlled by a WiFi controller which is configured to collect measurement information of a plurality of WLANs and provide the measurement information to the MEP. Any one or more of the MEP, ME app and ME service is configured to order the request and response with other requests and responses of one or more other STAs or ME apps.SELECTED DRAWING: Figure 9

Description

[Background technology]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 616,984, filed January 12, 2018, which is incorporated by reference as if set forth in its entirety. Summary of the Invention

[0002] A request for multi-domain network information may be sent by a STA to a mobile edge (ME) application (MEapp). In response to the request, multi-domain network information corresponding to multiple wireless local area networks (WLANs) may be received by the STA. A response to the request may be received from a mobile edge computing (MEC) service of the MEapp running on an ME platform (MEP). In one embodiment, the MEapp may be configured to obtain the multi-domain network information from a radio network information service (RNIS). In one embodiment, the STA may be associated with an access point (AP) controlled by a WiFi controller configured to collect measurement information of multiple WLANs and provide the measurement information to the MEP. Any one or more of the MEP, MEapp, or ME service may be configured to sequence requests and responses with other requests and responses of one or more other STAs or MEapps. [Brief explanation of the drawings]

[0003] Additionally, like reference numbers in the figures refer to like elements.

[0004] [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 1C] 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 1D] FIG. 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 2] FIG. 1 is a block diagram of an exemplary European Telecommunications Standards Institute (ETSI) Multi-Access Edge Computing (MEC) architecture. [Figure 3] FIG. 1 is a diagram of wireless local area network (WLAN) deployment options and MEC Radio Network Information Service (RNIS) interface points. [Figure 4] FIG. 10 is a message diagram illustrating configuring parameters through a request. [Figure 5] FIG. 10 is a message diagram illustrating a new message format for measurement configuration. [Figure 6] A message diagram showing a new message format including sub-options. [Figure 7] A diagram of the Mm5 interface. [Figure 8] FIG. 1 is a diagram of an exemplary orchestration function. [Figure 9] FIG. 10 is a diagram of a STA obtaining information about the surrounding network from an MEC application. [Figure 10] FIG. 1 is a diagram of an exemplary virtual terminal operation. [Figure 11] 1 is a block diagram illustrating a video server employing adaptive forward error correction (FEC). [Figure 12] FIG. 2 is a block diagram illustrating receiver components of a WTRU running the MEapp. DETAILED DESCRIPTION OF THE INVENTION

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

[0006] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., remote surgery), an industrial device and application (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), a consumer electronics device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

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

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

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

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

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

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

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

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

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

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

[0017] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs that may employ the same RAT as the RAN 104 or a different RAT.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0034] The SGW 164 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as anchoring the user plane during handover between eNodeBs, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

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

[0036] The CN 106 may facilitate communication with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and traditional fixed communication devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. Additionally, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

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

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

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

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

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

[0042] A very high throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, sometimes referred to as an 80+80 configuration. In the 80+80 configuration, after channel encoding, the data may be passed through a segment parser that may split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing may be performed separately on each stream. The streams may be mapped onto two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed, and the combined data may be sent to the medium access control (MAC).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0058] The one or more emulation devices may perform one or more functions, inclusive, without being implemented / deployed as part of a wired and / or wireless communications network. For example, the emulation devices may be utilized in a test laboratory and / or in a test scenario in an undeployed (e.g., test) wired and / or wireless communications network to perform tests of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0059] Detailed Description Edge computing and fog computing are emerging technologies that enable service and content providers to offer applications at the edge of the network without utilizing the core network or distant cloud data centers. In other words, edge computing extends "traditional" cloud services (such as Microsoft Azure or Amazon Elastic Cloud) toward the network edge, where applications and services can benefit from low latency, proximity, and context awareness by either moving backend functions closer to client devices, such as smartphones, IoT devices, and intelligent vehicles, or by offloading functions from devices out to the edge.

[0060] Edge computing can be a necessary point of presence for 5G services that require low latency, such as those defined within the Ultra-Reliable and Low-Latency Communications (URLLC) quadrant of the IMT-2020 5G service model. These include autonomous vehicles (cars, drones, etc.), industrial automation and smart factories, robotics, and tactile internet. Edge computing also benefits enhanced mobile broadband (eMBB) and massive machine-based communications (mMTC) by enabling processing to be located at different locations throughout the network, enabling service and network flexibility and optimizing network resources.

[0061] The Multi-Access Edge Computing (MEC) Industry Specification Group (ISG) within the European Telecommunications Standards Institute (ETSI) is the leading standards initiative within the edge computing field. The MEC ISG is chartered to create a standardized, open environment that enables efficient and seamless integration of edge applications from vendors, service providers, and third parties across mobile edge computing platforms within a multi-vendor, multi-domain, mobile edge computing environment.

[0062] A unique characteristic of MEC compared to other edge computing standards and organizations, such as Open Fog Computing, is its objective of providing access to real-time information about the state of the wireless network in order to tailor application behavior and services. During Phase 1 of the MEC ISG (2015-2016), the MEC ISG focused on integration with 3GPP LTE cellular networks. However, during Phase 2 (2017-2018), the MEC ISG expanded its scope to include other access technologies, including 802.11 WLAN.

[0063] FIG. 2 illustrates an exemplary ETSI MEC architecture 200. As shown in FIG. 2, a mobile edge host (MEH) 202 is an entity that includes a mobile edge platform (MEP) 204 and a virtualization infrastructure 206. The MEP 204 may include a collection of essential functions for running mobile edge applications on the virtualization infrastructure. Mobile edge applications (MEapps) 210, 212, and 214 may be instantiated on the virtualization infrastructure 206 of the MEH 202 based on configuration or requests confirmed by mobile edge management. The MEP 204 may include one or more ME services 208 and a service registry 226 and may provide traffic rule control 218 and DNS processing 216. The MEapps 210, 212, and 214 may be configured to communicate with the MEP 204 via Mp1 reference points 220 and 222. Reference point Mp2 224 may provide an interface between the MEP 204 and the virtualization infrastructure 206. In one embodiment, a reference point may be used to connect one or more functional elements.

[0064] The Mobile Edge Platform Manager (MEPM) 228 may manage the application lifecycle 230 and may provide element management functions 234 to the MEP. The MEPM 228 may also manage application rules and requirements 232. Mobile Edge Services (ME Services) 208 may be hosted on the MEP 204 and may provide various capabilities, including communication services, traffic load services, and location services. ME Services may also store or provide wireless network information. ME Services may be provided natively in the MEP or registered as add-on services by a third party.

[0065] The MEPM 228 may be in communication with the MEP 204 via the Mm5 reference point 236. The MEPM 228 may also be in communication with the virtualization infrastructure manager 238 via the Mm6 reference point 242. The virtualization infrastructure manager 238 may be in communication with the virtualization infrastructure via the Mm7 reference point 240. The Mp3 reference point 244 connects the other mobile edge platforms 246 of the other mobile edge hosts 248 to the MEP.

[0066] The mobile edge orchestrator 250 may communicate with the MEPM 228 via Mm3 252 and with the virtualization infrastructure manager 238 via Mm4 reference point 254. Reference point Mm2 256 may be used to connect operations support systems 258 to the MEPM 228. The operations support systems 258 may interface with the mobile edge orchestrator 250 via reference point Mm1 260. Reference point Mx1 262 may connect the operations support systems 258 to a customer-facing service (CFS) portal 264. Reference point Mm8 266 may connect the operations support systems 258 to a user application lifecycle management (LCM) proxy 268 coupled to the mobile edge orchestrator 250 via Mm9 270. The user application LCM proxy 268 may interface with the UE applications 272 via Mx2 274.

[0067] The MEC provides real-time network information to authorized mobile edge applications via the MEC-defined Radio Network Information Service (RNIS). The current MEC RNIS is defined only for 3GPP LTE access networks and may need to be updated to include IEEE-based or other network-based functions. The RNIS provides a Representational State Transfer (REST) ​​application program interface (API) that includes or responds to query or direct access services and notification subscription services. Direct requests for information, such as queries, can be one or more of PlmnInfo, RabInfo, or S1BearerInfo queries. Subscription-based services, such as subscription / notification services, can include CellChangeSubscription / Notification, RabEstSubscription / Notification, RabModSubscription / Notification, RabRelSubscription / Notification, MeasRepUeSubscription / Notification, MeasTaSubscription / Notification, CaReconfSubscription / Notification, S1BearerSubscription / Notification, and / or SubscriptionLinkList / ExpiryNotification.

[0068] All of the above information may be specific to 3GPP LTE. Radio network information for other (non-3GPP) radio access technologies was not considered within the scope of ETSI MEC Phase 1 and was left for future work.

[0069] In Phase 2, around 2017-2018, the ETSI MEC Industry Standardization Group (ISG) expanded the scope to include multi-access edge deployments, including non-3GPP wireless networks. Therefore, WLAN, including IEEE 802.11, is a radio access technology that MEC can support. The definition of WLAN RNIS services begins with the framework API specification. The framework specification does not include any details regarding WLAN network information, API formats, etc.

[0070] IEEE 802.11-2016 includes several possibilities for performing measurements in the WLAN air interface. WLAN radio measurements enable stations (STAs) to observe and collect data about radio link performance and the radio environment. A STA may choose to perform measurements locally, request measurements from another STA, or be requested by another STA to perform one or more measurements and return one or more of the results. The results may be returned via an API or directly to the requesting STA. Radio measurement data is made available to STA management and upper protocol layers, where it can be used for various applications. Radio measurement services may include measurements that enhance WLAN capability, reliability, and maintainability by providing standard measurements across vendors, and the service provides the resulting measurement data to upper layers in the communication stack.

[0071] Note that all nodes in an IEEE 802.11 network are named stations (STAs), whether they are access points or terminal devices. If a STA is configured as an AP and requires one or more features or functions of an AP, it may be described below as a STA-AP or an AP-STA.

[0072] Request and report measurements may be performed using beacons, probe responses, measurement pilots, as well as using other elements. By using a beacon request / report pair, a STA can request a list of APs that can receive its beacons on a specified channel from another STA. The measuring STA then monitors the requested channel, measures beacon, probe response, and measurement pilot power levels, e.g., received channel power indicator (RCPI), and logs some or all beacons, probe responses, and measurement pilots received within the measurement duration. Using a frame request / report pair may give or return a picture of all channel traffic and a count of all frames received at the measuring STA. For each unique transmitter address, the STA may report the transmitter address, the number of frames received from this transmitter, the RCPI for these frames, and the transmitter's basic service set identifier (BSSID). Other information, e.g., any element of the exchanged frames, may be utilized.

[0073] The channel load request / report pair may provide or return channel utilization measurements observed by the measuring STA. The noise histogram request / report pair may provide or return power histogram measurements of non-IEEE 802.11 noise power by sampling the channel when the virtual carrier sense indicates idle and the STA is not transmitting or receiving frames. The STA statistics request / report pair may provide or return groups of STA counter and BSS average access delay values. The STA counter group values ​​may include, among others, transmitted fragment count, group-addressed transmitted frame count, failed count, retry count, multiple retry count, frame duplicate count, request to send (RTS) successful count, RTS failure count, acknowledgment (ACK) failure count, received fragment count, group-addressed received frame count, frame check sequence (FCS) error count, and transmitted frame count. The BSS average access delay group values ​​include the AP average access delay, average access delay per access category, average access delay for one or more frequencies of the AP, associated STA count, available capacity, and channel utilization.

[0074] Location configuration information may be requested and returned. A location request / report pair may give or return the requested location in terms of latitude, longitude, and altitude. Alternatively, the location may be specified using other geographic methods. The location may be specified more precisely, including specifying an altitude type, such as one or more floors of a building. The location may be permitted and specified using various reporting resolutions or granularities. A neighbor report request may be sent to an AP, which returns a neighbor report containing information about known neighbor APs that are candidates for service set transition. A link measurement request / report exchange may provide measurements of the RF characteristics of the link between STAs. This measurement may indicate the instantaneous quality of the link or the quality over a longer period of time. A transmission stream / category measurement is a request / report pair that may allow a QoS STA to query a peer QoS STA about the status of an ongoing traffic stream between the pair.

[0075] Additional measurements may be included and supported. For example, location service measurements may be included. Location configuration request and response frames may enable a STA to configure a set of location-related parameters for a location track notification frame. Co-located interference reporting may enable a requesting STA to obtain information regarding interference due to co-located radios at the reporting STA. The requesting STA may use that information to schedule one or more transmissions to minimize the effects of the interference. Triggered STA statistics reporting capability may enable the generation of a STA statistics report when a statistic of interest reaches a predefined threshold.

[0076] The measurements to be made and the measurement formats may be defined by one or more IEEE 802.11 standards. The RNIS defined by ETSI MEC collects the underlying wireless network conditions and reports them to the MEapp. By utilizing information about the wireless conditions, the MEapp can optimize its behavior to the network; for example, the MEapp can adjust video coding formats, update traffic steering rules, etc. Currently, ETSI MEC defines RNIS only for LTE technology. The expansion of the scope of MEC to include access networks other than LTE requires the definition of RNIS services for ME applications for IEEE 802.11, WLAN access networks.

[0077] Furthermore, LTE technology differs significantly from IEEE 802.11 networks with respect to radio network metrics and measurements. Differences in distance and deployment scenarios, e.g., indoor vs. outdoor, macrocell vs. small cell, etc., affect how measurements and radio metrics can be collected from a WLAN network and how the results are presented or reported to entities such as the MEC RNIS service. The WLAN Radio Information Context requirement is necessary for configuration of the measurement process to account for the diversity present in a WLAN network. Indeed, the IEEE 802.11 standard includes various options for performing measurements. However, the paradigm of configuring MEC service parameters, such as radio measurements and metrics for RNIS, is not considered within the ETSI MEC. LTE radio measurements and metrics are not configurable from the MEC; any and all configuration of metrics occurs outside of the MEC within the 3GPP network. As noted above, this static radio measurement paradigm may not work for WLANs.

[0078] It is expected that all WLAN network providers that are accessible to or by the WTRU may not be from the same entity (vendor, operator, etc.) as the MEC edge service provider. Furthermore, due to the indoor nature of WLAN, various WLAN deployment scenarios are envisioned and even exist in current WLAN networks. Therefore, a southbound interface from the MEC, e.g., MEP or MEC system in general, towards the WLAN radio network may be required, which may depend on the actual deployment scenario. To date, the southbound interface has been considered out of scope by ETSI MEC and has been deferred to 3GPP.

[0079] This specification provides an embodiment for acquiring 802.11 WLAN radio metrics and sending them to an MEC system. The WLAN radio metrics are utilized to send WLAN RNIS toward the MEapp, consistent with the ETSI MEC reference architecture. Southbound interface options are provided to interconnect the MEC through the MEC platform for various WLAN wireless network deployment scenarios to acquire WLAN radio metrics to provide WLAN RNIS to the MEapp. Options are primarily driven by the underlying WLAN network and its configuration.

[0080] WLAN radio metrics and measurements require a level of configuration to address the diverse nature of WLAN deployments. This level of configuration does not exist in 3GPP metrics. IEEE 802.11 has defined a rich measurement framework to both configure and manage WLAN metrics and measurements. Various embodiments, each with their own tradeoffs, can be used for the MEC WLAN RNIS to configure the IEEE 802.11 metric environment.

[0081] In one embodiment, configuration of WLAN measurement and metric parameters is performed by an MEapp; for example, the MEC WLAN RNIS exposes an interface that allows the MEapp to configure the WLAN RNIS service. The concept of an MEC service consumer, which may include an MEapp that configures and adjusts MEC service parameters, can be generalized from RNIS and applied to other services. Some example services may include video analytics, location services, Internet of Things (IoT) applications, augmented or virtual reality, optimized local content delivery, and data caching.

[0082] In a second embodiment, the configuration of WLAN measurements and metric parameters is performed by the MEC system, for example by the MEPM, offloading the complexity of such configuration from the MEapp.

[0083] Note that in one embodiment where the MEPM sets default values ​​for all parameters, a combination of these two options may also be utilized, and the MEapp may update selected parameters if or when necessary.

[0084] Because two or more MEapps may request service from the MEC WLAN RNIS on a single MEC platform or across a set of MEC platforms, mechanisms may be employed to handle conflicts where two MEapps request incompatible measurements or a measurement overload condition occurs in the WLAN network. An overload condition may occur when the WLAN network is overwhelmed with measurements and may not be able to adequately report or provide any meaningful data.

[0085] The ETSI MEC reference architecture defines a REST-based API interface between the MEapp and MEC services, e.g., RNIS. A protocol definition may be adopted that exposes WLAN RNIS to the MEapp. In one embodiment, WLAN RNIS may be presented to the MEapp as a separate, independent service, e.g., with separate interface definitions and service endpoints, from LTE RNIS and other RATs as they become supported. In another embodiment, a single RNIS service may be presented to the MEapp that encapsulates radio network information for all RATs in a single interface and service endpoint.

[0086] In IEEE 802.11 networks, terminals may not be able to gather a complete view of the current wireless domain. A mechanism is needed that allows terminals to obtain information from the MEC about the radio performance that may be achievable in the entire wireless domain, or at least in a larger wireless domain, or a larger portion of the wireless domain than is currently possible.

[0087] A virtual terminal acting as an application in MEC may require real input or feedback from the wireless channel to mimic the current behavior of a physical terminal. This information may be collected from the IEEE 802.11 RNIS and provided to the virtual terminal or virtual app.

[0088] With respect to the following embodiments, no prejudice is made as to which STA is the one performing or making the measurements. The measuring STA may be a STA-AP or a non-AP STA, e.g., a terminal device. There may be many deployment options for MEC WLAN RNIS. The RNIS service may require support by or from the underlying RAT to provide measurements and metrics, regardless of the RAT. For IEEE 802.11, radio measurements are defined in IEEE 802.11k and later included in IEEE 802.11-2016. Some of the measurements 802.11k supports include measurements for roaming decisions, RF channel knowledge, hidden nodes, client statistics, and transmit power control (TCP).

[0089] There are multiple embodiments for deploying IEEE 802.11-based RNIS and interconnecting MEC platforms. Some embodiments may require exposing 802.11 radio information to edge applications and WLAN networks that provide actual 802.11 radio information metrics.

[0090] FIG. 3 is a network diagram presenting three unique options 300, 330, and 360 for one or more exemplary deployments. Each of these deployment options 300, 330, and 360 corresponds to a wireless mode of deployment and has an associated degree of complexity for the interface between the MEC platform and the wireless domain. Note that the IEEE 802.11 RNIS directly involves the AP and STAs as shown. Thus, for some metrics, the AP may be contacted directly and may be responsible for performing measurements, while for some other metrics, the MEC may need to contact a separate STA, which may be an end terminal, and then process the obtained information in a coherent manner. Depending on the deployment option selected, the interface required to reach the end STA may increase in complexity.

[0091] The top option 300 corresponds to a deployment in which the MEC RNIS from an isolated set of APs does not consider any specific infrastructure to coordinate measurements within the IEEE 802.11 network. In this example, the MEC platform 302 has direct access to the WLAN APs 304 and 306 in the network and, therefore, to the STAs 308-314 connected to the APs 304-306. To use the MEC platform 302 in this deployment model, it may be necessary to implement a complex API that allows the MEC application to connect directly to the STAs to perform measurements, collect the results, and then provision all this information to the MEC application or to another MEC service that can process the raw data and derive meaningful information from it. Note that to reach the STAs, the measurement request may first traverse an AP. This deployment model may be used to connect residential WiFi access points to an MEC system provided by an operator or venue owner. As an example, an IEEE 802.11 AP located in or near a user's premises may be considered. The isolated APs 304, 306 may be logically connected to an MEC to provide measurements to the MEC platform 302 of an edge service provider (e.g., an operator, venue owner, or neutral host). This deployment option allows for greater flexibility, but also has a higher degree of complexity compared to others. The MEC platform 302 may interface with an orchestrator 318, and the MEC platform 302 may have at least one ME service 316 running on the platform 302. Both the orchestrator 318 and the MEC platform 316 may have or be coupled to one or more servers 320, 322.

[0092] In a second deployment option 330, the MEC platform may communicate with the MEC RNIS from running on a WiFi controller 334. This option 330 may be used in conjunction with managed IEEE 802.11 infrastructure equipment, such as that found in airports or conference venues. In this case, the IEEE 802.11 network is controlled by a central controller 334 that configures all radio and network parameters of the WLAN network, including associations with users, channels, transmit power, etc. In this case, the MEC platform's connection to the IEEE 802.11 network is performed through interaction with the WiFi controller 334, which may provide a collaborative view of the entire WLAN network. Because direct access to the STAs 336-342 may not be permitted, operation of this model may require the MEC platform to provide a southbound interface specific to the controller. The WiFi controller 334 may have all measurement information directly available at several serving access points, and the MEC platform may need to interact with the corresponding APs 344-346 at the controller. Because the WiFi controller 334 is used to control the APs, this interface may be standardized. This deployment model may lead to lower complexity in the MEC platform, but also less flexibility, as it may only accommodate measurements and other actions that the controller 334 is ready to perform. Note that this option may be one of the most deployed by wireless carriers, as the use of wireless controllers is commonplace in carrier-owned wireless deployments. The MEC platform 332 may interface with the orchestrator 330, and the MEC platform 332 may have at least one ME service 348 running on it. Both the orchestrator 350 and the MEC platform 332 may have or be coupled to one or more servers 352, 354.

[0093] In a third option 360, in combination with the second deployment option 330, the MEP platform 362 can be configured to interface with a measurement daemon or box 364 that oversees performing measurements on one or a set of APs 366, 368 of an isolated WLAN, or via a controller or set of controllers, for example. In this case, a measurement daemon 364 can be deployed that is responsible for coordinating different measurement requests and performing the requested measurements, including generating specific measurement frames or parsing received information. This deployment option 360 simplifies deployment and provides a mechanism by which an existing IEEE 802.11 network can be connected to the MEC platform 362 by deploying a new box / software 364 responsible for performing measurements and reporting the results to the MEC platform 362. This option is a trade-off between the isolated AP option 300 and the WiFi controller option 330. As long as the wireless hardware implements a standard such as IEEE 802.11k, the measurement daemon can be implemented with whatever functionality the MEC platform requires. The STAs 370, 372 may be STAs of the isolated AP 368. The STAs 374, 376 may be STAs of the isolated AP 366. The MEC platform 362 may interface with an orchestrator 378, and the MEC platform 362 may have at least one ME service 380 running on the platform 362. Both the orchestrator 378 and the MEC platform 362 may have or be coupled to one or more servers 382, ​​384.

[0094] Note that we currently assume that the interface between the RNIS service provider and the underlying IEEE 802.11-based network is proprietary and not standardized. Alternatively, there may be a standards-based interface. The diagrams and examples described herein should not be construed as limiting with respect to any standard interface or standards body. The examples disclosed herein may be applicable to future standardized technologies of ETSI MEC, or any other standards body, for that matter.

[0095] In one embodiment, configuration of MEC service parameters may be performed by a service consumer. In one embodiment, configuration of parameters for a service may be performed by a service consumer. Another example may rely on IEEE 802.11 RNIS, which may provide, for example, WLAN wireless information services. However, all of the embodiments and examples may apply to any MEapp and MEC service that requires configuration.

[0096] IEEE 802.11 defines several possible measurements that can be requested of an IEEE 802.11 network to understand the current status and radio conditions of the 802.11 network. The current LTE RNIS defined in ETSI MEC may require configuring several parameters to obtain any meaningful measurement information. Furthermore, LTE RNIS fails to address requests made by a STA or AP and responses sent back to a STA or AP. To obtain the correct information, the MEC application must indicate the metric, the STA (terminal) at which the measurement should be performed, and the moment, e.g., the time instance or time period at which the measurement should be performed.

[0097] The following are mechanisms that can be used to configure the different 802.11 measurements: Parameters can be configured according to one of two options, both options, or any combination of either option, as well as other techniques or implementations.

[0098] FIG. 4 is a message diagram 400 illustrating a service consumer 402, e.g., an MEC app, configuring one or more required parameters of an MEC service 404. The MEC service 404 may be, for example, an RNIS. In a first option, option 1, a configuration API for each measurement may be defined independently, e.g., via AP_INFO_MEASUREMENT_CONF, represented as a PUT message. The parameters are provided as part of a PUT message 406 in a request, as shown in FIG. 4. The PUT message 406 may be sent from the service consumer 402 to the MEC service 404. Options 408 for configuration and corresponding values ​​410 may be specified. As shown, the message is an HTTP PUT message. However, other HTTP messages or, alternatively, other Internet Protocol messages may also be used.

[0099] Parameters or options for configuration 408 may be provided for each separate measurement request when the request is sent or made. Each specific service primitive, either request / response based or subscription based, requires a PUT-based API that can be accessed before requesting the actual service. The API is split over different messages defined in the service, so there is a configuration API for each request / subscription request. Each option for configuration may have an associated value 410.

[0100] As an example of a specific parameter, IEEE 802.11 provides a channel load metric. To perform this measurement, it may be necessary to indicate to the AP the channel to be measured, among other parameters. In this example, before requesting a channel load measurement, the involved application may configure the channel by issuing a PUT command such as "PUT .. / CHANNEL_LOAD_MEASUREMENT_CONF / Channel 1". In response, the service consumer 402 may receive a 200 OK message containing AP_INFO_MEASUREMENT_CONF 412.

[0101] In the second option, option 2, an API for configuration of all measurements may be defined, for example, using 80211_MEASUREMENT_CONFIG. This option includes the use of a specific message to configure the general request parameters for all required configurations or configuration options. This new message may be used to configure all possible characteristics required for a service, and the format for such may be given in Figures 4 and 5.

[0102] Note that the major difference between Option 2 and Option 1 is that in Option 2, there is a specific API for service composition that allows any application to define specific configurations for services under a common API. This common API for composition can include a hierarchy of options of arbitrary complexity, as illustrated in Figure 6.

[0103] Figure 5 is a message diagram 500 illustrating the new message format for measurement configuration. As shown in Figure 5, a service consumer 502 may send a PUT message 506 to an MEC service 504. The PUT message may include options 508 for the configuration and associated values ​​510. In response, the MEC service 504 may send an OK message 512 to the service consumer 502, including 80211_MEASUREMENT_CONFIG.

[0104] 6 is a message diagram 600 illustrating the new message format including sub-options. A service consumer 602 may send an 80211_MEASUREMENT_CONFIG PUT message 608 to an MEC service 604. The PUT message 608 may include an option 610 for configuration with associated sub-options 612 and values ​​614. In response, the MEC service 604 may send an OK message 616 including the 80211_MEASUREMENT_CONFIG to the service consumer 602.

[0105] As an example, consider an application that requests multiple measurements, such as channel load measurements and beacon request measurements, as shown in Table 1. In Table 1, some attributes are described as optional. This is the preferred embodiment, and any absence of optional notation should not be interpreted as mandatory to implement. An application may use the API for configuration of services that issue the following messages:

[0106] "PUT .. / 80211_MEASUREMENT_CONFIG / appID / Channel_Load / ChannelID 1"

[0107] "PUT .. / 80211_MEASUREMENT_CONFIG / appID / Beacon_Request / SSID test_1"

[0108] Table 1 lists exemplary parameters that can be configured.

[0109] [Table 1-1]

[0110] [Table 1-2]

[0111] [Table 1-3]

[0112] [Table 1-4]

[0113] In one embodiment, configuration of parameters through intervention by the MEPM may be employed. Mechanisms for direct configuration of service parameters by applications, e.g., WLAN RNIS configuration by the MEapp, may also be employed or implemented. These mechanisms may require the application, e.g., the MEapp, to configure all parameters for all required service primitives. Service primitives may resemble measurements, but may also represent other non-measurement information. This requirement is a complexity burden that may not be anticipated by applications. In one embodiment, a mechanism may be utilized that allows the MEPM to configure default values ​​for some of the configuration parameters, thus reducing application complexity.

[0114] In a first option, all parameters or a subset of all parameters may be configured by the MEPM to be used as defaults by some or all MEC applications. This may require modifications to the Mm5 interface 738 shown in FIG. 7. The Mm5 reference point may be needed to perform platform configuration, configuration of application rules and requirements, application lifecycle support procedures, management of application relocation, etc. The MEPM 728 is located in the management plane of the MEC platform and may therefore be located in the same infrastructure in which the MEC platform resides or in a different infrastructure, for example, on a different server in the same data center that may be logically connected to the MEC platform by the Mm5. In one embodiment, the MEPM 728 may be located in the MEC platform 704. After successful connection of an IEEE 802.11 network to the MEC platform, the MEPM 728 may configure the required parameters for the service. Default values ​​for the service may be provided by administrator configuration or by any automated process.

[0115] Much like FIG. 2, FIG. 7 illustrates an exemplary ETSI MEC architecture. As shown in FIG. 7, the MEH 702 is an entity that includes the MEP 704 and the virtualization infrastructure 706. The MEP 704 may include a collection of essential functions for running mobile edge applications on the virtualization infrastructure. ME apps 710, 712, and 714 may be instantiated on the virtualization infrastructure 706 of the MEH 702 based on configuration or requests confirmed by the mobile edge management. The MEP 704 may include one or more ME services 708 and a service registry 726, and may provide traffic rule control 718 and DNS processing 716. The ME apps 710, 712, and 714 may be configured to communicate with the MEP 704 via Mp1 reference points 720 and 722. Reference point Mp2 724 may provide an interface between the MEP 704 and the virtualization infrastructure 706. In one embodiment, a reference point may be used to connect one or more functional elements.

[0116] The MEPM 728 may manage the application lifecycle 730 and may provide element management functions 734 to the MEP. The MEPM 728 may also manage application rules and requirements 732. Mobile edge services (ME services) 708 may be hosted on the MEP 704 and may provide various capabilities including communication services, traffic load services, and location services. ME services may also store or provide wireless network information. ME services may be provided natively in the MEP or registered as add-on services by a third party.

[0117] The MEPM 728 may be in communication with the MEP 704 via the Mm5 reference point 736. The MEPM 728 may also be in communication with the virtualization infrastructure manager 738 via the Mm6 reference point 742. The virtualization infrastructure manager 738 may be in communication with the virtualization infrastructure via the Mm7 reference point 740. The Mp3 reference point 744 connects the other mobile edge platforms 746 of the other mobile edge hosts 748 to the MEP.

[0118] The mobile edge orchestrator 750 may communicate with the MEPM 728 via Mm3 752 and with the virtualization infrastructure manager 738 via Mm4 reference point 754. Reference point Mm2 756 may be used to connect operations support systems 758 to the MEPM 728. The operations support systems 758 may interface with the mobile edge orchestrator 750 via reference point Mm1 760. Reference point Mx1 762 may connect the operations support systems 758 to a CFS portal 764. Reference point Mm8 766 may connect the operations support systems 758 to a user application lifecycle management (LCM) proxy 768 coupled to the mobile edge orchestrator 750 via Mm9 770. The user application LCM proxy 768 may interface with the UE applications 772 via Mx2 774.

[0119] In a second option that may incorporate a mix of both MEPM configuration and application intelligence, the MEPM may configure default values ​​and the MEapp may have the option to change them through PUT messages or any other messages. In one embodiment, the MEPM may configure default values ​​and provide the values ​​to the application. The application may respond with further PUT messages.

[0120] In one embodiment, the MEC service manager organizes MEC service requests. For a given MEC service, it is possible that multiple ME applications request the service to perform some action or function, and the service may become overloaded with requests, or the requests may cause contention within the MEC service or in the underlying WLAN RAT. It is also possible that abundant requests for a particular service may cause an overload. As an example, considering an IEEE 802.11 RNIS implementation, it is possible that multiple applications may request multiple measurements simultaneously. If the number of requests is large enough, the wireless medium may become overloaded with measurements and may not be able to generate any communication or provide a meaningful measurement response to the requester. To avoid such a scenario, the MEC service platform may include a means or mechanism for organizing and ordering requests so that the medium is not overloaded.

[0121] FIG. 8 shows a functional diagram 800 illustrating an orchestration function 802. The orchestration function 802 may operate as follows: The orchestration function 802 of an ME service 804 running on a MEP 806 may listen for any or all service requests that require or request access to a RAT 808. When a new request is received from one or more ME apps 810-816, the orchestration function 802 may check whether the new request matches previous requests, e.g., that it can be executed without affecting other requests. If the request can be executed, the orchestration function 802 may find the best way to execute the current set of service requests together. A post-processed request 824 may be output from the orchestration function toward the RAT 808. In the opposite case, the orchestration function 802 may return an error message to one or more ME apps indicating the cause of the failure. One or more consecutive bundles of request / responses are exchanged with the RAT to execute the service and return with the results. The MEP 806 includes a service registry 818 and DNS processing 822. DNS processing 822 may include translating domain names to IP addresses. In one embodiment, DNS processing 822 may employ caching to reduce the time spent translating domain names. Service registry 818 may provide support for lower latency mobile edge services. DNS processing 822 may, for that matter, translate domain names included in PUT requests or any other message format.

[0122] In one embodiment, a protocol is defined for some messages addressed to or from the IEEE 802.11 RNIS. The current ETSI MEC RNIS is based on a request / response or subscription / notification API via REST. The same paradigm can be used to define the IEEE 802.11 RNIS, providing some measurements based on request / response and others based on subscription / notification.

[0123] The APIs can be defined according to two methods for defining RNIS for new technologies: 1. A first exemplary option is to adopt newly defined APIs specified for each wireless technology, which may include separate services and APIs for WLAN and LTE. 2. As a second option, the APIs can extend the current LTE RNIS APIs to include new IEEE 802.11-related parameters. While ETSI MEC defines the service APIs in a REST format, any particular format can be used regardless of the API framework.

[0124] As shown by Table 2, the NetworkInfo, or Network Info message, may provide information about the underlying IEEE 802.11 network from which information may be gathered.

[0125] A new functional primitive may indicate that an MEC application can obtain information about the underlying IEEE 802.11 network. The information may include basic information including the number of different networks characterized by their SSIDs and BSSIDs and their roaming and interconnection capabilities. Through this primitive, an application may learn what IEEE 802.11 infrastructure is connected to and obtain information about the availability of networks for stations accessing the application, for example, whether the stations support the network's roaming agreement and whether they can connect to it.

[0126] [Table 2]

[0127] The combined RAT RNIS network information message is shown in Table 3. The message or message format can be combined with the existing PlmnInfo message defined in the current MEC LTE RNIS specification by including a technology identifier (techId). In one embodiment, a techId specifying either the IEEE or 3GPP format can be used as shown in Table 3. In some embodiments, the techId field is more granular and can specify a particular 3GPP or 802.11 release. For example, 3GPP R8-R16 can be specified. For 802.11, the release can include 802.11ac, 802.11ad, 802.11ax, 802.11ay, etc. The 802.11 release can also be specified in terms of a version number, e.g., Wi-Fi 5, Wi-Fi 6, Wi-Fi 7, etc. Any other release can be specified or indicated by the message.

[0128] New functional primitives may extend the PlmnInfo message, providing the same information as before, but also extending the LTE RNIS. In this way, applications may be able to get a view of the complete set of RATs connected to the MEC platform without having to request network information through multiple APIs or from multiple different devices or technologies.

[0129] [Table 3-1]

[0130] [Table 3-2]

[0131] The APInfo message may correspond to the RabInfo message for LTE RNIS. In one embodiment, a separate message for each IEEE 802.11 AP may provide information about the users, capabilities, and / or capacity of the AP. In the case of IEEE 802.11, it may be preferable to provide some information about the STAs associated with the AP and also about the channel load for different APs. Regarding the channel load, it may be necessary to configure different values ​​for making measurements. In the example given below, the APInfo message provides information about the APs and their associated STAs.

[0132] The new functional primitive can be the basis for any application that provides mobility, local breakout, or traffic steering in general. Through this primitive, an application can obtain a view of the STAs connected to a network and what the current channel load is on the network. This information can be important for understanding the performance achieved by the STAs and the traffic steering options available. Table 4 shows attributes for providing relevant AP information about the associated STAs and channel load.

[0133] [Table 4-1]

[0134] [Table 4-2]

[0135] A new response message can be defined to obtain a beacon request measurement, assuming that the configuration of the parameters required to perform the measurement has already been done.

[0136] Using the new functional primitive, an application can obtain information about what access points are available for handover for a STA. Through this primitive, an application can monitor which APs are relevant handover options for the STA. The application or STA can then make mobility decisions based on the current status of the wireless network to which the STA is connected and the options reported by the APs. Table 5 shows the WLAN RNIS Beacon Request message.

[0137] [Table 5-1]

[0138] [Table 5-2]

[0139] [Table 5-3]

[0140] Subscription messages may be used by the MEC platform in addition to or instead of HTTP type messages. The MEC platform may provide a subscription service whereby applications may request information in the form of notifications of events. A subscription / notification tuple may be defined for use with IEEE 802.11-based APIs.

[0141] The BSSChangeSubscription message may provide information regarding the mobility of an end user associated with an IEEE 802.11 network. New functionality may be implemented in the 802.11 information subscription service. For example, an application may subscribe to STA mobility events to be notified of the STA's location. Location mobility events may include any change in mobility at any instant. Alternatively, mobility events may be periodic in nature and based on a mobility threshold or timer. This exemplary functionality may be required by applications attempting to distribute RAN usage, perform traffic steering, and optimize performance, as handovers may generally degrade STA performance, at least temporarily. Table 6 shows exemplary attributes related to BSS Change Subscription.

[0142] [Table 6-1]

[0143] [Table 6-2]

[0144] [Table 6-3]

[0145] A BSSChangeNotification may provide a reply to a previous BSS Change Subscription message. The following definitions provide an example message format with example attributes:

[0146] [Table 7-1]

[0147] [Table 7-2]

[0148] Table 7 shows the BSS Change Notification attributes. In one embodiment, the BSS Change exchange may be implemented as an extension to the current RNIS by including a new technology identifier in the Cell Change exchange. The technology identifier may indicate whether the technology is an IEEE 802.11-based technology or a 3GPP-based technology. In one embodiment, the technology indicator may indicate 5th generation technology.

[0149] Reporting user mobility in a common way for both LTE and IEEE 802.11 may be of potential interest for applications that consider the aggregation of LTE and IEEE 802.11 technologies. This may reduce the number of API calls required to implement the application. Table 8 shows Point of Attachment (PoA) attributes that may be used by a STA during handover or other PoA changes / configurations.

[0150] [Table 8-1]

[0151] [Table 8-2]

[0152] [Table 8-3]

[0153] In one embodiment, a wireless terminal may request wireless information from an MEC application. IEEE 802.11 provides mechanisms for radio measurement collection that can be used by any STA that belongs to a wireless network. These mechanisms are powerful but may be limited in scope, since the measurements a STA can acquire or perform are limited to its own wireless network. This means that a STA may not be able to acquire information from other STAs or APs that do not form part of its own wireless domain.

[0154] Obtaining more complete radio information of the surrounding network may enable several optimizations and result in performance gains for end-user terminals. In one embodiment, the IEEE 802.11 RNIS defined above may provide STAs with more complete radio information.

[0155] 9 is a network diagram 900 showing three different networks 902-906 that provide information to and receive information from ME services. Network 1 902 consists of two isolated APs 908, 910, each associated with two STAs 912-918. The isolated APs 908-910 may communicate with the MEC platform 966 via interfaces 974, 976. Network 2 904 includes a WiFi controller 920 dedicated to controlling two controlled APs 922, 924, each associated with two STAs 926-932. Like Network 2 904, Network 3 906 also includes a WiFi controller 934 dedicated to controlling two controlled APs 936, 938, each associated with two STAs 940-946. The WiFi controller 920 of network 2 and the WiFi controller 934 of network 3 906 may communicate information to and from the MEC platform 966 and the ME service 950 according to HTTP or using a publish / subscribe paradigm. Other methods may also be used. The WiFi controller 934 of network 3 906, in one embodiment, may receive information collection measurement requests from the ME platform and provide responses to the ME service 950 of the MEC platform 966. The information collection requests and responses may be made via interfaces 960-964. The ME service 950 may interface with the MEC APP 954 via an 802.11 RNIS interface or via a usage technology 972. The MEC APP 954 may provide radio metrics to a STA, for example, directly to STA 918 956. For example, STAs 912-918 of network 1 902 may receive radio metrics without following the direction of a WiFi controller. The ME service 950 may be in communication with an orchestrator 952. The orchestrator 952 and the MEC platform 966 may be configured on different servers 980, 982 or may reside on the same server.

[0156] Each STA in each network may be configured to receive 970 network information about all of the networks. In this way, the MEC platform may be used to provide MEC services to multiple wireless networks. These networks may belong to the same service provider or different providers. The networks may operate on different channels and even different radio access technologies. The MEC platform may include an MEC application (Mapp) that uses IEEE 802.11 RNIS to obtain information about the wireless usage of each of the wireless networks connected to it. This information is obtained by requesting measurements from an AP, a wireless controller, or directly from different terminals. The MEC platform may be controlled by an orchestrator.

[0157] A terminal located in one of the wireless networks served by the MEC platform may use Mapp to obtain a view of the current wireless status. In one example, this information may be important when two access points operate on adjacent, non-orthogonal channels. By measuring the obtained performance and having an understanding of the deployment of the remaining wireless APs, the STA may select a better (or best) network to connect to.

[0158] In one embodiment, a virtual terminal may emulate the wireless conditions of a physical terminal. Currently, there is a trend toward virtualization of user terminals to allow having a clone of a user terminal in the cloud to perform operations without having to terminate communication with a particular user. This may enable or provide new functionality, but may also require an understanding of the wireless performance achievable by the user.

[0159] FIG. 10 shows an example network diagram 1000 illustrating example virtual terminal operation. It can be assumed that an artificial intelligence algorithm is performing some data acquisition or learning from user interactions or applications installed in the end-user terminal. Because this can require a lot of computational power, the application instantiates a virtual version of the terminal in the MEC platform. To understand how the user interacts with the application, the virtual terminal may need to mimic the wireless domain and performance as seen by the end-user terminal. To do this, the virtual terminal application can use IEEE 802.11 RNIS to derive different metrics that can be fed to the virtual terminal to obtain, at least on average, the same behavior as for a real station, i.e., a PHY STA 1010.

[0160] As shown in FIG. 10 , an ME service 1002 may run on an MEC platform 1004. The MEC platform may communicate with an isolated AP 1006 associated with two STAs 1008, 1010. The STA 1010 is a physical STA and may report wireless status to the ME service 1002. A virtual terminal app 1014 may be instantiated to mimic the wireless domain from the perspective of the PHY STA 1010. In this manner, the virtual terminal app may perform functions that may be offloaded by the PHY STA 1010. The PHY STA 1010 may communicate with the virtual terminal app 1014, which is performing functions on behalf of the PHY STA 1010. Communication may occur via use of IEEE 802.11 RNIS 1018. The virtual terminal app 1014 may communicate with the MEC platform 1004 and may communicate with the ME service. An orchestrator 1020 may be configured to run on a server 1022. The MEC platforms may run on the same or different servers 1024.

[0161] FIG. 11 is a block diagram illustrating a video server 1100 employing adaptive forward error correction (FEC). The video server 1100 includes a video / source encoder 1102, a packetization unit 1104, an FEC processing / encoding unit 1106, and an adaptive FEC control unit 1108. The video server 1100 may be, include, or employ an MEapp 1110 that communicates via HTTP 1112 through a network interface 1114. The MEapp 1110 may receive requests for multi-domain network information 1118 and provide responses 1116 via HTTP 1112. The HTTP protocol 1112 may be used to communicate with a MEP or RNIS for exchanging measurement requests / responses. The network information may be provided to the adaptive FEC control unit 1108. The FEC control unit 1108 may determine appropriate video coding parameters and FEC code overhead. The adaptive FEC control unit 1108 may instruct the video / source encoder 1102, the packetization unit 1104, and the FEC processing / encoding unit 1106 to perform video encoding, packetization, and FEC encoding. The adaptive FEC control unit 1108 also communicates with and controls a UDP / IP communication unit employed in accordance with or under HTTP 1112 to transmit video source packets and parity packets.

[0162] FIG. 12 is a block diagram 1200 illustrating receiver components of a WTRU running a WTRU app 1210. The WTRU of FIG. 12 may send one or more requests for multi-domain network information 1202 and receive one or more responses 1204 via a WLAN interface 1206. The messages may be sent using the HTTP 1208 protocol. A depacketization unit 1216, an FEC processing / decoding unit 1214, and a channel estimation and feedback unit 1212 may be employed by the WTRU. The channel estimation and feedback unit 1212 may receive, for example, a raw packet loss rate or any one of the disclosed measurement parameters and provide relevant information to the FEC processing / decoding unit 1214 accordingly. The video server components may be implemented on a single physical WTRU or on multiple WTRUs for a single domain or for multiple domains.

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

Claims

1. sending, by the device, to a wireless local area network (WLAN) information services device, a first message indicating a request to configure a measurement, the first message including information indicating at least one of a random interval or a channel number; receiving, by the device, from the WLAN information service device in response to the first message, an indication of a measurement configuration corresponding to the requested measurement configuration information; sending a beacon request message to the WLAN information service device; receiving a beacon report message from the WLAN information service device in response to the beacon request message; A method comprising:

2. The method of claim 1 , wherein the beacon request message is in accordance with the measurement configuration information.

3. The method of claim 1 , wherein the beacon request message includes an information element indicating a beacon report structure.

4. The method of claim 1 , further comprising receiving information corresponding to other STAs from the WLAN information service device.

5. The method of claim 1 , further comprising receiving, from the WLAN information services device, mobility information regarding an end user associated with an IEEE 802.11 network.

6. The method of claim 1 , further comprising receiving, from the WLAN information service device, information of access points available for handover of a station (STA).

7. The method of claim 1 , wherein the method is performed by a service consumer that includes a Mobile Edge Computing (MEC) Application (APP) (MEC APP).

8. A device, a transmitter configured to transmit, to a wireless local area network (WLAN) information services device, a first message indicating a request to configure a measurement, the first message including information indicating at least one of a random interval or a channel number; a receiver configured to receive, in response to the first message, from the WLAN information service device, an indication of a measurement configuration corresponding to the requested measurement configuration information; the transmitter configured to transmit a beacon request message to the WLAN information service device; the receiver configured to receive a beacon report message from the WLAN information service device in response to the beacon request message; A device comprising:

9. The device of claim 8 , wherein the beacon request message includes an information element indicating a beacon report structure.

10. The device of claim 8 , wherein the beacon request message is in accordance with the measurement configuration information.

11. The device of claim 8 , wherein the measurement configuration information is transmitted within a HyperText Transfer Protocol (HTTP) message.

Images