Systems and methods for monitoring performance in distributed edge computing networks

A computer device may include a memory storing instructions and processor configured to execute the instructions to provide a test configuration to a plurality of multi-access edge computing (MEC) devices; collect test results associated with the provided test configuration from the plurality of MEC devices; and obtain capability information associated with particular ones of the plurality of MEC devices. The computer device may be further configured to generate a test report that relates one or more parameters included in the test results and the obtained capability information to particular ones of the plurality of MEC devices; and use the generated test report to select a MEC device from the plurality of MEC devices for a user equipment (UE) device requesting an application session.

BACKGROUND INFORMATION

In order to satisfy the needs and demands of users of mobile communication devices, providers of wireless communication services continue to improve and expand available services as well as networks used to deliver such services. One enhancement to broadband wireless networks is the use of Multi-access Edge Computing (MEC) architecture. The MEC architecture includes devices, which have previously been implemented in a core network or cloud center, located at the network edge relative to the point of attachment of a wireless communication device to a wireless access network. Server devices in a MEC network enable high computing loads to be offloaded from the core network to the edge and provide various services and applications to wireless communication devices with reduced latency. However, managing a large number of MEC devices poses various challenges.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

A wireless communication device, referred to herein as a user equipment (UE) device, may connect wirelessly to a network via a base station. The base station includes a radio frequency (RF) transceiver and, together with other base stations, may form a radio access network (RAN). The RAN may interface with a core network that enables establishment of an Internet Protocol (IP) connection to other networks, such as the public Internet or a private IP network. When a UE device requests an application session with a server device located in an IP network, the UE device may need to establish an IP connection to the IP network via the core network. Since the server device may be distant to the UE device from a geographic perspective and/or from a network topological perspective, such a connection may traverse a large number of routing devices and/or gateway devices. Thus, the connection between the server device and the UE device may result in large latency values.

To reduce latency and/or other parameters associated with user quality of experience, and to reduce the load of traffic in core networks and gateway devices and to provide more efficient services, a provider of communication services that manages a RAN may deploy a MEC network that includes one or more MEC devices. The MEC devices in the MEC network may provide application services, and/or other types of services, such as Domain Name System (DNS) lookup, to UE devices wirelessly connected to a particular base station. The MEC network may be located in geographic proximity to a base station and close to the base station from a network topology perspective. For example, the MEC network may be closer to the particular base station than to other base stations and may be reached with fewer network device traversals (“hops”) than traffic from other base stations or traffic destined to devices in other packet data networks, such as a cloud computing center located in a core network or private packet data network. When a UE device requests a service that is available via a MEC network, the UE device may be connected to a MEC device in the MEC network, rather than to an application server in the core network or an external packet data network. Different MEC networks may service different sets of base stations. A set of MEC networks distributed in different locations may be referred to as a “distributed edge” or “distributed edge computing.”

However, a MEC device in the closest MEC network with respect to a UE device may not always be the best choice for servicing the UE device. As an example, the UE device may be associated with a request that the local MEC network may not be able to service. For another example, the request may require an application, or a hardware component (e.g., an artificial intelligence (AI) accelerator), that is not available in the local MEC network. As another example, the request may be associated with a latency requirement that the local MEC network cannot meet, because of network loads or processing delays. Therefore, a provider of telecommunication services may need to collect information relating to particular MEC devices in MEC networks servicing UE devices with subscriptions managed by the provider.

Implementations described herein relate to performance monitoring in distributed edge computing. An orchestrator system may provide test configurations to MEC devices. Each MEC device may receive the test configuration from the orchestrator system, perform a test based on the received test configuration, and provide test results based on the performed test to the orchestration system. The MEC device may perform the test by instructing a testing device to send data to the MEC device based on the test configuration.

In some implementations, the testing device may correspond to a UE device communicating with a base station associated with the MEC device. The MEC device may configure the testing device as a UE device by, for example, providing authentication information that enables the testing device to attach to the base station. In other implementations, the testing device may communicate with the MEC device from the RAN, the core network, or another MEC device located in the MEC network or another MEC network.

Furthermore, the orchestrator system may obtain capability information associated with the different MEC devices. The capability information may include, for example, information indicating whether a particular one of the MEC devices includes at least one of a particular type of graphics processing unit (GPU), a particular type of hardware accelerator device, a particular type of virtual device, a particular type of operating system, a particular type of application, and/or other types of capability information. Furthermore, the capability information may include information relating to the capacity of particular hardware elements or devices, such as processor, memory, and/or storage devices, virtual devices, applications, and/or other functionality of a MEC device, information relating to network capacity or bandwidth of a network link associated with the MEC device, and/or other type of capacity information.

The orchestration system may collect test results from the MEC devices and may generate a test report that relates parameters included in the test results and the obtained capability information to particular MEC devices. For example, the test report may relate, for a particular MEC device, particular locations and communication protocols to latency values and/or other parameters, such as bandwidth, throughput, an error rate, and/or a signal quality. The generated test report may then be used to select a MEC device from a set of MEC devices for a UE device requesting a MEC service. For example, the orchestrator system may select a MEC device that satisfies a latency requirement and a capability requirement for the requested MEC service.

Furthermore, the orchestration system may generate a visual representation of the test report and provide the generated visual representation of the test report to an administration device. Moreover, the orchestration system may instruct the MEC device to send an alert when a threshold for a parameter has been approached, reached or exceeded. The MEC device may detect that the threshold has been approached, reached or exceeded and send an alert to the orchestrator system in response. Additionally, or alternatively, the orchestration system may detect that a threshold for a particular parameter has been reached for a MEC device based on the obtained test results and generate an alert in response.

FIG.1is a diagram of an exemplary environment100in which the systems and/or methods, described herein, may be implemented. As shown inFIG.1, environment100may include UE devices110-A to110-X (referred to herein individually as “UE device110” and collectively as “UE devices110”), a radio access network120, MEC networks130, a core network140, and packet data networks150-A to150-N (referred to herein collectively as “packet data networks150” and individually as “packet data network150”).

UE device110may include any device with wireless communication functionality. For example, UE device110may include a handheld wireless communication device (e.g., a mobile phone, a smart phone, a tablet device, etc.); a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch computer device, etc.); a laptop computer, a tablet computer, or another type of portable computer; a desktop computer; a customer premises equipment (CPE) device, such as a set-top box or a digital media player (e.g., Apple TV, Google Chromecast, Amazon Fire TV, etc.), a WiFi access point, a smart television, etc.; a portable gaming system; a global positioning system (GPS) device; a home appliance device; a home monitoring device; and/or any other type of computer device with wireless communication capabilities and a user interface. UE device110may include capabilities for voice communication, mobile broadband services (e.g., video streaming, real-time gaming, premium Internet access etc.), best effort data traffic, and/or other types of applications.

In some implementations, UE device110may communicate using machine-to-machine (M2M) communication, such as machine-type communication (MTC), and/or another type of M2M communication for Internet of Things (IoT) applications. For example, UE device110may include a health monitoring device (e.g., a blood pressure monitoring device, a blood glucose monitoring device, etc.), an asset tracking device (e.g., a system monitoring the geographic location of a fleet of vehicles, etc.), a traffic management device (e.g., a traffic light, traffic camera, road sensor, road illumination light, etc.), a climate controlling device (e.g., a thermostat, a ventilation system, etc.), a device controlling an electronic sign (e.g., an electronic billboard, etc.), a device controlling a manufacturing system (e.g., a robot arm, an assembly line, etc.), a device controlling a security system (e.g., a camera, a motion sensor, a window sensor, etc.), a device controlling a power system (e.g., a smart grid monitoring device, a utility meter, a fault diagnostics device, etc.), a device controlling a financial transaction system (e.g., a point-of-sale terminal, a vending machine, a parking meter, etc.), and/or another type of electronic device.

Radio access network120may enable UE devices110to connect to core network140for mobile telephone service, Short Message Service (SMS) message service, Multimedia Message Service (MMS) message service, Internet access, cloud computing, and/or other types of data services. Radio access network120may include base stations125-A to125-N (referred to herein collectively as “base stations125” and individually as “base station125”). Each base station125may include devices and/or components configured to enable wireless communication with UE devices110located in cells or sectors serviced by base station125. For example, for each cell or sector serviced by the base station, the base station may include a radio frequency (RF) transceiver facing a particular direction. Base station125may include a Fourth Generation (4G) base station configured to communicate with UE devices110as an eNodeB that uses a 4G Long Term Evolution (LTE) air interface. Additionally, or alternatively, base station125may include a Fifth Generation (5G) base station configured to communicate with UE devices110as a gNodeB that uses a 5G New Radio (NR) air interface. A gNodeB may include one or more antenna arrays configured to send and receive wireless signals in the mm-wave frequency range.

Furthermore, radio access network120may include features associated with an LTE Advanced (LTE-A) network and/or a 5G core network or other advanced network, such as management of 5G NR base stations; carrier aggregation; advanced or massive multiple-input and multiple-output (MIMO) configurations (e.g., an 8×8 antenna configuration, a 16×16 antenna configuration, a 256×256 antenna configuration, etc.); cooperative MIMO (CO-MIMO); relay stations; Heterogeneous Networks (HetNets) of overlapping small cells and macrocells; Self-Organizing Network (SON) functionality; MTC functionality, such as 1.4 MHz wide enhanced MTC (eMTC) channels (also referred to as category Cat-M1), Low Power Wide Area (LPWA) technology such as Narrow Band (NB) IoT (NB-IoT) technology, and/or other types of MTC technology; and/or other types of LTE-A and/or 5G functionality.

Each MEC network130may be associated with one or more base stations125and may provide MEC services for UE devices110attached to the one or more base stations125. MEC network130may be in proximity to the one or more base stations125from a geographic and network topology perspective. As an example, MEC network130may be located on a same site as one of the one or more base stations125. As another example, MEC network130may be geographically closer to the one or more base stations125, and reachable via fewer network hops and/or fewer switches, than other base stations125and/or packet data networks150. As yet another example, MEC network130may be reached without having to go through a gateway device, such as a 4G Packet Data Network Gateway (PGW) or a 5G User Plane Function (UPF).

MEC network130may interface with RAN120and/or with core network140via a MEC gateway device (not shown inFIG.1). In some implementations, MEC network130may be connected to RAN120via a direct connection to base station125. For example, in a 4G network, MEC network130may connect to an eNodeB via an S1 interface, or, in a 5G network, MEC network130may connect to a gNodeB via an N3 interface. In other implementations, MEC network130may include, or be included in, core network140. As an example, in a 4G network, MEC network130may connect to a Serving Gateway (SGW) via an S5 interface, or, in a 5G network, MEC network130may connect to a Session Management Function (SMF) via an N4 interface. MEC network130may support UE device110mobility and handover application sessions from a first MEC network130to a second MEC network130when UE device110experiences a handover from a first base station125to a second base station125.

MEC network130may include one or more MEC devices135. MEC network130may support device registration, discovery, and/or management of MEC devices135in MEC network130. MEC device135may include particular hardware capabilities, such as particular CPUs, GPUs, hardware accelerators, and/or other types of hardware capabilities. Furthermore, MEC device135may include particular software capabilities, such as a particular operating system, virtual machine, virtual container, application, and/or another type of software capability.

MEC device135may connect to one or more base stations125in RAN120and provide one or more MEC services to UE devices110connected to the one or more base stations125. As an example, a MEC service may include a service associated with a particular application, such as a content deliver system that provides streaming video on demand, an audio streaming service, a real-time online game, a virtual reality application, a medical or health monitoring application, and/or another type of application with a low latency requirement. As another example, a MEC service may include a cloud computing service, such as cache storage, use of artificial intelligence (AI) accelerators for machine learning computations, use of GPUs for processing of graphic information and/or other types of parallel processing, and/or other types of cloud computing services. As yet another example, a MEC service may include a network service, such as authentication, for example via a certificate authority for a Public Key Infrastructure (PKI) system, a local DNS service, implementation of a virtual network function (VNF), and/or another type of network service. As yet another example, a MEC service may include control of IoT devices, such as hosting an application server for autonomous vehicles, a security system, a manufacturing and/or robotics system, and/or another type of IoT system.

MEC device135may control one or more testing devices to test one or more parameters associated with MEC device135, such as latency, throughput, signal quality, and/or other types of parameters from various locations in the service area of base station125associated with MEC device135. A testing device may include a particular UE device110that sends test data to MEC device135via base station125. Additionally, or alternatively, the testing device may include a device included in base station125or in core network140that communicated with MEC device135using a wired connection and/or a short-range wireless connection (e.g., WiFi, Bluetooth, etc.). MEC device135may obtain test data sent by the testing device, determine one or more parameter values associated with the test data, and provide the determined one or more parameter values to orchestration system145in core network140.

Core network140may manage communication sessions for UE devices110. For example, core network140may establish an IP connection between UE device110and a packet data network150. Furthermore, core network140may enable UE device110to communicate with an application server, and/or another type of device, located in a packet data network150using a communication method that does not require the establishment of an IP connection between UE device110and packet data network150, such as, for example, Data over Non-Access Stratum (DoNAS).

In some implementations, core network140may include an LTE core network (e.g., an evolved packet core (EPC) network). In other implementations, core network140may include a Code Division Multiple Access (CDMA) core network. For example, the CDMA access network may include a CDMA enhanced High Rate Packet Data (eHRPD) network (which may provide access to an LTE core network). An EPC network may include devices that implement network functions that include a Mobility Management Entity (MME) that implements control plane processing, authentication, mobility management, tracking and paging, and activating and deactivating bearers; an SGW that provides an access point to and from UE devices, acts as a local anchor point during handovers, and directs gateway to a PGW; a PGW that functions as a gateway to a particular packet data network150; a Policy and Charging Rules Function (PCRF) that implements policy and charging rules functions, such as establishment of Quality of Service (QoS) requirements, setting allowed bandwidth and/or data throughput limits for particular bearers, and/or other policies; and a Home Subscriber Server (HSS) that stores subscription information for UE devices, including subscription profiles that include authentication and access authorization information, group device memberships, subscription privileges, and/or other types of subscription information.

In other implementations, core network140may include a 5G core network. A 5G core network may include devices that implement network functions that include an Access and Mobility Function (AMF) to perform registration management, connection management, reachability management, mobility management, and/or lawful intercepts; an SMF to perform session management, session modification, session release, IP allocation and management, Dynamic Host Configuration Protocol (DHCP) functions, and selection and control of a UPF; a UPF to serve as a gateway to packet data network150, act as an anchor point, perform packet inspection, routing, and forwarding, perform QoS handling in the user plane, uplink traffic verification, transport level packet marking, downlink packet buffering, and/or other type of user plane functions; an Application Function (AF) to provide services associated with a particular application; a Unified Data Management (UDM) to manage subscription information, handle user identification and authentication, and perform access authorization; a Policy Control Function (PCF) to support policies to control network behavior, provide policy rules to control plane functions, access subscription information relevant to policy decisions, and perform policy decisions; a Charging Function (CHF) to perform charging and billing functions; a Network Repository Function (NRF) to support service discovery, registration of network function instances, and maintain profiles of available network function instances; a Network Exposure Function (NEF) to expose capabilities and events to other network functions, including third party network functions; a Network Slice Selection Function (NSSF) to select a network slice instance to serve a particular UE device110; and/or other types of network functions.

Furthermore, a 5G core network may implement network slicing. Network slicing is a form of virtual network architecture that enables multiple logical networks to be implemented on top of a common shared physical infrastructure using software defined networking (SDN) and/or network function virtualization (NFV). Each logical network, referred to as a “network slice,” may encompass an end-to-end virtual network with dedicated storage and/or computation resources, may be configured to implement a different set of requirements and/or priorities, and/or may be associated with a particular QoS class, type of service, and/or particular enterprise customer associated with a set of UE devices.

The components of core network140may be implemented as dedicated hardware components and/or as virtualized network functions (VNFs) implemented on top of a common shared physical infrastructure using Software Defined Networking (SDN). For example, an SDN controller may implement one or more of the components of core network140using an adapter implementing a VNF virtual machine, a Cloud-Native Network Function (CNF) container, an event driven serverless architecture interface, and/or another type of SDN architecture. The common shared physical infrastructure may be implemented using one or more devices200described below with reference toFIG.2in a cloud computing center associated with core network140. Additionally, or alternatively, some, or all, of the common shared physical infrastructure may be implemented using one or more devices200included in MEC device135.

Core network140may include orchestration system145. Orchestration system145may include one or more computer devices, such as server devices, configured to collect performance information associated with MEC networks130. Orchestration system145may generate a test configuration, send the test configuration to MEC devices135, and collect test results associated with the test configuration and generate a test report based on the collected test results. The test report may be used to generate a dashboard that includes a visual representation of the collected test results for analysis by an administrator. Furthermore, the test report may be used to select a MEC device for a particular session for a particular UE device110. Additionally, orchestrator system145may generate an alert when a threshold for a parameter for a particular MEC device135is reached or exceeded.

Packet data networks150-A to150-N may each include a packet data network. A particular packet data network150may be associated with an Access Point Name (APN) and UE device110may request a connection to the particular packet data network150using the APN. Packet data network150may include, and/or be connected to and enable communication with, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), an optical network, a cable television network, a satellite network, a wireless network (e.g., a CDMA network, a general packet radio service (GPRS) network, and/or an LTE network), an ad hoc network, a telephone network (e.g., the Public Switched Telephone Network (PSTN) or a cellular network), an intranet, or a combination of networks.

AlthoughFIG.1shows exemplary components of environment100, in other implementations, environment100may include fewer components, different components, differently arranged components, or additional components than depicted inFIG.1. Additionally, or alternatively, one or more components of environment100may perform functions described as being performed by one or more other components of environment100.

FIG.2is a diagram illustrating example components of a device200according to an implementation described herein. UE device110, base station125, MEC device135, and/or orchestration system145may each include, or be implemented on, one or more devices200. As shown inFIG.2, device200may include a bus210, a processor220, a memory230, an input device240, an output device250, and a communication interface260.

Bus210may include a path that permits communication among the components of device200. Processor220may include any type of single-core processor, multi-core processor, microprocessor, latch-based processor, central processing unit (CPU), graphics processing unit (GPU), tensor processing unit (TPU), hardware accelerator, and/or processing logic (or families of processors, microprocessors, and/or processing logics) that interprets and executes instructions. In other embodiments, processor220may include an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and/or another type of integrated circuit or processing logic.

Memory230may include any type of dynamic storage device that may store information and/or instructions, for execution by processor220, and/or any type of non-volatile storage device that may store information for use by processor220. For example, memory230may include a random access memory (RAM) or another type of dynamic storage device, a read-only memory (ROM) device or another type of static storage device, a content addressable memory (CAM), a magnetic and/or optical recording memory device and its corresponding drive (e.g., a hard disk drive, optical drive, etc.), and/or a removable form of memory, such as a flash memory.

Input device240may allow an operator to input information into device200. Input device240may include, for example, a keyboard, a mouse, a pen, a microphone, a remote control, an audio capture device, an image and/or video capture device, a touch-screen display, and/or another type of input device. In some embodiments, device200may be managed remotely and may not include input device240. In other words, device200may be “headless” and may not include a keyboard, for example.

Output device250may output information to an operator of device200. Output device250may include a display, a printer, a speaker, and/or another type of output device. For example, device200may include a display, which may include a liquid-crystal display (LCD) for displaying content to the customer. In some embodiments, device200may be managed remotely and may not include output device250. In other words, device200may be “headless” and may not include a display, for example.

Communication interface260may include a transceiver that enables device200to communicate with other devices and/or systems via wireless communications (e.g., radio frequency, infrared, and/or visual optics, etc.), wired communications (e.g., conductive wire, twisted pair cable, coaxial cable, transmission line, fiber optic cable, and/or waveguide, etc.), or a combination of wireless and wired communications. Communication interface260may include a transmitter that converts baseband signals to RF signals and/or a receiver that converts RF signals to baseband signals. Communication interface260may be coupled to an antenna for transmitting and receiving RF signals.

AlthoughFIG.2shows exemplary components of device200, in other implementations, device200may include fewer components, different components, additional components, or differently arranged components than depicted inFIG.2. Additionally, or alternatively, one or more components of device200may perform one or more tasks described as being performed by one or more other components of device200.

FIG.3is a diagram illustrating exemplary components of MEC device135. The components of MEC device135may be implemented, for example, via processor220executing instructions from memory230. Alternatively, some or all of the components of MEC device135may be implemented via hard-wired circuitry. As shown inFIG.3, MEC device135may include an orchestrator interface310, a test devices manager320, a test devices database (DB)325, a data collector330, a test data DB335, an alert generator340, and a thresholds DB345. Furthermore, MEC device135may be in communication with one or more test devices350via, for example, RAN120.

Orchestrator interface310may be configured to communicate with orchestration system145. For example, orchestration interface310may receive instructions from orchestration system145and may provide information, such as test results or alerts, to orchestration system145. Test devices manager320may manage test devices350. Test device350may include UE device110. As an example, with a user's permission, a performance testing application may be installed on UE device110and UE device110may be recruited, during a time period when the user is not using UE device110, send test packets to MEC device135using a particular protocol. As another example, a provider managing MEC network130may send a technician into the field to particular locations with UE device110configured as test device350. As yet another example, UE device110configured as test device350may be installed on an autonomous vehicle or unmanned aerial drone and instructed to send test packets to MEC device135from particular locations. Additionally, or alternatively, test device350may be included in base station125or in core network140and may send test packets to MEC device135via a wired connection or a short-range wireless connection (e.g., WiFi, Bluetooth, etc.).

Test devices DB325may store information relating to test devices350. For example, test devices DB325may store information identifying each test device350, how to reach each test device350, a location of each test device350, and/or other types of information that may be needed to instruct test device350to send test packets to MEC device135using a particular protocol.

Data collector330may collect test data received from test devices350by MEC device135and store the collected test data in test data DB335. Data collector330may send the data stored in test data DB335to orchestrator system145via orchestrator interface310. Alert generator340may generate an alert, and send the alert to orchestrator system145, when a parameter, or a capacity, associated with MEC device135reaches or exceeds a threshold stored in thresholds DB345. As an example, alert generator340may generate an alert when MEC device135detects that packets associated with a particular protocol reach or exceed a latency requirement, a throughput requirement, a signal quality requirement, and/or another type of requirement. As another example, alert generator340may generate an alert when MEC device135detects that that a bandwidth capacity threshold has been reached, a storage capacity threshold has been reached, a processor load capacity has been reached, and/or another type of capacity threshold has been reached.

AlthoughFIG.3shows exemplary components of MEC device135, in other implementations, MEC device135may include fewer components, different components, differently arranged components, or additional components than depicted inFIG.3. Additionally, or alternatively, one or more components of MEC device135may perform functions described as being performed by one or more other components of MEC device135.

FIG.4is a diagram illustrating exemplary components of orchestration system145. The components of orchestration system145may be implemented, for example, via processor220executing instructions from memory230. Alternatively, some or all of the components of orchestration system145may be implemented via hard-wired circuitry. As shown inFIG.4, orchestration system145may include a MEC device interface410, a test configuration generator420, a data collector430, a test report generator440, a test report DB450, a dashboard manager460, an alert generator470, and a MEC selector480.

MEC device interface410may be configured to communicate with MEC device135. For example, MEC device interface410may send instructions to MEC device135and/or may receive test data or alerts from MEC device135. Test configuration generator420may generate a test configuration for a test to be performed by MEC device135using test devices350. For example, an administrator may select a particular parameter to test using a particular protocol. Furthermore, the administrator may select a set of locations within the service range of base station125associated with MEC device135from which the test is to be performed.

Data collector430may collect test data from MEC devices135and provide the collected test data to test report generator440. Test report generator440may generate a test report based on the collected test data and store the generated test report in test report DB450. Exemplary information that may be stored in test report DB450is described below with reference toFIG.5.

Dashboard manager460may manage a dashboard that enables an administrator to view or analyze the generated test report. For example, dashboard manager460may generate a visual representation of the generated test report. The visual representation may be customizable. Alert generator470may generate an alert when a particular parameter associated with a particular MEC device135is reached or exceeded. Alert generator470may generate an alert, and send the alert to dashboard manager460to display the alert, when a parameter, or a capacity, associated with a MEC device135reaches or exceeds a threshold and/or when an alert is received from MEC device135.

MEC selector480may select a particular MEC device135for a session requested by a particular UE device110. For example, a session request, from UE device110requesting a MEC service) may be associated with a particular latency requirement, a particular throughput requirement, a particular capability requirement (e.g., an AI accelerator, a GPU capable of a particular number of parallel processes, a particular application, etc.), and/or another type of service requirement. MEC selector480may access test report DB450and select a MEC device135that is the closest to the UE device110and satisfies the MEC request requirements.

AlthoughFIG.4shows exemplary components of orchestration system145, in other implementations, orchestration system145may include fewer components, different components, differently arranged components, or additional components than depicted inFIG.4. Additionally, or alternatively, one or more components of orchestration system145may perform functions described as being performed by one or more other components of orchestration system145.

FIG.5is a diagram illustrating exemplary information stored in test report DB450according to an implementation described herein. As shown inFIG.5, test report DB450may include one or more MEC device records500. Each MEC device record500may store information relating to a particular MEC device135. MEC records500may be updated by orchestration system145at particular intervals. Each MEC device record500may include a MEC device field510, a capability field520, and one or more location records530.

MEC device field510may store information identifying a particular MEC device135. For example, MEC device field510may store a name of the particular MEC device135, an IP address of the particular MEC device135, a Media Access Control (MAC) address of the particular MEC device135, and/or another type of identifier associated with the particular MEC device135. Capability field520may store information relating to the capabilities of the particular MEC device135, such as, for example, whether the particular MEC device135includes a particular type of CPU, GPU, TPU, hardware accelerator device, virtual device, operating system, application, and/or other types of capability information. Furthermore, the capability information may include capacity information for available network bandwidth, number of connections/sessions available for UE devices110, processors, memory devices, virtual devices, applications, and/or other types of capacity information.

Each location record530may store information associated with a particular location. Location record530may include a location field532and one or more time period records540. Location field532may identify a particular location in the service area of base station125associated with the particular MEC device135. As an example, location field532may store Global Positioning System (GPS) coordinates for the particular location. As another example, location field532may identify a particular area in the service area of base station125.

Each time period record540may store information associated with a particular time period. Time period record540may include a time period field542and one or more protocol records550. Time period field542may identify the particular time period, such as, for example, a time of day, a day of week, a time of year, the most recent time interval during which test data was received (e.g., the last 24 hours, etc.), and/or another time period associated with test results stored in MEC device record500.

Each protocol record550may store information relating to a particular protocol. Protocol record550may include a protocol field552, a latency field554, a throughput field556, and a signal field558. Protocol field552may identify a particular protocol, such as, for example, ICMP, TCP, UDP, RTTP, HTTP, TLS, MQTT, and/or another type of protocol. Latency field554may store one or more latency values measured for the particular protocol from test device350to MEC device135. For example, latency field554may store an OWD value, an RTT value, a bandwidth-delay product value, a packet delay variation value, and/or another type of latency value. Throughput field556may store one or more throughput values measured for the particular protocol from test device350to MEC device135. Signal field558may store one or more signal quality values measured for the particular protocol from test device350to MEC device135, such as, for example, a wireless signal quality value, a jitter value, an error rate value, and/or another type of signal quality value.

AlthoughFIG.5shows exemplary components of test report DB450, in other implementations, test report DB450may include fewer components, different components, additional components, or differently arranged components than depicted inFIG.5.

FIG.6illustrates a flowchart600of a process for testing performance of a Multi-access Edge Computing (MEC) device according to an implementation described herein. In some implementations, the process ofFIG.6may be performed by MEC device135. In other implementations, some or all of the process ofFIG.6may be performed by another device or a group of devices separate from MEC device135.

The process ofFIG.6may include receiving a test configuration from an orchestrator device (block610). For example, orchestrator interface310may receive instructions from orchestrator system145to carry out a performance test to test one or more parameters for a particular protocol from a particular location. A testing device may be configured as a UE device communicating with the MEC device via a RAN (block620), a test may be performed to measure a parameter from the testing device to the MEC device using a particular protocol (block630), and the test results may be reported to the orchestrator device (block640). For example, MEC device135may instruct test device350to send test packets to MEC device135from the particular location using the particular protocol. MEC device135may determine one or more parameters for the received test packets, such as a latency value, a throughput value, a signal quality value, and/or another type of value. MEC device135may then provide the determined parameter values to orchestrator system145.

Thresholds for one or more parameters may be monitored (block650) and an alert to the orchestrator device may be sent if a threshold is reached or exceeded (block660). For example, orchestrator interface310may receive instructions from orchestrator system145to implement an alert if a threshold for a performance parameter or a capacity is reached or exceeded. In response, alert generator340may be configured to implement the alert. For example, alert generator340may generate an alert when MEC device135detects that packets associated with a particular protocol reach or exceed a latency requirement, a throughput requirement, a signal quality requirement, and/or another type of requirement. As another example, alert generator340may generate an alert when MEC device135detects that that a bandwidth capacity threshold has been reached, a storage capacity threshold has been reached, a processor load capacity has been reached, and/or another type of capacity threshold has been reached.

FIG.7illustrates a flowchart700of a process for collecting test information relating to MEC devices according to an implementation described herein. In some implementations, the process ofFIG.7may be performed by orchestration system145. In other implementations, some or all of the process ofFIG.7may be performed by another device or a group of devices separate from orchestration system145.

Some or all of the process ofFIG.7may be repeatedly performed at particular intervals (e.g., every 24 hours, every 12 hours, every 6 hours, etc.). The process ofFIG.7may include providing a test configuration to a set of MEC devices (block710) and test results based on the provided test configuration may be collected from the set of MEC devices (block720). Orchestration system145may send instructions to a set of MEC device135in a set of MEC network130, such as, for example, based on a selected parameter and protocol to be tested from a set of locations within the service range of base stations125associated with particular MEC devices135in the set of MEC devices135. Orchestrator system145may then collect test data from the set of MEC devices135.

Capability information for the set of MEC devices may be obtained (block730). For example, orchestration system145may query MEC devices135for capability and/or capacity information and provide the capability and/or capacity information to test report generator440. A test report may be generated that relates one or more parameters from the test results and the obtained capability information to particular MEC devices from the set of MEC devices (block740). For example, orchestrator system145may generate a test report based on the obtained test results and the obtained capability information.

The generated test report may be used to select MEC devices for UE devices requesting a MEC service (block750). For example, orchestrator system145may receive a request from UE device110, via base station125, or via core network140, for a MEC service. In response, orchestrator system145may determine the requirements associated with the requested MEC service, such as, for example, a latency requirement, a throughput requirement, a capability requirement, and/or another type of service requirement. Orchestrator system145may access test report DB450and select a MEC device135that is the closest to the UE device110and satisfies the MEC request requirements.

Thresholds for MEC devices may be monitored (block760) and an alert may be generated if a threshold for a MEC device is reached or exceeded (block770). For example, orchestrator system145may generate an alert when a particular parameter associated with a particular MEC device135is reached or exceeded, and/or when an alert is received from MEC device135. A visual representation of the test report may be generated (block780). For example, orchestrator system145may generate a visual representation of the generated test report to be viewed by an administrator.

FIG.8illustrates an exemplary signal flow800according to an implementation described herein. As shown inFIG.8, signal flow800may include orchestration system145sending a test configuration to MEC device135(signal810). MEC device135may send test instructions to test device350via base station125based on the received test configuration (signals820and822). In response, test device350may perform the test by sending test packets to MEC device135via base station125(signals824and826). MEC device135may record the test results (block828). MEC device135may then provide the test results to orchestration system145when orchestration system145requests to obtain the test results (signal830). Orchestration system145may then incorporate the test results into a test report.

At a later time, UE device110may request a MEC service via base station125(signals840and842). For example, UE device110may request video content that is stored by MEC device135, to play a game hosted by MEC device135, to use machine language computing performed by an AI accelerator included in MEC device135, to access a DNS server hosted by MEC device135, to use a VNF hosted by MEC device135, to communicate with an IoT server hosted by MEC device135, and/or to request another type of MEC service.

In response, orchestration system145may determine the requirements associated with the requested MEC service and may select a particular MEC device135that is in proximity to UE device110and that satisfies the determined requirements based on information stored in the test report (block844). Orchestration system145may send the MEC device selection to base station125(signal846) and base station125may enable a connection for the MEC service between UE device110and MEC device135(signals850and852).

At a later time, MEC device135may detect that a threshold has been reached for a parameter or a capacity (block860). For example, MEC device135may detect that a latency threshold has been reached, that a data throughput has been reached, that a bandwidth capacity threshold has been reached, that an available capacity for a hardware device has been reached, etc. In response, MEC device135may send an alert to orchestrator system145(signal862). Orchestrator system145may update a test report and/or alert an administrator based on the received alert.

For example, while a series of blocks have been described with respect toFIGS.6and7, and a series of signals with respect toFIG.8, the order of the blocks and/or signals may be modified in other implementations. Further, non-dependent blocks and/or signals may be performed in parallel.

The term “logic,” as used herein, may refer to a combination of one or more processors configured to execute instructions stored in one or more memory devices, may refer to hardwired circuitry, and/or may refer to a combination thereof. Furthermore, a logic may be included in a single device or may be distributed across multiple, and possibly remote, devices.