阅读说明：本技术 用于提供行程特定QoS预测的V2X服务 (V2X service for providing trip specific QoS prediction ) 是由 M·菲利波 D·萨贝拉 于 2020-05-06 设计创作，主要内容包括：所公开的实施例涉及用于在多接入边缘计算(MEC)系统和网络中实现车辆到万物(V2X)通信的技术。V2X系统场景以高移动性和动态拓扑为特征,其中,无线电网络信息、位置信息的准确性和及时性可能受网络基础设施的环境状况和部署密度阻碍。所公开的实施例提供一种用于关于高效、行程特定服务质量(QoS)预测的信息的协作型获取、划分和分发的V2X信息服务(VIS)框架。VIS框架识别V2X系统中收集的无线电状况/质量数据与车辆的计划行程之间的空间/时间相关性,以用于更好地预测沿着所指定的路线的通信网络的无线电状况/质量。因此,VIS可以向所授权的设备包络关于QoS预测的行程特定信息。可以描述和/或要求保护其他实施例。(The disclosed embodiments relate to techniques for implementing vehicle-to-anything (V2X) communications in multiple access edge computing (MEC) systems and networks. The V2X system scenario features high mobility and dynamic topology, where the accuracy and timeliness of radio network information, location information may be hindered by the environmental conditions and deployment density of the network infrastructure. The disclosed embodiments provide a V2X Information Services (VIS) framework for collaborative acquisition, partitioning, and distribution of information regarding efficient, trip-specific quality of service (QoS) prediction. The VIS framework identifies spatial/temporal correlations between the radio condition/quality data collected in the V2X system and the planned trip of the vehicle for better predicting the radio condition/quality of the communication network along the specified route. Thus, the VIS can envelope the authorized devices with trip specific information about QoS predictions. Other embodiments may be described and/or claimed.)

1. An apparatus to be employed as a multi-access edge computing (MEC) master co-sited with a network access infrastructure, the apparatus comprising:

interface circuitry arranged to receive a request message for a predicted quality of service (QoS) for a wireless communication service along a planned route of a vehicle user equipment (vUE), the request message comprising location information (LocationInfo) for each of at least two points along the planned route and a timestamp for each of the at least two points; and

A processor circuit communicatively coupled with the interface circuit, the processor circuit arranged to: in response to receipt of the request message, determining the predicted QoS for the wireless communication service for the vUE along the planned route based on the location for each point and the timestamp.

2. The apparatus of claim 1, wherein the request message further comprises a route data element comprising information related to a potential route of the vUE.

3. The apparatus of claim 2, wherein the route data element comprises a route information (routeInfo) data element for each of the at least two points.

4. The apparatus of claim 3, wherein a forwardmost routeInfo data element included in the route data element corresponds to a start of the planned route and a rearmost routeInfo data element included in the route data element corresponds to an end of the planned route.

5. The apparatus of claim 4, wherein the route data elements further comprise one or more intermediate routeInfo data elements, each of the intermediate routeInfo data elements corresponding to a respective intermediate point between the start point of the planned route and the end point of the planned route.

6. The apparatus of any of claims 3-5, wherein the routeInfo data element for each point comprises a location data element containing the LocationInfo and a time data element containing the timestamp.

7. The apparatus of claim 6, wherein the LocationInfo comprises longitude and latitude coordinates or a global cell identifier of a serving cell to which the vUE is attached, and the timestamp is an estimated time at a location indicated by the LocationInfo.

8. The apparatus of claim 3, wherein the request message further comprises a time granularity data element and a location granularity data element, the time granularity data element comprising a timestamp value indicating a time granularity of accessing a location, and the location granularity data element comprising a string indicating a granularity of accessed location measured in meters by longitude and latitude margins.

9. The apparatus of any one of claims 1-5, wherein:

the processor circuit is arranged to generate a response message comprising a radio measurement for each point along the planned route; and

the interface circuitry is arranged to send the response message to the vUE.

10. The apparatus of claim 9, wherein the response message further comprises another route data element including another routeInfo data element for each of the at least two points, and the routeInfo data element for each point includes a location data element including LocationInfo for a corresponding point of the at least two points, a reference signal received power (rsrp) data element including a predicted rsrp value for the corresponding point, and a reference signal received quality (rsrq) data element including a predicted rsrq value for the corresponding point.

11. The apparatus of claim 10 wherein a first other routeInfo data element included in the other route data element corresponds to a start point of the planned route, a last other routeInfo data element included in the other route data element corresponds to an end point of the planned route, and one or more other intermediate routeInfo data elements included in the other route data element correspond to respective intermediate points between the start point of the planned route and the end point of the planned route.

12. The apparatus of claim 9, wherein the request and the response are communicated through a vehicle-to-everything information service (VIS) Application Programming Interface (API).

13. The apparatus of claim 1 wherein to determine the predicted QoS for the vUE along the planned route, the processor circuitry is arranged to:

identifying a spatio-temporal correlation between radio information collected by one or more other vues and the at least two points along the planned route.

14. The apparatus of claim 1 or 13, wherein to determine the predicted QoS for the wireless communication service for the vUE along the planned route, the processor circuit is arranged to:

requesting information from the MEC information service via the corresponding MEC API;

receiving the requested information from the MEC information service; and

using the received information, predicting a radio signal quality network at each of the at least two points, wherein the MEC information service is a radio network information service, an MEC location service, a subscriber identity service, a bandwidth management service, a wireless local area network access information service, or a fixed access information service.

15. An apparatus to be employed in a vehicle user equipment (vUE), the apparatus comprising:

processor circuitry arranged to generate a request message to request a quality of service (QoS) prediction for vehicle-to-anything (V2X) service along a planned route, the request message comprising a predicted QoS data structure comprising location information (LocationInfo) for each of at least two points along the planned route and a timestamp for each of the at least two points; and

Communication circuitry communicatively coupled with the processor circuitry, the communication circuitry arranged to:

sending the request message to a multiple access edge computing (MEC) host via a V2X Information Service (VIS) Application Programming Interface (API); and

receiving a response message from the MEC host via the VIS API, the response message including another predicted QoS data structure containing predicted QoS for the V2X service for each of the at least two points.

16. The apparatus of claim 1, wherein the predicted QoS data structure comprises a route data element including a route information (routeInfo) data element for a corresponding point of the at least two points, and the routeInfo data element for the corresponding point includes a location data element including LocationInfo for the corresponding point and a time data element including the timestamp for the corresponding point.

17. The apparatus of claim 16, wherein the corresponding point of a forwardmost routeInfo data element included in the route data element is a start point of the planned route and the corresponding point of a rearmost routeInfo data element included in the route data element is an end point of the planned route.

18. The apparatus of claim 17, wherein the timestamp for the starting point is a time at which the vUE accessed the location indicated by the LocationInfo in the most forward routeInfo data element, and the timestamp for the ending point is a predicted time at which the vUE will access the location indicated by the LocationInfo in the most forward routeInfo data element.

19. The apparatus of claim 17 or 18, wherein the way data element further comprises one or more intermediate routeInfo data elements, each of the one or more intermediate routeInfo data elements corresponding to a way point between the start point and the end point.

20. The apparatus of claim 19, wherein the timestamp for at least one waypoint is a time at which the vUE accessed the location indicated by the LocationInfo in the intermediate routeInfo data element corresponding to the at least one waypoint, and the timestamp for a point of another waypoint is a predicted time at which the vUE will access the location indicated by the LocationInfo in the routeInfo data element corresponding to the other waypoint.

21. The apparatus of claim 16, wherein the other predicted QoS data structure comprises another route data element comprising another routeInfo data element for the corresponding point of the at least two points, and the routeInfo data element for the corresponding point comprises:

a location data element including the LocationInfo for the corresponding point,

a time data element comprising the timestamp for the corresponding point,

a reference signal received power (rsrp) data element comprising a predicted rsrp value at a location indicated by the LocationInfo for the corresponding point and during a time of the timestamp in the temporal data element, and

a reference Signal received quality (rsrq) data element comprising a predicted rsrq value at the location indicated by the LocationInfo of the corresponding point and during the time of the timestamp in the temporal data element.

22. One or more computer-readable media (CRM) comprising instructions for obtaining a trip-specific quality of service (QoS) prediction for vehicle-to-anything (V2X) service, wherein execution of the instructions by one or more processors of a vehicle user equipment (vUE) is operable to cause the vUE to:

Sending a request for the trip-specific QoS prediction to a multiple access edge computing (MEC) host via a V2X Information Service (VIS) Application Programming Interface (API), the request indicating a planned route comprising a start point, an end point, and zero or more waypoints between the start point and the end point; and

receiving a response message from the MEC host via the VIS API, the response message including a predicted QoS for V2X service at each of the start point, the end point, and the zero or more waypoints.

23. The one or more CRMs of claim 22, wherein execution of the instructions is operable to cause the vUE to:

at each period of the determined radio information reporting periodicity, collecting radio information comprising one or more radio measurement reports and sending the radio information to the MEC host via the VIS API or another MEC API; and

determining whether to perform data transfer at each of the at least two points based on the predicted QoS for V2X service for each point.

24. One or more computer-readable media (CRM) comprising instructions for providing trip-specific quality of service (QoS) prediction for a network service, wherein execution of the instructions by one or more processors of a multi-access edge computing (MEC) host is operable to cause the MEC host to:

Receive, from a vehicle user equipment (vUE), via a vehicle-to-everything information service (VIS) Application Programming Interface (API), a request for the trip-specific QoS prediction for the network service, the request indicating a planned route for the vUE, the planned route including a start point, an end point, and zero or more waypoints between the start point and the end point;

obtaining radio information from one or more vues and other information from one or more other MEC hosts using a corresponding MEC API;

determining a predicted QoS for a network service at each of the start point, the end point, and the zero or more waypoints based on the radio information and the other information; and

sending a response message to the vUE via the VIS API, the response message including the predicted QoS for network services for the start point, the end point, and the zero or more waypoints.

25. The one or more CRMs of claim 24, wherein the other information is one or more of the following: an RNI obtained from a Radio Network Information (RNI) service, location information obtained from a location service, user identity information obtained from a user identity service, bandwidth management (BWM) information obtained from a BWM service, a WAI obtained from a wireless local area network access information (WAI) service, and a FAI obtained from a Fixed Access Information (FAI) service.

Technical Field

Embodiments described herein relate generally to edge computing, network communications, and communication system implementation, and in particular, to techniques for implementing vehicle-to-anything (V2X) communications in multiple access edge computing (MEC) systems and networks.

Background

Internet of things (IoT) devices are physical or virtual objects that can communicate over a network and can include sensors, actuators, and other input/output components to cause data to be collected or operations to be performed from a real-world environment. For example, IoT devices may include low powered devices that are embedded in or attached to everyday things (e.g., buildings, vehicles, packages, etc.) to provide an additional level of artificial sensory perception of these things. Recently, IoT devices have become more popular, and thus applications using these devices have proliferated. The deployment of IoT devices and multi-access edge computing (MEC) services has introduced several advanced use cases and scenarios that occur at or otherwise involve the edges of the network.

However, these advanced use cases have also introduced several corresponding technical challenges related to security, processing/computing resources, network resources, service availability and efficiency, and the like. With respect to vehicle-to-everything (V2X) services, there currently exists no mechanism for efficiently predicting quality of service (QoS) along a planned trajectory or travel route of a vehicle.

Drawings

In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. Some embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which:

fig. 1A and 1B depict an example V2X communication system utilizing MEC techniques to provide support for V2X applications, in accordance with various embodiments. Fig. 2 depicts an example V2X system including an MEC system architecture, in accordance with various embodiments. Fig. 3 depicts an example architecture of communication between an enabled V2X Information Service (VIS) and V2X control function, in accordance with various embodiments. Fig. 4 depicts an exemplary V2X system scenario in which an MEC host is co-sited with a Network Access Node (NAN) that provides V2X communication services to a vehicle User Equipment (UE), in accordance with various embodiments. Fig. 5 depicts an example trip-specific QoS process, in accordance with various embodiments.

Fig. 7 depicts an example trip-specific QoS notification procedure according to the first embodiment. Fig. 8 depicts another exemplary scenario in which a MEC host is co-sited with a NAN providing V2X communication service, in accordance with various embodiments. Fig. 8 depicts an example hierarchical MEC system including a master MEC host co-sited with a NAN and an on-board MEC host co-sited with a corresponding vUE. Fig. 9 depicts an information collection framework in accordance with various embodiments. Fig. 10 depicts an example QoS notification procedure according to a second embodiment. Fig. 11 depicts an example V2X process, in accordance with various embodiments. Fig. 12 depicts an example resource Uniform Resource Indicator (URI) structure of a VIS API in accordance with various embodiments.

FIG. 13 illustrates an example 5G system architecture that may be deployed in an edge computing system. Fig. 14 illustrates a 5G services-based architecture and MEC architecture that may be deployed in an example edge computing system and an integrated MEC deployment in a 5G network that may be used with the example edge computing system. Fig. 15 illustrates an example MEC system reference architecture. Fig. 16 illustrates a MEC reference architecture in a Network Function Virtualization (NFV) environment that may be deployed from an example edge computing system.

Fig. 17A, 17B, and 17C depict examples of edge computing hardware configurations. Fig. 18 and 19 depict example components of various compute nodes in an edge computing system. Fig. 20 depicts an example mobile computing device in an edge computing system. Fig. 21 depicts an example of a configurable server rack in an edge computing system.

Detailed Description

The following embodiments relate generally to data processing, service management, resource allocation, computing management, network communications, application partitioning, and communication system implementations, and in particular, to techniques and configurations for adapting various edge computing devices and entities to dynamically support multiple entities (e.g., multiple tenants, users, stakeholders, service instances, applications, etc.) in a distributed edge computing environment. In particular, the disclosed embodiments relate to techniques for implementing vehicle-to-anything (V2X) communications in a multiple access edge computing (MEC) system. The V2X system scenario features high mobility and dynamic topology, where the accuracy and timeliness of radio network information, location information may be hindered by the environmental conditions and deployment density of the network infrastructure. The disclosed embodiments provide a V2X Information Service (VIS) framework for collaborative acquisition, partitioning, and distribution of information regarding efficient, trip-specific quality of service (QoS) prediction. The VIS framework identifies spatial/temporal correlations between the radio condition/quality data collected in the V2X system and the planned trip of the vehicle for better predicting the radio condition/quality of the communication network along the specified route. Thus, the VIS can envelope the authorized devices with trip specific information about QoS predictions. Other embodiments may be described and/or claimed. Accurate and timely prediction of the radio environment at various intermediate locations along the planned route/trip may trigger, modify or postpone the enabling/activation of certain V2X functions and/or data transfer between the User Equipment (UE) and the network infrastructure, including Downlink (DL) and Uplink (UL) data transfer. Other embodiments may be described and/or claimed.

MEC V2X Information Service (VIS)

Vehicle-to-everything (V2X) applications (abbreviated as "V2X") include the following four types of communication: vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I); vehicle-to-network (V2N) and vehicle-to-pedestrian communication (V2P). The V2X application may use collaborative awareness to provide more intelligent services to the end user. This means that entities (e.g. vehicle stations or vehicle user equipment (vUE), roadside infrastructure or roadside units (RSU), application servers and pedestrian devices (e.g. smartphones, tablet computers etc.)) gather knowledge of their local environment (e.g. information received from other vehicles or sensor devices in the vicinity) to process and share this knowledge to provide more intelligent services (e.g. cooperative sensing, maneuver coordination etc.) for collision warning systems, autonomous driving etc. V2X applications utilize an underlying access technology or Radio Access Technology (RAT) to communicate messages for cooperative awareness. These RATs may include, for example, IEEE 802.11 p-based protocols (e.g., DSRC and ITS-G5), 3GPP cellular-based protocols (e.g., 5G-V2X and/or LTE-V2X protocols). Although the embodiments herein are discussed in the context of a motor vehicle, the embodiments may also be applied to other types of vehicles including aircraft, watercraft, and the like.

Multiple access edge computing (MEC) is a technique that allows an application to be instantiated at the edge of an access network and provides a low latency and close proximity environment to User Equipment (UE). Thus, vertical industries such as the automotive industry are expected to benefit significantly from deployment of MEC infrastructure in conjunction with deployment of Radio Access Networks (RANs). These RANs may be operated by different MNOs and/or operate different RATs.

Wireless communication is a key enabling technology for collaborative Intelligent Transportation Systems (ITS). Road users (e.g., vehicles, cyclists, and pedestrians) participating in V2X communication may use services provided by different operators that provide different networks and/or use different Radio Access Technologies (RATs). Environments that include networks provided by different operators and that include different RATs are referred to as "multi-vendor, multi-network, and multi-access environments". Examples of multi-vendor, multi-network and multi-access environments are illustrated by fig. 1A and 1B.

Fig. 1A depicts an example V2X communication system utilizing MEC techniques that provide support for V2X applications. In particular, fig. 1A depicts a V2X communication system 100 involving the use of MEC systems, wherein a road operator (or ITS operator) is engaged in offering V2X services in a cross-country, cross-operator, cross-provider environment. The MEC system supports and/or provides various services to an endpoint device (e.g., vehicle ue (vue)101 in fig. 1A), each of which may have different requirements or constraints. For example, some services may have priority or quality of service (QoS) constraints (e.g., traffic data from an autonomous vUE 101 may have a higher priority than infotainment data), reliability and resiliency (e.g., traffic data may require mission critical reliability while infotainment data may allow for some error variation), and power, cooling, and shape number constraints. A UE application (app) uses various interfaces to request the MEC system to run an application (e.g., MEC application) in the MEC system or to move the application in or out of the MEC system. For example, such interfaces include Mp3 reference points for internal MEC management, Mx2 reference points for control communications between MEC platforms, and for external access.

In a typical multi-operator scenario, multiple operators (e.g., MNO-1 and MNO-2 in fig. 1) provide infrastructure (including, for example, a Network Access Node (NAN)110-1 and a core network 150-1 provided by MNO-1 and a NAN 110-2 and a core network 150-2 provided by MNO-2) for enabling network connectivity for a vehicular user equipment (vUE)101 (also referred to as a "vehicle station," "vehicle ITS station," or "V-ITS-S"). An "operator" refers to an entity or organization that owns or controls infrastructure equipment (including radio infrastructure, core network, and/or backhaul infrastructure, etc.) necessary to provide communication and/or network-related services (including radio spectrum allocation (including one or more spectrum licenses from regulatory agencies), billing and subscription-related services, device provisioning, and/or other similar services). Operators provide technical capabilities for accessing a mobile network or wireless environment using over-the-air (OTA) or wireless communication channels. The term "operator" as used herein may be considered synonymous to and/or referred to as a network operator, a Mobile Network Operator (MNO), a cellular network operator, a wireless service provider, a wireless operator, a mobile network operator, a virtual MNO, and the like.

Further, the NANs 110-1 and 110-2 may be macro cell base stations, Remote Radio Heads (RRHs), small and/or micro cell base stations, Access Points (APs), and/or other similar network elements. The APs may be, for example, wireless routers, roadside ITS stations or roadside units, gateway appliances, central hubs, and the like. The base station may be, for example, a 3GPP Long Term Evolution (LTE) evolved node B (eNB), a 3GPP 5G/NR Next Generation node B (gNB), or the like. The set of NANs 110 may be referred to as an "access class edge network" or "access class edge. The NAN 110 may be configured or operable to perform setup of transport resources (e.g., for CDN services and/or other application level services) and scheduling signaling resources for providing network services of the underlying access network/RAT.

In the example of fig. 1A, NAN 110-1 is co-sited with MEC master 140-1, and NAN 110-2 is co-sited with MEC master 140-2. MEC host 140 is an entity that contains the MEC platform and virtualization infrastructure to provide computing, storage, and network resources to MEC applications. The MEC platform is a collection of functions (including hardware and software elements) that run MEC applications on the virtualized infrastructure of 140 of a particular MEC host and enable them to provide and consume MEC services and that may themselves provide several MEC services. The MEC application is an application that may be instantiated within the MEC host 140 within the MEC system 100 and that may potentially provide or consume MEC services, and the MEC service is a service provided by the MEC platform itself or by the MEC application via the MEC platform. MEC host 140 may be provided by MNO-1 and MNO-2, respectively, or MEC host 140 may be provided by a separate edge networking service provider. In this example, vUE 101 at T1 is capable of receiving network connections from MNO-1 via NAN 110-1 and core network 150-1, and is capable of receiving services from remote application server 160 via MNO-1 infrastructure. As the vUE 101 travels, the temporary lack of radio coverage is experienced by the vUE 101 at T2, resulting in a roaming situation, which can then receive service via MNO-2 infrastructure (e.g., NAN 110-2 and core network 150-2). The core network 150 may be, for example, an LTE or 5G/NR core network.

One challenging situation is when an ITS operator attempts to provide the same or continuous V2X service to a vUE 101 connected to different operators (e.g., MNO-1 and MNO-2) even in a temporary lack of radio coverage. This use case is also complicated by the presence of multiple MEC providers, which results in the need to enable communication between different MEC systems. This use case is more complicated when the UE application has relatively high QoS constraints. Further, the allocation of sufficient radio resources within the cell coverage area of the NAN 110 does not necessarily guarantee a certain QoS (or QoS performance) in the V2X communication. Poor QoS performance is also related to poor signal reception due to lack of coverage, signal interference, inefficient switching mechanisms, and insufficient transmission power management and switching mechanisms at the NAN 110.

As shown in fig. 1B, in a conventional V2X system (without VIS services), the interconnection between MNOs (e.g., MNO-1 and MNO-2) is terminated at the far-end side (e.g., far-end application server 160), with the obvious disadvantage of high end-to-end (e2e) latency. On the other hand, with VIS services that enable "horizontal communication" over the interconnect 188 between MEC systems 140, the interconnect between MNOs can be implemented with low e2e latency. The VIS exposes information about the PC5 configuration parameters and information about the Uu interface (e.g., unicast and Multimedia Broadcast Multicast Services (MBMS)) and manages the multi-operator environment, which allows the vUE 101 to leave the coverage area of one MNO-1 and enter the coverage area of another MNO-2 to continue receiving service without any service interruption and to guarantee e2e performance.

V2X applications and services include, for example, security applications/services, convenience applications/services, advanced driving assistance applications/services, and Vulnerable Road User (VRU) applications/services, among others. Examples of security applications/services include Intersection Mobile Assistance (IMA) and Queue Warnings (QW). IMA is designed to avoid intersection crossing collisions by alerting drivers to vehicles approaching laterally at an intersection. Intersection collisions include intersection, intersection related, roadway/alley, and roadway access related collisions. The QW queues of vehicles on the road may pose potential hazards and cause delays in traffic (e.g., when the turn queues extend to other lanes). Using V2X services, queue information may be made available to other vues 101 in advance, which minimizes the likelihood of collisions and allows for mitigation actions.

The convenience applications/services include, for example, remote information processing (telematics), software updates, infotainment, and the like. Some of these applications/services may be implemented with existing access technologies and are already supported in part by some automotive manufacturers. This V2X group use case needs to enable cost-effective communication between the vUE 101 and backend servers/services.

Advanced driving assistance applications/services (also referred to as "advanced driving assistance systems" or "ADAS") are electronic systems (including hardware and software elements) that assist the vehicle driver while driving or parking the vehicle, and typically employ various microcontrollers, Electronic Control Units (ECUs), sensors, and/or power semiconductor devices/systems (collectively referred to herein as "drive control units" or "DCUs") implemented in the vehicle to gather the most challenging requirements for V2X. These applications/services are also applicable to autonomous driving applications/services. These V2X applications/services may require relatively large amounts of data to be distributed in parallel with high reliability and low latency, and generally benefit from predictive reliability. This means that vUE 101 utilizing ADAS should have the possibility to receive predictions of network availability and/or QoS to plan ahead. Real-time situational awareness is crucial for autonomous driving automobiles, especially at critical road segments in the case of changing road conditions (e.g., new objects/obstacles detected by another vehicle before a certain time, changing weather and/or environmental conditions, etc.). For this and other purposes, there is a need to make available the relevant high definition (local) maps via download from a back-end server/service (e.g., remote application server 160). The use cases with respect to real-time situational awareness and high-definition (local) maps should not only be seen as cases where information about relatively slowly changing road conditions is distributed. This situation should be extended to the real-time distribution and aggregation of locally available information to the traffic participants via roadside units. Another ADAS application/service is insights (or high definition sensor sharing). In this type of use case, vehicles in a fleet (e.g., trucks, minivans, automobiles, etc.) need to share sensor data (e.g., images/video) of road conditions ahead of them to vehicles behind them.

Additionally, the ADAS and/or autopilot applications/services may involve the use of Artificial Intelligence (AI) agents and/or Machine Learning (ML) models operable to observe environmental conditions and determine actions to be taken in the propulsion of a particular target. The particular environmental conditions to be observed and the actions to be taken may be based on an Operational Design Domain (ODD). The ODD includes the operating conditions under which a given AI agent/ML model or features thereof are specifically designed to operate. The ODD may include operational limitations (e.g., environmental, geographic, and time-of-day limitations, and/or the necessary presence or absence of particular traffic or road characteristics). In embodiments, the individual AI agents and/or the trained ML models/algorithms may be configured or operable to control the respective control systems/DCUs of the host vUE 101. In these embodiments, the actions to be taken and the specific goals to be achieved may be specific or personalized based on the control system itself and/or the DCU involved. Additionally, depending on the particular context in which the AI agent and/or the trained ML model/algorithm are implemented, some actions or goals may be Dynamic Driving Tasks (DDTs), Object and Event Detection and Response (OEDR) tasks, or other non-vehicle operation related tasks. The DDT includes all real-time operational and tactical functions required to operate the vUE 101 in road traffic, excluding strategic functions (e.g., trip scheduling and selection of endpoints and waypoints). DDTs include, for example, the following tactical and operational tasks: lateral vehicle motion control via steering (operability); longitudinal vehicle motion control (operability) via acceleration and deceleration; monitoring the driving environment (operational and tactical) via object and event detection, identification, classification and response preparation; object and event response execution (operational and tactical); maneuver planning (tactical); and enhancement of conspicuity (tacticity) via lighting, signaling, gesturing, and the like. The OEDR task may be a subtask of DDT, which includes: monitoring the driving environment (e.g., detecting, identifying and classifying objects and events, and preparing to respond as needed), and performing appropriate responses to such objects and events, for example, as needed to complete a DDT or fallback task. Some of these features may be triggered by the involved AI agent/ML models, or may be triggered by external entities (e.g., remote application server 160 and/or MEC host 140). The events/triggers may be AI agent/ML model specific and may vary depending on the particular embodiment.

The VRU is a non-motorized road user as well as a user of the VRU vehicle. A "VRU device" refers to a portable device (e.g., a smartphone, tablet, wearable device, etc.) used by a VRU of an integrated standard ITS station, although the term "VRU" may itself refer to both VRU and VRU devices. The VRU-related V2X applications/services utilize information provided by the VRU for purposes of traffic safety (e.g., collision avoidance, etc.). These applications/services often require a high accuracy of the positioning information provided by these traffic participants. Additional means for using the available information with better and reliable accuracy is crucial to allow real world use of the information shared from the VRU. The cooperation between vehicles and VRUs through their VRU devices is an important key element for improving traffic safety and avoiding accidents.

For these V2X applications/services, the MEC system 100 (or MEC host 140) provides feedback information from the network to the vUE 101 (e.g., in view of latency requirements, packet arrival rates, QoS for data services/connectivity, etc.) that predicts whether the communication channel is currently reliable to support V2X functions/applications/services. MEC system 100 also provides interoperability by: support exchange of V2X information between vues 101 and/or other road users (e.g., VRUs, etc.) connected through different station/device types/platforms, access technologies, networks, or MNOs, and enable multi-operator operation for V2X applications/services and/or individual vues 101 to provide service continuity across national access network coverage areas and across boundaries of different MNO networks. MEC system 100 (or a separate MEC master 140) may need to provide timely accurate positioning and/or predictive quality-related information to the vehicle assisted by available positioning technology including radio network functionality when various connectivity parameters (e.g., latency, PER, signal strength, etc.) will change.

The MEC includes a V2X Information Service (VIS) Application Programming Interface (API) designed to facilitate V2X interoperability in a multi-vendor, multi-network, and multi-access environment for automotive use cases. These use cases may involve different vehicle manufacturers, Original Equipment Manufacturer (OEM) providers, network infrastructure providers, MEC providers, application/content providers, and other stakeholders.

An MNO is typically region-specific or country-specific, and interworking between networks using the MNO provides services directly to its own customers (subscribers) while providing communications to other MNO's customers at the core network level. Each MNO operates its own Public Land Mobile Network (PLMN), which is generally referred to as home PLMN (hplmn) from the perspective of subscribers to a particular MNO, or visited PLMN (vplmn) from the perspective of users who are not subscribers to a particular MNO. For vehicular applications, it becomes challenging to maintain V2X service continuity (generally with low latency requirements) for road users, especially when these road users move from the coverage area of one MNO to the coverage area of another MNO.

Mobile network-level interworking between different PLMNs is used to enable service continuity in such use cases specified in 3GPP specifications (e.g., ETSI GS MEC 003v2.1.1(2019-01) ("[ R05 ]"), ETSI GS MEC 011V1.1.1(2017-07) ("[ R08 ]"), ETSI GS MEC 013v1.1 (2017-07) ("[ R10 ]"), ETSI GS MEC 014V1.1.1(2018-02) ("[ R11 ]") and ETSI GS MEC 015V1.1.1(2017-10) ("[ R12 ]")). Furthermore, inter-system coordination across MECs is also needed to prepare the transitioning UE (e.g., based on agreements between MNOs, roaming, and/or handover to a new PLMN) and reduce outage time.

Service customers communicate with the VIS 280 through the V2X API to obtain the necessary V2X service provisioning information for the visited PLMN to support inter-PLMN service continuity. Both MEC applications (apps) and MEC platforms may consume VIS 280; and both the MEC platform and MEC application may be providers of V2X information. The V2X API may also be referred to as a "VIS API" or the like. The MEC application and MEC platform will be discussed in more detail below with respect to fig. 14, 15, and 16.

Fig. 2 illustrates an example V2X system 200 including an MEC system architecture, in accordance with various embodiments. The MEC system architecture includes each of a plurality of MEC hosts 240 (including MEC host 240-1 and MEC host 240-2), each of which may correspond to MEC host 1502 in MEC system 1500 of fig. 15. As previously described, MECs provide cloud computing functionality and IT service environments for application developers and content providers at the edge of a network. This environment is characterized by ultra-low latency and high bandwidth and real-time access to radio network information that can be leveraged by applications. MEC technology allows flexible, fast deployment of innovative applications and services towards mobile subscribers, enterprises and vertically subdivided markets. In particular, with respect to the automotive field, applications (e.g., V2X applications) require exchanging data, providing data to aggregation points, and accessing data in a database that provides a local situation overview (by various automobiles, roadside units, etc.) derived from a multitude of sensors.

V2X system 200 involves the use of multiple MEC hosts 240 (including MEC host 240-1 and MEC host 240-2) and MEC VIS 280. The vUE 201, NAN 210 (including NAN 210-1 and NAN 210-2), MEC host 240, and remote cloud 260 may correspond to the vUE 101, NAN 110, and MEC host 140 of fig. 1A and 1B, respectively. Each of the MEC host 240 and NAN 210 pairs may constitute a respective edge cloud, and the remote cloud 260 may include one or more remote application servers (e.g., the remote application servers 160 of fig. 1A and 1B).

In various embodiments, MEC system 200 (and individual MEC hosts 240) may support feature V2X services. When MEC system 200 supports the feature V2XService, MEC system 200 includes the ability to provide feedback information from a network (e.g., MNO network in fig. 1 a-1 b and/or edge cloud in fig. 2) to vUE 201 to support the V2X function, which facilitates predicting whether a communication channel is currently reliable (e.g., in view of meeting latency requirements and/or threshold packet arrivals). The MEC system 200 supporting the V2X service includes the ability to provide quality-related information from the network to the vehicle regarding when various connectivity parameters (e.g., latency, PER, signal strength, etc.) will change. The MEC system 200 supporting V2X services includes the capability to provide interoperability by supporting the exchange of V2X information between road users connected through different access technologies, networks, and/or MNOs. The MEC system 200 supporting V2X services enables multi-operator operation for V2X stations/equipment to provide service continuity across national access network coverage and across the boundaries of different operators' networks. The MEC system 200 supporting V2X services includes the capability to provide interoperability in a multi-operator scenario, enabling MEC applications in different systems to securely communicate with each other to enable synchronization in the multi-operator system also in the absence of cellular coverage (outside of the 3GPP domain). The MEC system 200 supporting V2X services includes the capability to provide interoperability in a multi-operator scenario, enabling MEC applications to securely communicate with V2X related 3GPP core network logical functions (e.g., V2X control function 350 and/or other core network functions of fig. 3), and collecting PC 5V 2X related information (e.g., PC5 configuration parameters) from the 3GPP network.

In the framework of V2X services, vUE 201 is hosting a client application (UE application 202 in fig. 2) and is connected to a particular MEC host 240 (and related MEC applications 228). In the presence of multiple MEC hosts 240, the VIS 280 allows for opening information between MEC applications 228 running on different MEC hosts 240. Each of the MEC hosts 240 may be owned/managed by a different operator or service provider (e.g., MEC vendor or third party). MEC applications 228 instantiated on MEC host 240-1 and MEC host 240-2 may be used to provide V2X-related services and may be operated by a mobile service operator, an MEC provider, or a third party (e.g., an OEM, or OEM provider, or system integrator). Further, other remote application server instances may be located elsewhere (e.g., in remote cloud 260). Remote cloud 260 may be any type of cloud infrastructure (e.g., one or more private clouds owned by an operator or OEM). The remote cloud 260 also operates one or more remote applications 265. The VIS 280 may be generated by the MEC platform 230 or by the MEC application 228.

In some aspects, MEC platform 230 (corresponding to MEC platform 1532 and/or MEC platform VNF 1602 of fig. 16) may include a MEC V2X API that provides MEC VIS 280. The VIS 280/V2X API supports queries and subscriptions (e.g., pub/sub mechanisms) used by the representation state transition ("REST" or "RESTful") API or by alternative transports (e.g., message buses). For the RESTful architecture style, HTTP protocol bindings may be defined for the VIS API. In particular, the VIS 280 allows information relating to support of vehicle usage to be exposed to MEC application instances. The VIS 280 also allows a single ITS operator to offer V2X applications/services throughout an area that may span different countries and involve multiple network operators, MEC systems, and MEC application providers. To this end, the VIS 280 may include the following functions: (a) collecting PC 5V 2X related information from the 3GPP network with the purpose of performing UE authorization for V2X communication (e.g., obtaining a list of V2X authorized UEs, obtaining related information about authorization based on UE subscription, and obtaining V2X configuration parameters (e.g., a common V2X configuration parameter set, which may include PC5 configuration parameters)); (b) opening the information obtained in (a) to the MEC application 228 in the same MEC host 240 or to the MEC application 228 in other MEC hosts 240; (c) enabling MEC applications 228 to securely communicate with V2X related 3GPP core network logical functions (e.g., enabling communication between MEC host 240 and V2X control functions in the core network); (d) enabling MEC applications 228 in different MEC systems 240 to securely communicate with each other; and (e) collect and process information available in other MEC hosts/systems using appropriate MEC APIs (e.g., collect and process information obtained via V2X (VIS) APIs, Radio Network Information (RNI) APIs (see, e.g., ETSI GS MEC 012V1.1.1(2017-07) ("[ R09 ]"), location APIs [ R10], UE identity (UE _ ID) APIs [ R11], bandwidth management (BWM) APIs [ R12], WLAN Access Information (WAI) APIs, Fixed Access Information (FAI) API ETSI GS MEC 029v2.1.1(2019-07) ("[ R13 ]") and other similar APIs) for accessing information that may implement other MEC services 236 within MEC platform 230 to predict radio network congestion and provide appropriate notifications to UEs 201. Service registration 238, filter rules control 231, DNS processing 232, data plane 224, and virtualization infrastructure 222 will be discussed in more detail below with respect to fig. 15 and 16.

From this perspective, VIS 280 is related to Mp1 and Mp3 reference points in the MEC architecture (see, e.g., fig. 14, 15, and 16). In particular, relevant information is exposed to the MEC application 228 from various services 228 and 236 via the Mp1 reference point. The Mp3 reference point enables the transfer of this information between different MEC platforms 230. For example, second MEC host 240-2 may also implement a MEC V2X API that may provide an interface 240-2 to one or more of the instantiated MEC applications 228 within the MEC host. Here, MEC host 240-2 and MEC host 240-1 may communicate with each other via the Mp3 interface and the MEC V2X API. Additionally, an instantiated application 228 within MEC host 240-1 may communicate with one or more of instantiated MEC applications 228 within MEC host 240-2 via a MEC V2X API and an interface between MEC host 240-1 and MEC host 240-2.

MEC VIS API provide information to the MEC application 228 in a standardized manner, thus providing interoperability in a multi-vendor scenario. However, the MEC application 228 may communicate in a direct manner (e.g., without using the MEC platform 230). In some embodiments, inter-system communication may be implemented between MEC organizers (MEOs). Additionally or alternatively, possible Mp3 enhancements (or new reference points between MEC systems 240) may be defined for MEC application 228 communications.

The MEC V2X API (e.g., for opening VIS 280) may be provided as a generic middleware service, provide information gathered from vehicle 201 and other V2X elements, and open as a service within the host (e.g., as a RESTful API) for higher layers (e.g., as an instantiated MEC application 228 within the host). In some aspects, the MEC V2X API may be configured to collect information and data from various sensors. Here, the deployment of the MEC V2X API ensures continuity of service across different mobile networks for the same OEM (e.g., automotive manufacturer). If a standard implementation of the V2X API is introduced (e.g., by ETSI MEC), this functionality may ensure the same basic V2X service characteristics for all OEMs in a 5G communication system with MEC functionality.

The VIS API/V2X API includes resources and operations. A "resource" is an object having a type, associated data, a set of methods to operate on, and relationships to other resources (if applicable). Resources are a basic concept in the RESTful API. The resource is acted upon by the RESTful API using HTTP methods (e.g., POST, GET, PUT, DELETE, etc.). The operation on the resource affects the state of the corresponding managed entity. Some of the processes/operations of the VIS API are depicted by fig. 11. Fig. 12 illustrates a resource Uniform Resource Indicator (URI) structure of a VIS API in accordance with various embodiments. Table 7.2-1 provides an overview of the resources defined by the VIS API and applicable HTTP methods. The VIS API supports additional application-related error information to be provided in the HTTP response when an error occurs (see, e.g., clause 6.15 of ETSI GS MEC 009V2.1.1(2019-01) ("[ R06 ]").

Table 7.2-1: example VIS API resources and methods

The syntax for each resource URI follows [ R06], and IETF RFC 3986(2005-01) or IETF RFC 7320 (2014-07). In the RESTful MEC service API, which includes the VIS API, the resource URI structure for each API has the following structure:

{apiRoot}/{apiName}/{apiVersion}/{apiSpecificSuffixes}

here, "apiRoot" includes schema ("https"), host and optional port, and optional prefix string. "apiName" defines the name of an API (e.g., VIS/V2X API, RNI API, etc.). "apiVersion" represents the version of the API, and "apispecificsuffies" defines a tree of resource URIs in a particular API. The combination of "apiRoot", "apiName", and "apiVersion" is referred to as the root URI. The "apiRoot" is under the control of the deployment, while the rest of the URI is under the control of the API specification. In the above root, "apiRoot" and "apiName" are discovered using service registry 238. It includes a schema ("http" or "https"), host and optional ports, and optional prefix strings. For the VIS API, "apiName" may be set to "VIS" and "apiVersion" may be set to an appropriate version number (e.g., "v 1" for version 1). The MEC API supports TLS-based HTTP (also referred to as HTTPs). All resource URIs in the VIS procedure are defined with respect to the root URI described above (see e.g. fig. 11).

JSON content formats may also be supported. The JSON format is signaled by the content type "application/JSON". The VIS API may use an OAuth 2.0 client credential approval type with a bearer token (see e.g. [ R06 ]). Token endpoints may be discovered as part of the service availability query process defined in [ R08 ]. The client credentials may be provisioned into the MEC application using known provisioning mechanisms.

In some embodiments, MEC applications 228 in their respective MEC hosts 240 may use the corresponding MEC V2X API to retrieve information from the 3GPP network. In some embodiments, MEC applications 228 in their respective MEC hosts 240 may be configured to host V2X configuration parameters (e.g., PC5 configuration parameters (or a common set of V2X configuration parameters that may be available within a multi-PLMN communication environment.) the availability of these V2X configuration parameters, also when network coverage is missing, is ensured through the use of an Mp3 interface (or another type of interface) between hosts in some aspects MEC application 228 in MEC host 240-1 may be configured to connect to MEC host 240-2 (through a V2X MEC API in MEC host 240-2) and MEC application 228 in MEC host 240-2 may be configured to connect to MEC host 240-1 (through a V2X MEC API in MEC host 240-1.) in the case of a multi-carrier architecture, multiple MEC hosts 240 may be configured to communicate with each other via MEC V2X and synchronize 2X configuration parameters, such that they may be available across multi-operator architectures when cellular coverage is missing (e.g., outside of the 3GPP domain). In this way, a UE (e.g., vUE 201) may have access to V2X configuration parameters even when the UE is not under coverage of its 3GPP network.

In some embodiments, one or more MEC applications 228 within MEC host 240 may be instantiated to perform the functions of the V2X application functions, which may include: the VIS 280 is provided. Additionally, MEC host 240 may use MEC V2X APIs to perform various V2X or VIS 280 functions. In particular, one or more MEC applications 228 may be instantiated within MEC host 240 to perform functions associated with V2X application functions, as shown in fig. 3. These MEC applications 228 may be configured to perform one or more of the following V2X application functions: obtaining V2X subscription information for vUE 201; determining whether the vUE 201 is authorized to perform V2X communications in response to a request for V2X service; passing V2X configuration parameters (e.g., a common set of V2X configuration parameters); and the like.

Fig. 3 illustrates an example architecture 300 that enables communication between a VIS (e.g., VIS 280 of fig. 2) and a V2X control function 350. In this example, the VIS is deployed in MEC platform 322 of MEC host 340-1 and/or MEC host 340-2. In a 3GPP network, V2X applications may be deployed on one or more V2X application servers (V2X AS) 328. In 3GPP-V2X, there are two modes of operation for V2X communication, namely over the PC5 interface and over the LTE/5G Uu interface. The Uu interface may be unicast and/or MBMS. These two modes of operation may be used independently by UEs (e.g., vues 101 and 201 in fig. 1A, 1B, and 2) for transmission and reception. For example, the UE may use MBMS for reception without using the Uu interface for transmission. The UE may also receive the V2X message via the Uu interface unicast DL.

V2X AS 328 may receive UL data from one or more UEs through unicast and deliver the data to the UEs in the target area using unicast delivery and/or MBMS delivery. V2X AS 328 may map from the geographical location information to the appropriate target MBMS SAI for broadcast, from the geographical location information to the appropriate target 3GPP identity (e.g., E-UTRAN cell global identifier (ECGI) and/or NR Cell Global Identifier (NCGI) for broadcast); and mapping the ECGI/NCGI provided from the UE to an appropriate target MBMS Service Area Identifier (SAI) for broadcasting. The V2X AS 328 may also provide the appropriate ECGI/NCGI and/or MBMS SAI to a broadcast multicast service center (BM-SC) for scheduling and transmission of broadcast/multicast content, charging, service announcement, security, and content synchronization.

The V2X control function 350 is a Network Function (NF) in the core network for the network-related actions required by the V2X. The V2X control function 350 is to provide the necessary parameters to the UEs (e.g., vues 101 and 201) to communicate using V2X (e.g., PLMN specific parameters that allow the UE to use V2X in a specific PLMN). The V2X control function 350 is also used to provide the UE with the parameters needed when the UE is "out of E-UTRAN service" or "out of NG-RAN service". The V2X control function 350 may also be used to obtain a V2X USD for the UE to receive MBMS-based V2X traffic from the V2X AS 328 via the V2 reference point. The V2X control function 350 may also obtain parameters required for V2X communications from the V2X AS 328 over the PC5 reference point via the V2 reference point. The V2 reference point is the reference point between the V2X AS 328 and the V2X control function 350 in the operator's network.

The V2X control function 350 of the HPLMN is discovered through interaction with a Domain Name Service (DNS) function. The Fully Qualified Domain Name (FQDN) of the V2X control function 350 in the HPLMN may be pre-configured in the UE, provided by the network, or self-constructed by the UE (e.g., derived from the PLMN ID of the HPLMN, etc.). The IP address of the V2X control function 350 in the HPLMN may also be provided in or to the UE. A Home Subscriber Server (HSS) in an LTE core network and/or a Unified Data Management (UDM) NF in a 5G core network (5GC) provides a list of PLMNs in which UEs (e.g., vues 101 and 201 of fig. 1A, 1B, and 2) are authorized to perform V2X communications to a V2X control function 350 over a PC5 reference point (see, e.g., 3GPP TS 23.285v16.0.0(2019-03-25) and ETSI TS 123285 V14.2.0(2017-05) (collectively "[ R04 ]").

In some implementations, the V2X AS 328 (or V2X AS logic) may be co-sited with the RSU. The VIS 280 defined in the MEC is used to facilitate V2X interoperability in multi-vendor, multi-network and multi-access environments. VIS 280 or a generic part thereof may be deployed in MEC platform 330 (filter rules control 331, DNS process 332, and service registration 338 may correspond to filter rules control 231, DNS process 232, and service registration 238, respectively, of fig. 2). Thus, the VIS 280 may be used to obtain subscription data of the UE from the V2X control function 350 (e.g., PC5 based V2X communication allows PLMN). Because V2X AS 328 carries (or services) multiple V2X applications, it may be deployed AS one or more MEC applications 228 in MEC platform 330 (see, e.g., fig. 2). The VIS 280 may communicate with the V2X AS 328 over the Mp1 interface, and it may obtain the V2X subscription data of the UE from the V2X control function 350 over the V2X AS 328. In some embodiments, the V2 and Mp1 reference points may be enhanced to support secure transfer of subscription data between the V2X control function 350 and the VIS 280. Furthermore, the current 3GPP specifications do not define an interface between two or more V2X ASs 328 or a method for message exchange between V2X ASs 328. In some embodiments, the Mp1 reference point may be enhanced to support secure transfers of data between two or more V2X AS 328 implemented by the same MEC host 340, and the Mp3 reference point may be enhanced to support secure transfers of data between two or more V2X AS 328 implemented by different MEC hosts 340. In these embodiments, the V2X API and/or the VIS 280 may provide a means for exchanging such information between V2X AS 328.

The V2X MEC applications (e.g., MEC application 228 and/or V2X AS 328) may be required to communicate with their peer applications in other MEC systems to achieve the intended purpose of the application usage. The MEC system in question enables an authorized application in one MEC system to communicate with its peers in another MEC system. The VIS 280 and/or V2X APIs (or VIS APIs) may facilitate discovery of application peers by opening available communication endpoint information for point-to-point connectivity. Alternatively, configured traffic rules (e.g., filter rules control 231/331) for V2X MEC applications, along with the underlying MEC inter-system connectivity arrangement, may support communication of application peers. Additionally or alternatively, V2X MEC applications may rely on non-MEC specific means for their peer discovery and then on their authorized access to external interfaces for communication. The required arrangement between the involved MEC systems for achieving secure connectivity with application specific requirements may be application and/or deployment specific and may vary from embodiment to embodiment.

Additionally, V2X MEC applications (e.g., MEC application 228 and/or V2X AS 328) in one MEC system may need to consume services in another MEC system to achieve the intended purpose of the application usage scenario. In this case, the V2X MEC application discovers the service in question in the service registration of its local MEC host 240/340. The arrangement required between the MEC systems involved for mapping services produced in one MEC system to endpoints in another MEC system may be application and/or deployment specific and may vary from embodiment to embodiment.

As previously described, the MEC host 240/340 also provides RNI Services (RNIs). The RNIS is a service that provides radio network-related information to MEC applications (e.g., MEC application 228 and/or V2X AS 328) and to MEC platform 230/330. The RNIS may be available for authorized MEC applications and discovered through the Mp1 reference point. The granularity of the radio network information may be adjusted based on parameters, such as per-cell, per-UE, per-QoS class (or QoS Class Identifier (QCI)) information, or may be requested throughout a time period. The RNI may be used by the MEC application 228 and the MEC platform 230/330 to optimize existing services and provide new types of services based on up-to-date information about radio conditions. The RNI that may be provided may include, for example, up-to-date radio network information about radio network conditions; measurement information related to the user plane based on 3GPP specifications; WLAN measurement; information about UEs connected to radio nodes associated with the MEC hosts (e.g., NAN 110, 210), their UE contexts, and related radio access bearers; changes in information about UEs connected to radio nodes associated with the MEC master, their UE context and related radio access bearers.

In various embodiments herein (e.g., the first and second embodiments discussed below), since the RNIS provides information about vues 101/201 connected to a given NAN 110/210, the type of information provided by the multiple NANs 110/210 may result in real-time traffic flow predictions for the given vUE 101/201 being achieved. This information may then be considered with respect to route planning/updating.

Furthermore, a cell switch should not create a need to trigger the vUE trip-aware QoS prediction process from the beginning (e.g., step 1 above) because the planned trip and data transfer can be passed or transmitted (e.g., installed SW packet version, etc.) from the (master) MEC host 140/240 to the (master) MEC host 140/240 along the planned trip (e.g., over an X2 or Xn interface between RAN nodes, etc.). This "data transfer" is possible because the MEC orchestrator (discussed below) of the MEC system is aware of the MEC host deployment details. Communications between MEC host 140/240 and vUE 101/201 and/or between multiple MEC hosts 140/240 may use secure procedures/protocols, such as, for example: OAuth 2.0 authorization framework that enables third party applications to obtain restricted access to HTTP services (HTTPs:// restfulapi. net/security-essentials /); transport Layer Security (TLS), which is an encryption protocol (https:// block.restase.com/introduction-torest-api-security /) that provides communication security over a computer network; HTTPS, which protects the transmission of messages over the network and provides some assurance to the client regarding the identity of the server; and/or any other suitable communication mechanism.

MEC VIS for route-specific QOS prediction

Embodiments herein relate to V2X service and QoS prediction along a planned trajectory of a vehicle (e.g., vehicle ue (vue), vehicle ITS station (V-ITS-S), etc.), assuming deployment of MEC infrastructure with a RAN (and/or individual RAN node) (e.g., 3GPP fifth generation (5G) RAN, 3GPP LTE E-UTRAN, WiFi Wireless Access Point (WAP), Intelligent Transportation System (ITS) roadside device (R-ITS-S), etc.). In an embodiment, accurate and timely prediction of the radio environment at a location planned to be visited by a vehicle may trigger, modify, or postpone (i) application of a particular V2X function and/or (ii) download of software packages, delivery of content (e.g., streaming media), and/or the like. Multiple access edge computing (MEC) is a technique that allows an application to be instantiated at the edge of the access network and provides a low latency and close proximity environment to the terminal/UE. Thus, vertical industries such as the automotive industry are expected to benefit significantly from deployment of MEC infrastructure in conjunction with deployment of Radio Access Networks (RANs).

Fig. 4 illustrates an exemplary V2X system scenario 400 in which a MEC host 440 is deployed in cooperation with a Network Access Node (NAN)410 providing coverage (e.g., V2X communication services). NAN 410 may be a roadside unit (RSU) or roadside ITS station (R-ITS-S), a cellular base station (e.g., evolved node b (enb), next generation node b (gnb), etc.), or some other network element that provides network coverage (e.g., V2X communication services) to vUE 101 (including first vUE 401-1 and second vUE 401-2). The MEC host 440 provides, among other things, VIS, RNI Service (RNIs), Location Service (LS), UE _ ID service, BWM Service (BWMs), WAI Service (WAIs), FAI Service (FAIs), and/or other MEC services. In fig. 4, the planned trajectories of the first vUE 401-1 and the second vUE 401-2 are not known at the NAN 410 or MEC host 440. However, since the V2X system scenario is characterized by high mobility and dynamic topology, the accuracy and timeliness of information (e.g., radio network, location information, etc.) when collected by the MEC host 440 in a centralized manner, along with the capabilities of the deployed MEC infrastructure, is hampered by environmental conditions (e.g., the occurrence of network congestion events when multiple vues 401 attempt to provide radio measurements to NANs 410 co-located with the MEC host 440) and by the deployment density of cellular networks.

An example showing the impact of the above limitations on system performance is one of a vehicle and related MEC application planned to follow a trajectory from a first location ("location a") to a second location ("location B") that needs to be informed of the radio condition "en route" before the elapsed time of vUE401, and then make a decision. "decision making" may include, for example, enabling/disabling an autopilot feature, downloading infotainment content (e.g., media streaming, immersive gaming, etc.), over-the-air scheduling Software (SOTA), and/or firmware over-the-air (FOMA) updates (e.g., related to driving safety/convenience purposes), etc. In current MEC systems, trip-specific environment/situation information will only be available to vUE401 along with large heaps of data that are not relevant to the planned route. In other words, the distributed data is "polluted" by useless information, which is detrimental from a delay point of view, since it takes more time for downloading a large file, given the same data transfer rate.

To address these challenges, the VIS of embodiments herein facilitates a framework for collaborative acquisition, partitioning, and distribution of information for efficient, trip-specific QoS prediction. That is, VIS can be utilized to identify spatial/temporal correlations between radio quality data collected by different vues 401 in a V2X system and the planned trip of a particular vUE401 for better prediction of the quality of the communication network along the specified route. Thus, the VIS may open relevant (e.g., trip-specific) information about QoS prediction to the authorized vUE 401.

Current/previous solutions to the above problems include the solutions discussed In Filippou et al ETSI MEC (18)000227R2, "MEC 002-In-vehicle MEC hosts supporting automatic works", MEC #104-Tech (12June 2018) ("[ R01 ]") which brings up new MEC usage on onboard MEC hosts supporting automotive workloads. In particular, [ R01] discusses an MEC architecture embodied by a MEC host deployed onboard vUE 401 that may provide content storage and memory capabilities and may enhance context awareness via utilization of a radio network, location, and/or any other information related to an environment that is constantly changing during a trip time. Further, it is mentioned that possible types of workloads hosted by MEC applications instantiated on an in-vehicle MEC host may include Machine Learning (ML), data analysis, fused sensor measurements, and/or other workload types, among others. Thus, ETSI GS MEC002 v2.1.1(2018-10) ("[ R02 ]") incorporates on-board MEC host usage along with related requirements, which support vehicle workload. Embodiments related to on-board MEC hosts are also discussed in more detail below. However, MEC technical components and mechanisms to improve context-aware and predictive QoS are not explained in [ R01] and [ R02 ]. Neither R01 nor R02 mention if and how such paradigm shifts in MEC deployment (and possibly architecture) when considering the V2X scenario are expected to improve the accuracy and timeliness of acquiring and even predicting radio network information ahead of time. Furthermore, the solutions of [ R01] and [ R02] do not allow the vUE 401 to take advantage of the benefits of improved context awareness and/or trip-specific predictive QoS without an onboard MEC host.

The subject of intelligent data-centric decision-making for efficient V2X communications has also been addressed by academic writings (e.g., "Machine Learning for Vehicular Networks," Ye et al arXiv:1712.07143V2(26Feb 2018) ("[ R03 ]") which provides an overview of ML's recent progress toward solving problems faced by V2X communication systems (e.g., traffic flow prediction, congestion control, and local data storage). However, no practical solution set-up is proposed in [ R03 ]. In contrast, [ R03] is relevant to adapt existing learning methods, or to develop V2X specific learning algorithms to better handle these features remains a challenging task and practical consideration to be paid attention to before applying ML methods to facilitate decision making. Practical considerations include increased dynamics of network topology, wireless channels, and traffic distribution, algorithm complexity issues, as processing power is typically limited at the vehicle, while cloud-based solutions will result in potentially large delays and challenges for distributed learning-based solutions. Furthermore, [ R03] does not discuss the actual dimensions of the problem with MEC infrastructure and information exchange settings/protocols (e.g., MEC APIs and/or related MEC applications).

Embodiments herein relate to trip-aware QoS prediction for vues. Specifically, embodiments include a V2X system overlaid by an MEC host. In the first embodiment (embodiment 1), the MEC hosts are deployed only on the network infrastructure side. In a second embodiment (embodiment 2), MEC hosts are deployed on both the network infrastructure side and the vUE side (e.g., "in-vehicle MEC hosts"). Embodiments herein also include a framework for collaborative acquisition, partitioning, and distribution of information for efficient, trip-specific QoS prediction.

From a technical perspective, a first benefit of the MEC-based framework for collaborative acquisition, partitioning and distribution of information for efficient, trip-specific QoS prediction is to reach in advance the right decision (e.g., for optimizing FOTA/SOTA downloads, content streaming and/or any type of content delivery). Such decisions would be based on trip-specific RNIs rather than global information, which may provide little to zero correlation with a given planned route to be followed by the vUE. Furthermore, with respect to embodiment 2, the resulting RNI information partitioning may be exploited for predictive QoS purposes and also stored as historical information to be considered the next time the vUE follows the same or similar route (e.g. office commute). This historical information may be used to reduce computational overhead when allocating resources to vues taking the same or similar routes.

The following discussion describes a collaborative RNI prediction and content delivery decision framework embodiment in view of SOTA/FOTA updates. However, embodiments herein are also applicable to other types of content/data delivery in addition to or instead of SOTA/FOTA updates, including enabling/disabling autopilot features, downloading infotainment content, computing off-loading, collaborative-type ML, and/or other similar data transfer ii.a. example trip-specific QOS prediction & task decision processes, e.g., according to other example use cases discussed herein

Fig. 5 depicts an example vUE journey-aware (or route-aware) QoS prediction process 500 for the first and second embodiments. Process 500 may be used to determine various tasks to perform and/or decisions to take on such tasks based on a predicted trip-specific QoS. Process 500 is discussed with respect to obtaining/downloading SW/FW package updates, however, embodiments herein may be used to obtain other types of data/content (e.g., decisions/tasks for streaming content (e.g., video data, AR/VR or other interactive game data, etc.) or to determine other decisions/tasks (e.g., whether to enable or disable automation tasks, whether to change operating parameters of a vUE or components therein, etc.).

Process 500 begins at operation 505, where each client application (e.g., UE application 202) running on a respective vUE (e.g., vUE 101, 201, 301, 401) residing on a NAN (e.g., NAN 110, 210, 410) reports its planned trip information (e.g., map coordinates and/or route data) to an MEC host (e.g., MEC host 140, 240, 340, 440). The MEC master may be co-sited with a NAN (RAN node or other network element) and may also run (geographical) location services and/or other services. The planned trip information may be supplemented with information regarding data transfers that are to occur during the planned trip. For example, in case the vUE is to obtain updated SW/FW packages, the information may comprise the version of the SW/FW package currently installed or running on the vUE. The SW/FW package may be the client application itself or some other SW/FW package.

Next, in operation 510, each vUE provides radio information to the MEC host. In an embodiment, each vUE reports radio information with low or high periodicity depending on the data transmission to take place and/or other information about the data transmission. For example, the SW/FW packet version number may be used to determine whether radio information should be provided with low or high periodicity. The radio information may be in the form of one or more measurement reports and/or may include, for example, signal strength measurements, signal quality measurements, and the like. Each measurement report is tagged with a timestamp of the measurement and a location (e.g., a current location of the vUE).

As an example, the measurements collected by the vUE and/or included in the measurement report may include one or more of the following: bandwidth (BW), network or cell load, time delay, jitter, Round Trip Time (RTT), number of interruptions, out-of-order delivery of data packets, transmission power, Bit Error Rate (BER), block error rate (BLER), packet loss rate, Packet Reception Rate (PRR), E2E delay, signal-to-noise ratio (SNR), signal-to-interference-and-noise ratio (SINR), signal-plus-noise-and-distortion-plus-noise (SINAD) ratio, carrier-to-interference-and-noise ratio (CINR), Additive White Gaussian Noise (AWGN), energy-per-bit-to-noise power density ratio (Eb/N0), energy-per-bit-to-interference power density ratio (Ec/I0), peak-to-average power ratio (PAPR), Reference Signal Received Power (RSRP), Received Signal Strength Indicator (RSSI), Reference Signal Received Quality (RSRQ), timing of cell frames for UE positioning for E-UTRAN or 5G/NR (e.g., the timing between the AP or RAN node reference time and the GNSS specific reference time for a given GNSS), GNSS code measurements (e.g., the GNSS code phase (integer and fractional part) of the spreading code of the ith GNSS satellite signal), GNSS carrier phase measurements (e.g., the number of carrier phase cycles (integer and fractional part) of the ith GNSS satellite signal measured since locking onto the signal); also known as Accumulated Delta Range (ADR)), channel interference measurements, thermal noise power measurements, received interference power measurements, and/or other similar measurements. The RSRP, RSSI, and/or RSRQ measurements may include RSRP, RSSI, and/or RSRQ measurements for cell-specific reference signals, channel state information reference signals (CSI-RS), and/or Synchronization Signals (SS) or SS blocks of a 3GPP network (e.g., LTE or 5G/NR), as well as RSRP, RSSI, and/or RSRQ measurements for various beacons, Fast Initial Link Setup (FILS) discovery frames, or probe response frames of an IEEE 802.11WLAN/WiFi network. Other measurements may additionally or alternatively be used, such as those discussed in 3GPP TS 36.214v15.3.0(2018-09-27) ("[ R15 ]"), 3GPP TS 38.215v15.4.0(2019-01-11) ("[ R16 ]"), IEEE 802.11, Part 11: "Wireless LAN Medium Access Controls (MAC) and Physical Layer (PHY) specifications, IEEE Std." ("[ R17 ]"), and so forth. Additionally or alternatively, any of the foregoing measurements (or combinations of measurements) may be collected by one or more NANs and provided to the MEC host. In these embodiments, the MEC master may request measurements from the NAN on a low or high periodicity, or the NAN may provide measurements to the MEC master on a low or high periodicity. Additionally or alternatively, the MEC master may obtain other relevant data from other MEC masters, core network functions, and/or other vues for determining QoS predictions and/or generating composite information. For example, other Key Performance Indicators (KPIs) may be collected from other MEC hosts via suitable MEC APIs and/or from core network functions via network open functions and used to predict QoS along planned routes and/or generate composite information (discussed below). Additionally or alternatively, the vUE may obtain other relevant information and provide this information to the MEC host along with or separately from the measurement report.

At operation 515, the MEC host compiles or otherwise generates QoS prediction and/or composite information based on the planned routes and/or measurement reports for each vUE. QoS prediction may include predicted QoS for various points along the planned route of the vUE. The composite information may include, for example, recommendations as to whether to perform data transfers at various points on the planned route, and/or content to be delivered to the vUE based on predicted QoS along the planned itinerary. In some embodiments, the MEC host may operate a trained ML algorithm to predict QoS along the planned route and/or generate composite information. For example, a trained neural network (e.g., a convolutional neural network and/or a cyclic neural network) may determine inferences using input data indicative of time-varying radio measurements and location information. The particular ML model/algorithm used may vary from embodiment to embodiment.

When generating the composite information, the MEC host divides or re-divides the composite information into individual data blocks, chunks, or chunks, each of which is related to a particular planned route, a particular vUE, or a cluster or group of vues (e.g., a fleet of vehicles) that are planned to follow the same or similar route/trip. The information (re) partitioning is a pre-processing stage to obtain a useful data set to be used for trip-specific QoS prediction. Whether an on-board MEC host is present, absent, or unavailable at the vUE, the fusion information at the main MEC host is partitioned by correlation to the planned itinerary of the vUES. Additionally or alternatively, the fused information at the on-board MEC host is partitioned according to correlation with previously collected planned trips of the vUES.

Any suitable data fusion or data integration technique may be used to generate the composite information. For example, the data fusion technique may be a direct fusion technique or an indirect fusion technique. Direct fusion combines data acquired directly from multiple vues or sensors, which may be the same or similar (e.g., all vues or sensors perform the same type of measurement) or different (e.g., different vues or sensor types, historical data, etc.). Indirect fusion utilizes historical data and/or known environmental properties and/or human input to generate a refined data set. Additionally, the data fusion techniques may include one or more fusion algorithms (e.g., smoothing algorithms (e.g., estimating values using multiple measurements in real-time or non-real-time), filtering algorithms (e.g., estimating a state of an entity with current and past measurements in real-time), and/or predictive state estimation algorithms (e.g., analyzing historical data (e.g., geographic location, speed, direction, and signal measurements) in real-time to predict a state (e.g., future signal strength/quality at particular geographic location coordinates))). Thus, in some embodiments, data fusion may be used to estimate various vUE parameters not provided by the vUE, as well as to predict QoS and/or signal quality for particular trips or routes. As examples, the data fusion algorithm may be or include a structure-based algorithm (e.g., a tree-based (e.g., Minimum Spanning Tree (MST)), a cluster-based, a mesh-based, and/or a centralized-based), a structure-free algorithmic data fusion algorithm, a kalman filter algorithm, a fuzzy-based data fusion algorithm, an Ant Colony Optimization (ACO) algorithm, a fault detection algorithm, a Dempster-shafer (ds) -based argumentation algorithm, a gaussian mixture model algorithm, a triangulation-based fusion algorithm, and/or any other similar data fusion algorithm.

At operation 520, the MEC application at the MEC host (co-sited with the NAN and/or the in-vehicle MEC host) processes each partition depending on the presence or absence of the in-vehicle MEC host at each vUE. In an embodiment, the MEC application may be triggered by an indication of the availability of a new SW/FW package to begin processing each partition. When the vUE does not host an in-vehicle MEC host, the partitioning is processed according to the first embodiment. When the vUE does host an in-vehicle MEC host, the partitioning is handled according to the second embodiment.

In a first embodiment (when there is no on-board MEC master or an on-board MEC master is not available), the composite information is divided into trip/route specific divisions including radio signal quality for each planned trip/route. The trip-specific partition is used as input for decision making (e.g., for determining trip-specific QoS predictions) along with the SW/FW packet versions running at each of the vues. After performing the trip specific QoS prediction at the MEC host, a decision is taken by the MEC application at the MEC host to recommend initiating/downloading SW/FW updates. The recommendations are then forwarded by unicast or multicast transmission to client applications running at (i) vues that have planned routes tailored for trip-specific divisions, (ii) that run out-of-date SW/FW packages, and (iii) that are expected to experience favorable radio conditions along their planned routes, at operation 525.

In a second embodiment (when there is an onboard MEC host available), the composite information is divided into trip/route specific RNIs, packaged and sent to individual client applications at the vUE at operation 525. Here, operation 525 may involve unicast transmission to individual vues or multicast transmission to clusters or groups of vues with the same or similar planned routes. Each client application performs trip-specific QoS prediction using the received trip-specific RNI and the version of the currently installed SW/FW package. Each client application may also consider one or more other locally running applications as well as other operating parameters (e.g., resource utilization, etc.). Each client application makes a decision while traveling towards its endpoint using an RNI analysis MEC application instantiated at the on-board MEC host when scheduling a task (e.g., SW/FW update/package download).

When the MEC host or vUE detects a change to the planned trip, the process 500 is repeated with the updated trip information. The change to the planned trip/route may be based on sensor data, GPS data, 5G/LTE location service data, data from one or more applications, and/or the like. Each client application at each vUE may use appropriate APIs, drivers, etc. to interact with sensors, GPS circuitry, and/or other applications to obtain data for making such determinations.

Ii.b. example 1

The first embodiment relates to an implementation in which an MEC master (e.g., MEC master 140, 240, 340, 440 of fig. 1A, 1B, 2, 3, and 4; MEC master 1502 of fig. 15, etc.) is deployed at or co-sited with one or more NANs (e.g., NANs 110, 210, 410 of fig. 1A, 1B, 2, and 4).

The following data structures may be used to implement a collaborative RNI prediction and content delivery decision framework. As described in step 1 of the vUE trip-aware QoS prediction and task decision procedure, each client application running in the vUE reports planned trip/route information to the MEC host. A data structure for planning route information having an Identifier (ID) (e.g., "UE _ ID") includes coordinates of the following locations: a start point position, which refers to point a (e.g., "start point a") in the route from point a to point B; an end position, which refers to point B in the route from point a to point B (e.g., "end B"); and a number of intermediate locations that reflect the trajectory or route to or through which the vUE is to travel on the route (e.g., a particular street, highway, etc.). Table 1 shows an example data structure that may be used to convey this location information.

TABLE 1

UE _ ID waypoints	Geographic location
		Starting point A	41°24'12.2"N,2°10'26.5"E
Intermediate position 1	41°23'14.9"N,2°12'32.7"E
		Intermediate position 2	41°22'31.8"N,2°14'21.8"E
…
		Intermediate position N	41°17'16.2"N,2°19'34.1"E
End point B	41°15'23.6"N,2°24'18.1"E

A data structure representing a format of a message periodically sent by the vUE in step 2 of the vUE journey aware QoS prediction procedure and received by a NAN co-sited with the MEC host. Different attributes of a message may include: the ID of the vehicle "UE _ ID", the message transmission time or timestamp ("TS"), the location of the vUE at the time of transmission ("UE _ Loc"), and local radio measurements at the vUE (e.g., RSRP/RSRQ values accumulated over a time window ending at time TS (e.g., message transmission time)). Table 2 depicts an example of such a message format.

TABLE 2

UE_ID

TS

UE_Loc

Measuring

A data structure for a message sent by the RSU/eNB to notify targeted UEs (e.g. via unicast transmission) or targeted UE clusters (e.g. via multicast transmission) at step 4a of the vUE trip aware QoS prediction procedure. This message is used to indicate the availability of an updated SW package version with ID "SW _ Ver _ New", recommended download Start Time "DL _ Start _ Time" and expected duration of download "DL _ Exp _ Dur" based on predicted radio conditions along the vehicle route.

TABLE 3

SW_Ver_New

DL_Start_Time

DL_Exp_Dur

Fig. 6 depicts an example process 600 according to the first embodiment. The process 600 is a single decision cycle that may be performed by the MEC master 440 co-sited with the NAN 410 and vUE 401 within the coverage area of the NAN 410 (see, e.g., fig. 4). Process 600 is described as being used to make decisions regarding whether to download Software (SW) and/or Firmware (FW) updates, however, process 600 may be used to make decisions regarding other types of data transfer usage (e.g., the usage discussed herein).

The process 600 begins at operation 601, where the MEC host 440 receives the current/updated trip plan from the vUE 401 along with its version of SW and/or FW running to the MEC host 440 via the co-sited/connected NAN 410. In operation 602, the MEC host 440 determines whether there is a new SW/FW package version available for the vUE. If the MEC host 440 determines that there is no new SW/FW packet version available for the vUE, the MEC host 440 proceeds to operation 603, where the MEC host 440 periodically receives locally experienced radio quality information at the vUE 401 from the vUE. This may involve a relatively low sample/message transfer rate (e.g., L < K cycles, where L and K are numbers). At operation 604, the MEC host 440 re-partitions the acquired multi-vehicle information as per context (e.g., correlation to the planned route of the vUE under coverage), and at operation 605, the MEC host 440 recommends to initiate/postpone SW-ota (sota)/FW-ota (fota) updates and notify the vUE under coverage when these updates are needed. In some embodiments, if the currently installed SW package for a given vUE 401 is the latest version of the SW package, then at operation 605 the network need not provide recommendations via the MEC host 440. After operation 515, process 600 ends.

Referring back to operation 602, if MEC host 440 determines that there is a new SW/FW packet version available to vUE 401, MEC host 440 proceeds to operation 606 where MEC host 440 periodically receives locally experienced radio quality information at vUE 401 from the vUE. This may involve a high sample/message transfer rate (e.g., K cycles, where K is a number). In other words, when the version of the currently installed SW/FW package is the latest (latest) and/or latest (newest) version, the measurement is provided at a low rate (see, e.g., operation 603); conversely, when the currently installed SW/FW package version is not the latest (latest) and/or latest (newest) version (e.g., SW/FW package updates are not needed or desired), measurements should be provided at a higher rate (see, e.g., operation 606). At operation 607, MEC master 440 re-partitions the acquired multi-vehicle information according to context (e.g., relevance to the planned route of the vUE under coverage). In operation 608, vUE 401 reports its planned itinerary after information repartitioning at MEC host 440.

In some embodiments, MEC host 440 does not perform any further information partitioning after vUE 401 communicates the updated trip plan. Rather, MEC host 440 correlates or associates the most appropriate partition (e.g., the highest context-dependent partition) with vUE 401 (see, e.g., operation 610), and then performs trip-specific QoS prediction and provides recommendations based on the trip-specific QoS prediction (see, e.g., operation 611).

In operation 609, MEC host 440 determines whether the planned route for vUE 401 is still valid. If MEC host 440 determines that the planned route for vUE 401 is not still valid, MEC host 440 proceeds to operation 610 to correlate the updated trip plan with the highest (spatial) correlation multi-vehicle information split. Then, at operation 611, the MEC master 440 evaluates the expected openness, suggesting to initiate/postpone SOTA/FOTA updates and notify the vUE, taking into account the packet size. If, at operation 609, MEC host 440 determines that the planned route for vUE 401 is still valid, MEC host 440 proceeds to perform operation 611 without performing operation 610. In operation 612, vUE 401 makes a decision as to whether to start/defer downloading according to functional requirements, policies, preferences, etc., or MEC host 440 determines whether to start/defer downloading to vUE 401 according to functional requirements, policies, preferences, etc., of either vUE 401 or MEC host 440. After operation 612, process 600 may end.

Fig. 7 depicts an exemplary scenario 700 in which an MEC host 740 (which is the same as or similar to MEC host 440 of fig. 4) co-sited with a NAN 710 (which is the same as or similar to NAN 410 of fig. 4) and three vues 701 (including vues 701-1, 701-2, and 701-3, which are the same as or similar to vUE 401 of fig. 4) are under the coverage of the NAN 710 (or reside on the NAN 710). The NAN 710 may be a radio infrastructure node (e.g., RSU or R-ITS-S), a Radio Access Point (RAP) providing ITS-G5 and/or DSRC network services, or a RAN node providing cellular network services (e.g., eNB, gNB, etc.). In scenario 700, vUE 701-1 and vUE 701-2 have the same planned route from location a to location B, and vUE 701-3 has planned a different route from location C to location D. In this example, each vUE 701 is attempting to obtain SOTA and/or FOTA updates, where vUE 701-1 has the latest version of the particular SW package installed (e.g., v1.3), and vues 701-2 and 701-3 have an outdated version installed (e.g., v 1.2). Process 600 of fig. 6 may be performed with respect to vUE 701-2 and vUE 701-3 obtaining recommendations when initiating or deferring SW package download, which may be as follows.

In operation 1, vUE 701-1 reports the planned journey from location a to location B to MEC host 740 via transmission to NAN 710 and instructs to install SW package v1.3 at vUE 701-1. In operation 2, vUE 701-2 reports the planned journey from location a to location B to MEC host 740 via transmission to NAN 710 and instructs to install SW package v1.2 at vUE 701-2. In operation 3, vUE 701-3 reports the planned journey from location a to location B to MEC host 740 via transmission to NAN 710 and instructs to install SW package v1.2 at vUE 701-3. In operation 4, each of vUE 701-1, vUE 701-2 and vUE 701-3 uploads respective radio signal quality measurements tailored to vUE location and timestamp. In this example, vUE 701-1 uploads fewer tagged measurements than vUE 701-2 and vUE 701-3 because it does not require SW packet updates (at present). In operation 5, the MEC host 740 acquires and re-partitions all original data according to the trip-based criterion; two data partitions are obtained: one associated with the route between locations a and B and one associated with the route between locations C and D.

In operation 6, MEC host 740 predicts the radio signal quality that vUE 701-2 is expected to experience based on the first data partitioning (sourced by vUE 701-1 and vUE 701-2) and, for example, by using statistical tools, ML/AI algorithms, etc., and recommends that vUE 701-2 start or defer downloading in view of the SW packet size. In case of a recommended start, the start time of the download is also recommended. In operation 7, MEC host 740 predicts the radio signal quality that vUE 701-3 is expected to experience and recommends vUE 701-3 to start or defer downloading, taking into account the size of the SW packet. The prediction is based on a second data partitioning, which can be enriched by the obtained past measurements relating to the route between locations C and D. In case of a recommended start, the start time of the download is also recommended.

Although embodiment 1 is discussed as being implemented by an MEC host co-located with a network access infrastructure, in some implementations, an onboard MEC host (see, e.g., fig. 8-9) may provide trip-specific QoS predictions for its own local MEC applications or for other MEC hosts (including other onboard MEC hosts), e.g., by utilizing sidelink/short range connectivity where vehicle-to-vehicle (V2V) communications are possible.

Ii.c. example 2

A second embodiment relates to an MEC system implementation in which an MEC host is deployed at or co-sited with one or more NANs and the MEC host is co-sited at or implemented by a vUE. The NAN may be the same as or similar to NAN 110, 210, 410, and 710 of fig. 1A-6, discussed previously, and the MEC master may be the same as or similar to MEC master 140, 240, 340, 440, and 740 of fig. 1A-6 and/or MEC master 1502 of fig. 15, etc. An MEC host co-sited at or implemented by a vUE is referred to as an "in-vehicle MEC host" or the like.

Today's passenger vehicles incorporate a diverse embedded computing environment responsible for handling a variety of functions of different nature. This environment consists of processing units and processes in which information is exchanged over a specific industrial message bus, however, it is rather complex, hardly reconfigurable, and also highly specialized to cater for the dissimilar functions. To address such issues, suggested use cases include the availability of on-board MEC hosts to support the automotive workload encountered in passenger vehicles. Such workloads can be customized for several similar or diverse functions affecting different on-board units (OBUs) of a passenger vehicle, such as an Engine Control Unit (ECU), e.g., related to security, remote information processing, high-resolution maps for navigation, and video and other infotainment applications. As an example, fig. 8 shows a system scenario 800 according to which two vues 801 running different applications are connected to a given radio node 810 (e.g., cellular connectivity). Each application is running on MEC host 841 embedded within a corresponding vUE 841.

Fig. 8 depicts an example hierarchical MEC system 800 that includes a primary MEC host 810 co-sited with a NAN 810 (e.g., RAP or RAN node) and an onboard MEC host 841 co-sited with a corresponding vUE 801 under coverage. For example, in-vehicle MEC host 841-1 is co-sited with vUE 801-1, in-vehicle MEC host 841-2 is co-sited with vUE 801-2, and in-vehicle MEC host 841-3 is co-sited with vUE 801-3.

Since a recent trend in the automotive industry is to develop software architectures that utilize fewer processing units and contain more open operating systems, MEC technology can constructively add to this trend as it provides an open, standardized environment for efficiently integrating applications running on passenger vehicles. Additionally, the MEC architecture embodied by MEC hosts deployed onboard vUE 401 may provide content storage and memory capabilities and may enhance context awareness via leveraging a radio network, location, and/or any other information related to the changing environment during the trip time. Notably, the fluctuating connectivity conditions that an on-board MEC host may experience, along with its potentially limited processing, memory and storage capabilities and vehicle ownership aspects, may impact its efficient management. In the example of fig. 8, three vues 801 are running different applications. Today's passenger vehicles incorporate a diverse embedded computing environment responsible for handling a variety of functions of different nature. This environment consists of processing units and processes in which information is exchanged over a specific industrial message bus, however, it is rather complex, hardly reconfigurable, and also highly specialized to cater for the dissimilar functions. To remedy this problem, on-board MEC host 841 supports the automotive workload encountered in V2X applications. Such workloads can be customized for several similar or diverse functions affecting different on-board units (OBUs) of a passenger vehicle, such as an Engine Control Unit (ECU), e.g., related to security, remote information processing, high-resolution maps for navigation, and video and other infotainment applications. As an example, fig. 1 shows a system scenario according to which two passenger vehicles running different applications are connected to a given radio node (cellular connectivity). Each application is running on an MEC host embedded within the corresponding passenger vehicle.

The functionality for the onboard MEC host 841 may include MEC applications running different types of workloads (e.g., Machine Learning (ML), data analytics, sensor measurement fusion from vehicles and environments, privacy enforcement for data streams destined for the cloud (e.g., face blurring in video streams from onboard cameras), etc.). The different MEC applications may share data directly, or also through the MEC V2X API. In-vehicle MEC host 841 may also enable offloading of processing-critical tasks (e.g., related to computing hunger-thirsty applications (e.g., Augmented Reality (AR), Virtual Reality (VR), Artificial Intelligence (AI), etc.) from vUE 801 to the network. In-vehicle MEC host 841 may also provide a common application framework for independent deployment across service providers through the applicable interoperable RESTful API, thus also enabling cost-effective and efficient application lifecycle and V2X service provisioning.

In this example, the master MEC host 840 runs and/or provides various enhanced (e.g., cell/coverage area) MEC services via respective MEC APIs (hereinafter "master MEC API", "master API", etc.). Other entities (e.g., vUE 801, in-vehicle MEC host 841, in-vehicle MEC applications, other MEC hosts 840, remote application servers, etc.) use the primary MEC API to access information/services from primary MEC host 840. The main MEC API is discussed in more detail below.

Additionally, each vUE 841 runs and/or provides local UE MEC services, which may be UE-based versions of MEC services that may be accessed via respective MEC APIs (hereinafter "UE MEC APIs", "UE APIs", etc.). Other entities (e.g., NAN 810, primary MEC host 840, other vues 801, other in-vehicle MEC hosts 841, MEC applications hosted by in-vehicle MEC host 841, external MEC applications, other MEC hosts 840, remote application servers, etc.) use the UE MEC APIs to access information/services from in-vehicle MEC host 841. The UE MEC API is discussed in more detail below.

The procedure for accessing and/or providing trip specific QoS predictions in relation to the second embodiment is similar to that of the first embodiment, with the difference that: the decision to initiate/defer an action (e.g., content delivery, SW update, etc.) is not taken in a centralized manner at the MEC host 840 co-located with the NAN 810, but rather is determined at the respective on-board MEC host 841 via an analytics MEC application (e.g., a dedicated RNI analytics MEC application). In this way, each vUE 801 can control its own networking and processing performance based on trip-specific partitioning of cell/area/range measurements collected on the network side.

Fig. 9 depicts an information collection framework 900 according to a second embodiment. In this embodiment, a master MEC host 940 (corresponding to master MEC host 840 of fig. 8) is co-sited with a NAN 910 (corresponding to NAN 810 of fig. 8). Additionally, vUE 901 (corresponding to any vUE 801 of fig. 8) is hosting an in-vehicle MEC host 941 (corresponding to any in-vehicle MEC host 841 of fig. 8).

Master MEC host 940 hosts or implements MEC applications 9408 (corresponding to any MEC applications discussed herein) and MEC platform 9403. In-vehicle MEC host 941 hosts or implements a local instance of MEC application 9418 (corresponding to any MEC application discussed herein) and MEC platform 9413. MEC hosts 940, 941 each include their own virtualization infrastructure 922 and their own data plane instance 924. The MEC platforms 9403, 9413 include service registry 938, filter rule control 931, DNS processing 932, and corresponding instances of various MEC APIs.

As previously described, the main MEC host 940 provides various MEC services including, for example, VIS, RNIS, BWMS, LS, WAIS, FAIS, and/or other similar services. Access to MEC services is provided by respective MEC APIs (e.g., location API 9400 (providing access to LS), primary RNI API 9401 (providing access to RNIs), primary V2X API 9402 (providing access to VIS), and other primary MEC APIs 9403). Other main MEC APIs 9403 may include, for example, a UE _ ID API (providing access to UE _ ID services), a BWM API (providing access to BWMs), a WAI API (providing access to WAIs), a FAI API (providing access to FAIs), and/or other similar APIs. In some embodiments, the master V2X API 9402 may have a resource URI structure as depicted in FIG. 12 and the method illustrated by Table 7.2-1 above.

Additionally, the in-vehicle MEC host 941 runs and/or provides local UE MEC services, which may be UE-based versions of VIS, RNIS, LS, BWMS, UE _ ID services, WAIS, FAIS, etc., that may be accessed using respective UE RNI APIs (e.g., UE location API 9410, UE RNI API 9411, UE V2X API 9412, and other UE MEC APIs 9413). Other UE MEC APIs 9412 may include, for example, UE-based UE _ ID APIs, BWM APIs, WAI APIs, FAI APIs, etc. The UE MEC API may be the same as the main MEC API, or the UE MEC API may be specially adapted/customized for the in-vehicle MEC host 941. In some embodiments, the UE V2X API 9412 may have a resource URI structure as depicted in fig. 12 and the method illustrated by table 7.2-1 above.

In various embodiments, the primary MEC host 940 periodically collects UE information (e.g., RNI, location, UE identity, V2X information, etc.) from all vues 901 under network coverage of the NAN 910 by using the primary V2X API 9402 (or UE V2X API 9412), while each onboard MEC host 941 collects local information for feedback back to the primary MEC host via the UE MEC API (e.g., UE V2XAPI 9412 and/or primary V2X API 9402). The main MEC host 940 uses the collected information to generate partitions as previously described, and the onboard MEC host 941 processes the travel-related information partitions received from the main MEC host 940 with the purpose of making decisions to initiate/defer certain actions (e.g., downloading SOTA/FOTA updates, streaming content at certain data rates, buffering data downloads at certain locations/times, etc.). This decision is made by a locally instantiated MEC application 9418 (e.g., an RNI analysis MEC application 9418, etc.) at the onboard MEC host 941.

For example, at step 4b of the vUE journey-aware QoS prediction process, at one or more content delivery requests (e.g., SOTA/FOTA updates), the onboard MEC host 941 instantiates or executes an RNI analysis MEC application 9418, consuming the journey-specific part of the acquired composite UE context information distributed by the primary MEC host 940. The RNI analysis MEC application 9418 schedules content delivery requests and/or recommends activation/deactivation of specific V2X application features (e.g., autopilot features, etc.) subject to the obtained trip-specific partitioning of the composite RNI information. These embodiments may be useful when vUE 901 moves out of network (e.g., cellular) coverage, as the RNIs collected (possibly by more capable UEs) with reference to these geographic regions will have been known in advance. Thus, even without network (e.g., cellular) coverage by one or more NANs 910, the vUE 901 will be able to adapt its operation (e.g., defer or reduce download rates to adapt to adverse radio conditions).

An example data structure. The data/information structure may be the same or similar as described in the first embodiment, with the difference being the message sent by the NAN 910 at step 4b of the vUE journey aware QoS prediction process. In this embodiment, since the decision is to be taken at the onboard MEC host 941, trip specific measurement sets (e.g., information partitioning) are sent from the NAN 910 exclusively to the vUE 901 using unicast transmission or to the vUE cluster 801/801 via multicast transmission. Table 4 describes an example of such a data structure.

TABLE 4

The data structure of table 4 provides each of the measurement time stamp, the measurement location, and the measurement value for the respective waypoints 1 through S, where S is a number. In the example of table 4, "TS" refers to a particular timestamp value, "Loc" refers to a particular location value, and "Meas" refers to a particular radio measurement value. The timestamp refers to the time at which the measurement was taken as determined by the vUE 801/801 relative to some reference time, which may be based on some suitable internal or external clock that provided the reference time. The timestamp may be a universal clock indication and/or a timestamp data type provided by the MEC LS via the location APIs 9400, 9410. The survey location is the location (e.g., geolocation, cell location, etc.) at which the survey is taken and may be expressed using any suitable location/geolocation indication (e.g., LocationInfo datatypes provided by MEC LS via location APIs 9400, 9410 (e.g., GPS/GNSS coordinates based on the world geodetic system in 1984 (WGS 84) and/or based on 3GPP location services (see, e.g., [ R10] and ETSI TS 123032 V15.1.0 (2018-09)). Additionally or alternatively, WLAN location services may be used to measure location. For example, the geographical location of the vUE 901 based on dynamic host configuration protocol (e.g., DHCPv4 and DHCPv6) coordinates may be used, which includes Location Configuration Information (LCI), and the LCI includes latitude, longitude, and altitude data/coordinates with a resolution or uncertainty indicator for each data/coordinate (see, e.g., IETF RFC 6225 (2011-07)). The measurement values may be any of the above-described measurement types (e.g., RSRP, RSRQ, etc.) or combinations thereof. In some embodiments, the measurement values may be provided by any UE measurement report discussed in [ R09] (e.g., by layer 2 measurement information (L2Meas), 5G UE measurement report (nrmeasrepusessubscription), etc.). Additionally or alternatively, the data structure of table 4 may be or may include an RNIS measurement report provided by the RNIS that includes a timestamp and cell ID information. Additionally or alternatively, the measurement reports provided by the RNIS may include additional or supplemental location information provided by the MEC LS to provide a more accurate (geographical) location of the vUE 901.

Fig. 10 depicts an example process 1000 according to a second embodiment. The process of fig. 10 is a single decision cycle that may be performed by the MEC host 940 co-located with the NAN 910 and/or one or more vues 901 with onboard MEC hosts 941 within the coverage area of the NAN 910. Process 900 is described as being used to make decisions regarding whether to download SW and/or FW updates, however, process 1000 may be used to make decisions regarding other types of data transfer usage (e.g., as discussed herein).

The process 1000 begins at operation 1001, where the primary MEC host 940 (or the on-board MEC host 941) receives a report of the current and/or updated trip plans of the vUE 901 along with the version of SW/FW it runs. (when executed by in-vehicle MEC host 941, the vUE 901 being analyzed may be the vUE 901 that in-vehicle MEC host 901 is deployed or another vUE 901 implementing another in-vehicle MEC host 941; in the latter case, assuming that V2V communication is feasible (e.g., sidelink/short-range communication.) at operation 1002, main MEC host 940 (or in-vehicle MEC host 941) determines whether there is a new SW/FW packet version available for vUE 901. if there is no new SW/FW packet version available for vUE 901, then at operation 1003, vUE 901 periodically provides locally experienced radio quality information to MEC host 940 at a low sampling/messaging rate. The main MEC host 940 (or in-vehicle MEC host 941) re-partitions the acquired multi-vehicle information according to context (e.g., association with the planned route of the vUE 901 under coverage) and at operation 1005, the main MEC host 940 (or in-vehicle MEC host 941) promises to transmit each information partition to the most relevant vUE 901 via unicast/multicast transmission (and/or siding/PC 5 transmission when executed by in-vehicle MEC host 941). Here, the most relevant vUE 901 may be based on context information (e.g., relevance to the planned route of the vUE 901). Additionally, at or after operation 1005, each vUE 901 requiring SW/FW updates processes the received information partitioning at the respective in-vehicle MEC host 941. In an embodiment, the RNI analysis MEC application 9418 makes decisions about start time, location, and/or deferred (if necessary) downloads. After performing operation 1005, process 1000 ends.

Referring back to operation 1002, if the main MEC host 940 (or in-vehicle MEC host 941) determines that there is a new SW/FW packet version available to the vUE 901, then in operation 1006, the main MEC host 940 (or in-vehicle MEC host 941) periodically receives radio measurements at a high sampling/messaging rate. In an embodiment, vUE 901 periodically provides locally experienced radio quality information to main MEC host 940 (or onboard MEC host 941) at a high sampling/messaging rate (e.g., K cycles, where K is a number). In other words, when the version of the currently installed SW/FW package is the most recent and/or latest version, the measurements are provided at a low rate (see, e.g., operation 1003); conversely, when the currently installed SW/FW package version is not the most recent and/or latest version (e.g., SW/FW package updates are needed or desired), measurements are provided at a higher rate (see, e.g., operation 1006). In operation 1007, the main MEC host 940 (or the in-vehicle MEC host 941) re-divides the acquired multi-vehicle information by context (e.g., correlation with the planned route of the vehicle under coverage), and in operation 1008, after the re-division, the main MEC host 940 (or the in-vehicle MEC host 941) receives the planned trip information of the vUE 901. In an embodiment, vUE 901 reports its planned itinerary after information at primary MEC host 940 (or onboard MEC host 941) is repartitioned.

In operation 1009, the main MEC host 940 (or the in-vehicle MEC host 941) determines whether the planned route of the vUE 901 is still valid based on the updated trip information obtained in operation 1008. If the planned route of the vUE 901 is not still valid, the main MEC host 940 (or in-vehicle MEC host 941) proceeds to operation 1010 where the main MEC host 940 (or in-vehicle MEC host 941) correlates or associates the most appropriate partition (e.g., the highest context-related partition) with the vUE 901 of interest (e.g., the vUE 901 whose route is being analyzed/processed). In some embodiments, after the vUE 901 communicates the updated trip plan, the primary MEC host 940 (or onboard MEC host 941) does not perform any further information partitioning; in contrast, the main MEC host 940 (or the in-vehicle MEC host 941) performs operation 1010.

Referring back to operation 1009, if the primary MEC host 940 (or onboard MEC host 941) determines that the planned route of the vUE 901 of interest is still valid, the primary MEC host 940 (or onboard MEC host 941) proceeds directly to operation 1011 to transmit the trip-specific information split to the vUE 901 of interest via unicast or multicast transmission. After operations 1009 or 1010, the main MEC host 940 assumes at operation 1011 that the trip specific information split is transmitted to the concerned vUE 901 via unicast or multicast transmission (and/or side link/PC 5 transmission when executed by the onboard MEC host 941). Additionally, at or after operation 1011, vUE 901 (or the RNI analysis MEC application 9418 instantiated at the onboard MEC host 941) performs trip specific QoS predictions and provides recommendations based on the trip specific QoS predictions. Here, the vUE 901 (or the RNI analysis MEC application 9418 instantiated at the in-vehicle MEC host 941) makes a decision on the start time, location and/or delay (if needed) of a download or other data transfer. After performing operation 1011, process 1000 ends.

MEC VIS plan route aware QOS notification

In the embodiments discussed above, the usefulness of MEC VIS API is highlighted when it comes to obtaining a run-length aware QoS prediction. These predictions are used by the MEC application that needs to be notified that the radio condition is "en route" before the elapsed time of the vUE, and then decision is made as to whether to transmit data in the DL or UL or both directions (e.g., enable/disable the autonomous driving feature, download infotainment content, schedule SOTA/FOTA updates, etc.). A challenge for MEC VIS (e.g., VIS 280 in fig. 2) is to identify spatial/temporal correlations between radio data (RNI) collected by different vues in a V2X (e.g., C-V2X) system and the planned itinerary/route of a particular vUE to better predict the quality of the communication network (e.g., radio conditions, QoS, etc.) along the specified route. In order to obtain timely and accurate QoS predictions along the planned vUE route, the VIS API may need to collect and process information available to other MEC APIs (see, e.g., fig. 2, 3, and 8). Thus, new VIS API resource elements are needed to collect and process information available to other MEC APIs, each of which may be useful for the usage/V2X usage set.

Currently, no solution has been proposed to exploit the spatial temporal correlation between the RNIs delivered by vues under network (e.g., cellular) coverage and the planned routes of these vues (or other vues under network coverage) for the system to generate trip-specific QoS notifications. Most importantly, no solution has been proposed for any process/procedure and/or data type to accomplish these tasks.

Embodiments herein emphasize the role of VIS as it relates to generating trip-specific QoS notifications. To accomplish such tasks, embodiments herein provide processes and/or processes (e.g., sequence diagrams) and data types that reflect the planned itinerary of the vUE. Embodiments herein provide a framework for collaborative acquisition, partitioning, and distribution of information regarding trip-specific QoS predictions in MEC implementations. According to various embodiments, a VIS consumer (e.g., MEC application or MEC platform) sends a request to the VIS to receive planned route information for a particular vUE. One or more data types representing planned route (e.g., location) information for the vUE are also provided. This information is per-UE (e.g., tailored for a particular UE identity). Attributes of a data type refer to the time and location of interest for a given vehicle UE. The procedures/procedures and data types discussed herein may be included in the ETSI MEC V2X service (VIS) specification. Embodiments may also be part of the service subscription/notification and resource tree of MEC VIS API. Embodiments herein provide energy efficiency in V2X communications through resource allocation over large areas/regions and better quality of experience (QoE) V2X user-enabled communication/signaling resource conservation.

Embodiments 1 and 2 discussed above focus on the role of VIS as it relates to generating run-specific QoS predictions. The MEC VIS-informed embodiment may be used in embodiments 1 and 2 to exchange other relevant information regarding trip-specific QoS predictions and task decisions. MEC VIS notification embodiments include example processes/procedures according to which a service consumer (e.g., MEC application 1526 and/or MEC platform 1532 of fig. 15) sends a request for planned route information for a particular vUE and an example data type representing the planned route (location) information for the vUE). This information is per vUE (e.g., tailored to a particular UE identity). Attributes of a data type refer to the time and location of interest for a given vUE.

FIG. 11 illustrates example V2X/VIS API processes 1101, 1102, and 1103 in accordance with various embodiments. In the process of fig. 11, a service consumer (e.g., a VIS consumer (e.g., an MEC application or MEC platform)) sends a request for information for a particular vUE (e.g., vUE 101, 201, 401, 701, 801, 901 discussed previously). In response to the request, the service provider (i.e., the VIS (e.g., VIS 280 of fig. 2, VIS provided by V2X APIs 9402 and 9412 of fig. 9, etc.)) generates a response including the requested information and sends the response to the service consumer. The service consumer receives a response from the VIS including the requested information.

Fig. 11 includes a first process 1101 that is a process of requesting planned route information for a particular vUE for a service consumer. Process 1101 begins at operation 1101-1, where a service consumer (or VIS consumer) sends a request message to a VIS as a service producer (or "VIS producer"). In this embodiment, the VIS is a resource that represents the planned route information, and the VIS consumer uses the GET method to obtain (e.g., read) the planned route information resource. In an embodiment, the request contains UE identity information of the vUE as an input parameter. The request message may be an HTTP GET message with the request line "GET./planed _ route _ info _ id", where the "UE _ id" parameter is the UE identity information. Here, the resource URI is "{ apiRoot }/vis/v 1/planed _ route _ info _ id". In some embodiments, the request may include a service consumer instance ID as an input parameter, which may be included in a message body of the request message.

At operation 1101-2, the service producer (e.g., VIS) responds with a response/reply message that includes a message body containing the planned route information. In this embodiment, the response message is an HTTP response message that includes a status code "200 OK" in the header of the HTTP message, which indicates that the service consumer's request was successful. Further, the requested planned route information data structure (planednrouteinfo) is included in the body of the HTTP response message. In some embodiments, the response message may include a planedorutelnfo IE, a field, a data element, etc. to include a planedorutelnfo data structure. In this embodiment, the GET method is used to request planned route information corresponding to the potential route of the vUE providing the ID in the request. The method supports the URI query parameters, request and response data structures, and response codes specified in tables 5 and 6.

Table 5: URI query parameter supported by GET method for PlannedRouteInfo resource

Table 6: data structure supported by PlannedRouteInfo GET resource

PlannedRouteInfo is a resource data type. The planedreuteinfo type represents the planned route (location) information of the vUE. This information is on a per-UE basis (e.g., tailored to a particular UE identity). The attributes of planenedRouteInfo may follow the notation provided in Table 7.

Table 7: properties of PlannedRouteEnfo

Fig. 11 also includes a second process 1102 in which the service consumer requests planned route information for a particular vUE. Process 1102 is a scenario where: the service consumer (e.g., V2X application, MEC application, etc.) sends a request to the VIS to receive the predicted QoS corresponding to the potential route of the vUE and to receive information (e.g., predicted QoS information) that is needed/requested.

Process 1102 begins at operation 1102-1, where a service consumer (or VIS consumer) sends a request message to a VIS as a service producer (or "VIS producer"). In this embodiment, VIS is a resource representing planned route information and/or predicted QoS for the concerned vUE. The (request) message body contains a data structure for predicted QoS related to potential routes of the vehicle UE (discussed below). The request message may be an HTTP POST message with a request line "POST. Here, the resource URI is "{ apiRoot }/vis/v 1/provider _ predicted _ qos". In some embodiments, the request may further include a service consumer instance ID as an input parameter, which may be included in a message body of the request message.

At operation 1102-2, the service producer (e.g., VIS) responds with a response/reply message that includes a message body containing a predicted QoS information data structure (predictedbos). In this embodiment, the response message is an HTTP response message that includes a status code "200 OK" in the header of the HTTP message, which indicates that the service consumer's request was successful. Additionally, the requested predictedfqos is included in the body of the HTTP response message. In some embodiments, the response message may include a predictedQoS IE, a field, a data element, etc. to include a predictedQoS data structure.

In this embodiment, the POST method is used to request a predicted QoS corresponding to a potential route of the vUE. The method supports the URI query parameters, request and response data structures, and response codes specified in table 8.

Table 8: data structure supported by predictedQoS POST request/response

Predictedqs is a resource data type. The predictedqs type represents a predicted QoS of the vehicle UE. This information is based on potential routes per UE. The attributes of predictedqs may follow the notation provided in table 9.

Table 9: properties of predictedQos

In the example of Table 9, the rsrp and rsrq attributes are included in the response message only. In other embodiments, the RSRP and RSRQ attributes may also be included in the request message, and the RSRP and RSRQ values contained therein may be used for trip-specific QoS prediction. These RSRP and RSRQ values may be used, for example, as radio information reported in step 2 of the trip-specific QoS prediction procedure discussed in section ii.a above. In this example, the "RSRP and/or RSRQ values are" marked "with LocationInfo and TimeStamp in the location and time data elements. As previously noted, in other embodiments, other types of measurements may additionally or alternatively be included in the request or response messages.

In some embodiments, a time attribute may be included to indicate an actual time to visit a particular location indicated by LocationInfo or a predicted time at which vUE is expected to visit the particular location. For example, the most forward routeInfo structure relating to the start of a route may include the actual time that the vUE is at the start of a route, while the last routeInfo structure relating to the end of a route may be the predicted or expected time that the vUE will arrive at the end. The intermediate routeInfo structure corresponding to the waypoint locations may include the actual time at which the vUE visited these waypoint locations, the predicted/expected time of arrival at the waypoint locations, or some combination thereof.

Fig. 11 also includes an example process 1103 for requesting PC5 provisioning information, in accordance with various embodiments. In process 1103, a service consumer (or VIS consumer) (e.g., MEC application or MEC platform) sends a request to receive provisioning information for V2X communications over a PC5 interface with respect to a particular location, and the response contains the required information.

Process 1103 begins with operation 1103-1, where a service consumer (or VIS consumer) sends a request message to a service producer (or VIS producer). VIS is a resource that represents PC5 provisioning information. In an embodiment, location information (e.g., a serving cell ID or geographical area information of the UE) is used as an input parameter. In this example, the request message may be an HTTP GET message with the request line "GET. Here, the resource URI is "{ apiRoot }/vis/v1/queries/pc5_ provisioning _ info". In some embodiments, the request may include a service consumer instance ID as an input parameter, which may be included in a message body of the request message.

At operation 1103-2, the service producer (e.g., VIS) responds with a response/reply message that includes a message body containing PC5provisioning information. In one embodiment, the response message is an HTTP response message that includes a status code "200 OK" in the header of the HTTP message, which indicates that the service consumer's request was successful. Additionally, the requested planned route information ("PC 5 ProvisioningInfo") is included in the body of the HTTP response message, for example, in a PC5ProvisioningInfo IE, a field, a data element, or other similar data structure.

In this embodiment, the GET method is used to query provisioning information regarding V2X communications through the PC 5. The method supports the URI query parameters, request and response data structures, and response codes specified in tables 10 and 11.

Table 10: URI query parameter supported by PC5provisioningInfo GET method

Table 11: data structure supported by PC5provisioningInfo GET response

Pc5ProvisioningInfo is a resource data type. The Pc5ProvisioningInfo type indicates provisioning information required for V2X communication through the Pc 5. This information is on a per-location basis (e.g., cell, RSU, WAP/RAP, or geographic area of the base station). The attributes of the Pc5provisioningInfo may follow the notation provided in Table 12 and are defined in [ R04], 3GPP TS 36.300v15.5.0(2019-04-17), 3GPP TS 38.300v15.5.0(2019-04-09), 3GPP TS 36.321v15.5.0(2019-04-11) ("[ R18 ]"), 3GPP TS 38.321v15.5.0(2019-04-09) ("[ R19 ]"), 3GPP TS 31v15.0.5.1(2019-04-22) ("[ R20 ]"), and 3GPP TS 38.331v15.5.1(2019-04-16) ([ R21] ").

Table 12: attributes of Pc5provisioningInfo

The Pc5NeighbourCellInfo attribute in Table 12 may include the PLMN ID, ECGI/NCGI and SystemInformationBlockType21 defined in [ R20] and/or [ R21 ].

According to various embodiments, the service (VIS) consumer uses the provided information to divide the acquired radio quality information according to trip specific criteria (e.g. as described previously). Thus, by processing each radio information partition, trip-specific QoS predictive notifications are sent to the corresponding vUE (e.g., via unicast transmission) or to the cluster of vues (e.g., via multicast transmission), characterized by similar planned routes.

As previously mentioned, PlannedRouteInfo, predictedQos, and Pc5provisioningInfo are all resource data types. A resource is an object having a type, associated data, relationships to other resources, and a set of methods to operate on the resource. Tables 7, 9, and 12 define the data types and attributes that may be used for each of the resource representations. A data type is a particular kind of data item that is defined by the values it can take and/or the operations it can perform. As shown in tables 7, 9, and 12, some of these attributes have: simple data types, where each data item can only store one value at a time (e.g., a string, unsigned integer ("Uint"), etc.); and a structured data type, wherein each data item is a collection of other data items. Some structured data types are defined by attributes listed in the same table (denoted as "structured (inline)"). For example, in Table 9, the routes attributes are structured data types that include one or more routeInfo attributes, and each routeInfo attribute includes a location and time attribute and an rsrp and rsrq attribute (if included in the response message). Some structured data types are common to each resource data type (e.g., TimeStamp data type and locationInfo data type). The attributes of the TimeStamp data type and the locationInfo data type may follow the notation provided in Table 13 and Table 14, respectively.

Table 13: attributes of TimeStamp

Table 14: attributes of LocationInfo

In table 14, "ECGI" refers to an E-UTRAN cell global identifier to globally identify a cell. The ECGI is composed of a Mobile Country Code (MCC), a Mobile Network Code (MNC) and an E-UTRAN cell identifier (ECI). "NCGI" refers to an NR/5G cell global identifier to globally identify a cell, although a gNB may include multiple NCGIs. The NCGI is a concatenation of a PLMN identifier (PLMN-Id) and a 36-bit NR Cell Identity (NCI).

In each of the processes of fig. 11, when the request is unsuccessful, failed, or contains an error, the HTTP response message may contain other HTTP status codes (e.g., a bad request status code (400) (e.g., when an incorrect time parameter is passed in the request), a not found status code (404) (e.g., when a URI provided in the request cannot map to a valid resource URI), a prohibited status code (403) (e.g., when an operation is not permitted given the current status of the resource), and/or other similar HTTP status codes). In the foregoing example, the response body may include a promlemdetails IE, a field, a data element, or other similar data structure that indicates/includes information about the particular error. Other message formats may be used in other embodiments, and the request/response data may be located in a header or body portion of such messages. III example edge computing System configuration and arrangement

Edge computing refers to implementing, coordinating, and using computations and resources at locations closer to the "edge" or "edge" set of the network. Deploying computing resources at the edge of the network may reduce application and network latency, reduce network backhaul traffic and associated energy consumption, improve service capacity, improve compliance with security or data privacy requirements (especially compared to traditional cloud computing), and improve overall owner costs.

A single computing platform or other component (referred to as an "edge computing node," "edge node," etc.) that may perform edge computing operations may reside anywhere required by the system architecture or ad hoc service. In many edge computing architectures, edge nodes are deployed at NANs, gateways, network routers, and/or other devices closer to the endpoint devices (e.g., UEs, IoT devices, etc.) that produce and consume data. As an example, the edge nodes may be implemented in a high performance computing data center or cloud installation; appointing an edge node server, an enterprise server, a roadside server and a telecommunication central office; or a local or peer edge device that is using an edge service.

The edge compute nodes may partition resources (e.g., memory, CPU, GPU, interrupt controller, I/O controller, memory controller, bus controller, network connections or sessions, etc.), where each partition may contain security and/or integrity protection capabilities. An edge node may also provide orchestration of multiple applications through isolated user space instances (e.g., containers, partitions, Virtual Environments (VEs), Virtual Machines (VMs), function as a service (FaaS) engines, servlets, servers, and/or other similar computing abstractions). A container is an inclusive, deployable unit of software that provides the code and required dependencies. Various edge system arrangements/architectures treat virtual machines, containers, and functions equally in terms of application composition. Edge nodes are coordinated based on edge provisioning functions, while the operation of various applications is coordinated through orchestration functions (e.g., VMs or container engines, etc.). Orchestration functions may be used to deploy isolated user-space instances that identify and schedule the use of specific hardware, security-related functions (e.g., key management, trust anchor management, etc.), and other tasks related to the provisioning and lifetime of the isolated user-space.

Applications suitable for edge computing include, but are not limited to, virtualization of legacy network functions including, for example, Software Defined Networking (SDN), Network Function Virtualization (NFV), distributed RAN units and/or RAN clouds, and the like. Additional example use cases for edge computing include computing offload, Content Data Network (CDN) services (e.g., video on demand, content streaming, security monitoring, alarm system monitoring, building access, data/content caching, etc.), gaming services (e.g., AR/VR, etc.), accelerated browsing, IoT and industry applications (e.g., factory automation), media analytics, real-time streaming/transcoding, and V2X applications (e.g., driving assistance and/or autonomous driving applications).

The present disclosure provides specific examples related to edge computing configurations provided in multiple access edge computing (MEC) and 5G network implementations. However, many other standards and network implementations are applicable to the edge and service management concepts discussed herein. For example, the embodiments discussed herein may be applicable to many other edge computing/networking technologies in various combinations and layouts of devices located at the edge of a network. Examples of these other edge computing/networking technologies that may implement embodiments herein include Content Delivery Networks (CDNs) (also referred to as "content delivery networks," etc.); mobile Service Provider (MSP) edge computing and/or mobile as a service (MaaS) provider systems (e.g., used in AECC architecture); a cloud-edge cloud system; a fog calculation system; a Cloudlet edge cloud system; a Mobile Cloud Computing (MCC) system; the central office is re-configured as a data Center (CORD), a mobile CORD (M-CORD) and/or a converged multi-access and core (COMAC) system; and the like. Moreover, the techniques disclosed herein may relate to other internet of things edge network systems and configurations, and other intermediate processing entities and architectures may also be used to practice embodiments herein.

Fig. 13 illustrates a non-roaming 5G system architecture 1300 in a reference point representation in accordance with various embodiments. In fig. 13, the UE 1366 communicates with the RAN 1368 and one or more other 5GC entities. The 5G system 1300 includes a plurality of Network Functions (NFs), such as an access and mobility management function (AMF)1362, a Session Management Function (SMF)1360, a Policy Control Function (PCF)1358, an Application Function (AF)1364, User Plane Functions (UPFs) 1370 and 1374, a Network Slice Selection Function (NSSF)1342, an authentication server function (AUSF)1344, and a Unified Data Management (UDM) 1346. 5G system 1300 also includes an Application Server (AS)1348 and one or more MEC hosts 1336, which may be the same AS or similar to any of MEC hosts 140, 240, 340, 440, 740, 840, 841, 940, and/or 941 previously discussed.

The (R) AN 1368 may be a next generation RAN (NG-RAN) including a plurality of nodes, such as a next generation node B (gnb) and a NG evolved node B (NG-eNB). AMF 1362 and UPF 1370 may be communicatively coupled to the gNB and/or NG-eNB via respective NG interfaces (not shown). The gNB includes a node providing NR/5G user plane terminations and control plane terminations towards the UE 1366, and the NG-eNB includes a node providing evolved universal terrestrial radio access (E-UTRA) user plane and control plane protocol terminations towards the UE 1366 and connected to the 5GC via an NG interface. In particular, the gNB and/or NG-eNB may connect to AMF 1362 via a NG-C interface and to UPF 1370 via a NG-U interface. The gNB and NG-eNB may be coupled to each other via respective Xn interfaces. The NG-RAN may also use the reference points between various nodes provided by 3GPP TS 23.501v16.0.2(2019-04-01) ("[ R14 ]").

The UPFs 1370, 1374 serve as anchor points for intra-RAT and inter-RAT mobility. An external PDU session point interconnected with a local Data Network (DN)1372 and/or a central DN 1376, any of which may include, for example, operator services, internet access, or third party services. The DNs 1372, 1376 may include or be similar to the application server 1348 discussed previously. The UPFs 1370, 1374 may also perform packet routing and forwarding, perform packet inspection, perform user plane part of policy rules, lawful intercept packets, perform traffic usage reporting, perform QoS processing of the user plane, perform UL traffic validation, transport level packet marking in UL and DL, and perform DL packet caching and DL data notification triggering. The UPF 1370 may interact with the SMF 1360 via an N4 reference point between SMFs 1360. A UPF 1370 may be connected to another UPF 1374 via an N9 interface, with the other UPF 1374 being connected to the central DN 1376 via an N6 interface. The UPFs 1370, 1374 may be deployed in one or more configurations according to a desired service type.

The AUSF 1344 stores data for authenticating the UE 1366 and processes authentication-related functions. The AUSF 1344 may facilitate a universal authentication framework for various access types. AUSF 1344 may communicate with AMF 1362 via an N12 reference point between AMF 1362 and AUSF 1344; and may communicate with UDM 1346 via an N13 reference point between UDM 1346 and AUSF 1344. Additionally, AUSF 1344 can exhibit Nausf SBI.

The UDM 1346 processes subscription-related information (e.g., subscriber profiles and data) to support network entities handling communication sessions (similar to the HSS in 4G systems). Subscription data may be passed between UDM 1346 and AMF 1362 via the N8 reference point. The UDM 1346 may interact with the SMF 1360 via the N10 reference point. The UDM 1346 may also be coupled to the AS 1348 through the Sh reference point. AS 1348 may be or include a Telephony Application Server (TAS), an MEC host (e.g., MEC host 140, 240, 340, 440, 740, 840, 841, 940, and/or 941 discussed above, or the same or similar to MEC host 1336). The 5G system 1300 may use one or more MEC hosts 1336 to provide interfacing and offloading processing of wireless communication traffic. For example, and as shown in fig. 13, the MEC host 1336 may provide a connection between the RAN 1368 and the UPF 1370 in the 5 GC. MEC host 1336 may use one or more NFV instances instantiated on a virtualization infrastructure within MEC host 1336 to handle wireless connections to and from RAN 1368 and UPF 1370.

The AMF 1362 is responsible for registration management (e.g., for registering the UE 1366 with the 5G network), connection management, reachability management, mobility management, and access authentication and authorization. The AMF 1362 is responsible for termination of the RAN control plane and NAS procedures, and thus, the AMF 1362 is the termination point of the RAN Control Plane (CP) interface (N2 reference point) and is also the termination point of non-access stratum (NAS) signaling with the UE 1366 (N1 reference point). AMF 1362 is also responsible for protecting the integrity of signaling, interfacing with any intercept functions for access and mobility events, providing authentication and authorization for the access layer, and hosting the security anchor function (SEAF). The AMF 1412 provides communication and reachability services for other NFs, and it may allow subscriptions to receive notifications about mobility events. The AMF 1362 also assigns external parameters (e.g., predicted UE behavior parameters or network configuration parameters).

The AMF 1362 is also a termination point for the N11 reference point, and the N11 reference point is used to interact with the SMF 1360, which allows the AMF 1362 to provide transport for Session Management (SM) messages between the UE 1366 and the SMF 1360. AMF 1362 may also provide transport for SMS messages between UE 1366 and a Short Message Service Function (SMSF) (not shown in fig. 13). The SMSF is responsible for SMS subscription checking and verification, and relaying SM messages to/from UE 1366 to/from other SMS entities. AMF 1362 is also the termination point of the N14 reference point between two AMFs 1362 and the N17 reference point between AMFs 1362 and 5G-EIRs (not shown in FIG. 13). In addition to the functions of the AMF described above, the AMF may also include [ R14] and other functions described in 3GPP TS 23.503v16.0.0 (2019-03-26).

SMF 1360 may be responsible for SM functions (e.g., session establishment, modification, and release, including tunnel maintenance between UPF 1370 and (R) AN 1368); IP address assignment and management (including optional authorization); a Dynamic Host Configuration Protocol (DHCP) service; (re) select and control the UPF 1370; configuring traffic steering rules at UPF 1370 to route the traffic crew to the correct destination; intercepting an SM event; terminating an interface towards a policy control function; controlling a portion of policy enforcement and QoS; the SM part of the terminating NAS message; a DL data notification; initiating (R) AN 1368 specific SM information, which is sent to (R) AN 1368 via AMF 1362 through N11 and then through N2; and determining an SSC pattern for the session. SM may refer to the management of PDU sessions, and a PDU session or "session" may refer to a PDU connection service that provides or enables the exchange of PDUs between UE 1366 and DNs 1372, 1376 identified by a Data Network Name (DNN). Since MEC services may be provided in both centralized and distributed edge systems, SMF 1414 may be configured to: selects and controls UPF 1370 and configures its rules for traffic steering. SMF 1414 is also configured to: the open services operate to allow the MEC to manage PDU sessions, control policy settings and traffic rules as 5G AF 1364, and subscribe to notifications on session management events.

The PCF 1358 provides policy rules to CP functions to enforce them and also supports a unified policy framework to manage network behavior (similar to PCRF in 4G systems). PCF 1358 may communicate with AMF 1362 via the N15 reference point. PCF 1358 may communicate with AF 1364 via the N5 reference point and with SMF 1360 via the N7 reference point.

AF 1364 provides application impact on traffic routing, provides access to NEFs (e.g., NEF 1418 of fig. 14) and interacts with the policy framework for policy control. AF 1364 may send a request to affect SMF 1360 routing decisions for traffic of the PDU session. The AF 1364 request may affect the UPF 1370, 1374 (re) selection and allow user traffic to be routed to local access to the DN 1372, 1376 (identified by DNAI). For edge computing, operator and third party services are hosted near AN attachment access point (e.g., (R) AN 1368) of the UE 1366 in order to achieve efficient service delivery by reducing e2e latency and load on the transport network. The 5GC selects UPFs 1370, 1374 near the UE and performs traffic steering from the UPFs 1370, 1374 to the local DN 1372 via an N6 interface. This may be based on the UE's subscription data, UE location, information from AF 1364, policy, and/or other relevant business rules. Some AFs 1364 may not be allowed direct access to the NFs and must interact with the relevant NFs via NEF 1418 using an external open framework.

The NSSF 1342 selects a set of network slice instances for serving UE 1366. The NSSF 1342 may also determine allowed NSSAIs and mappings to subscribed S-NSSAIs, if desired. The NSSF 1342 may also determine the set of AMFs 1362 or list of candidate AMFs 1362 to be used to serve the UE 1366 based on a suitable configuration, and possibly by querying the NRFs (see, e.g., NRF 1420 of fig. 14). Selection of a set of network slice instances for UE 1366 may be triggered by AMF 1362 with which UE 1366 registers by interacting with NSSF 1342, which may result in a change in AMF 1362. NSSF 1342 may interact with AMF 1362 via the N22 reference point between AMF 1362 and NSSF 1342; and may communicate with another NSSF 1342 in the visited network via an N31 reference point (not shown). Additionally, NSSF 1342 may exhibit NSSF SBI.

Fig. 13 shows a reference point representation for a 5G network. The reference point representation shows that there may be interactions between the corresponding NF services. FIG. 13 includes the following reference points: n1 (between UE 1366 and AMF 1362), N2 (between RAN 1368 and AMF 1362), N3 (between RAN 1368 and UPF 1370), N4 (between SMF 1360 and UPF 1370), N5 (between PCF 1358 and AF 1364), N6 (between UPF 1370 and DN 1372, 1376), N7 (between SMF 1360 and PCF 1358), N8 (between UDM 1346 and AMF 2), N9 (between UPF 1370 and 1374), N10 (between UDM 1346 and SMF 1360), N11 (between AMF 1362 and SMF 1360), N12 (between AUSF 1344 and AMF 1362), N13 (between AUSF 1344 and UDM 1346), N14 (between two AMF 632), N15 (between aff 1344 and AMF 1362), N13 (between amsf 1358 and PCF 1362), or between aff 1 16 and PCF 1362, in a non-visited scenario, between amsf 1358, between aff 13535, between aff 1358, between aff 13535, not shown) and N22 (between AMF 1362 and NSSF 1344). There may be more reference points between NFs; however, for clarity, these reference points have been omitted from fig. 13. Furthermore, 5G system 1300 may also include other elements not shown in fig. 13, such as data storage systems/architectures, 5G-EIR, SEPP, SMSF, etc.

Fig. 14 shows a non-integrated MEC deployment 14A comprising a 5G services based architecture 1400 and a MEC architecture 1490, and an integrated MEC deployment 14B comprising a MEC system 1491 in a 5G network 1401, wherein some functional entities of the MEC system 1491 interact with NFs of the 5G network. Referring to deployment 14A, the 5G system architecture 1400 is shown in a service-based representation and may be substantially similar (or identical) to the system architecture 1300 of fig. 13. For example, the 5G system architecture 1400 includes the following entities, which are also present in the system architecture 1400: NSSF 1416, PCF 1422, UDM 1424, AF 1426, AUSF 1410, AMF 1412, SMF 1414, UE 1402, RAN 1404, UPF 1406, and DN 1480. In addition to these network entities, the 5G system architecture 2800 includes a network open function (NEF)1418 and a Network Repository Function (NRF) 1420. The 5G system architecture may be service-based and interactions between NFs may be represented by corresponding point-to-point reference points Ni (as shown in fig. 13) or SBI (as shown in fig. 14).

The 5G system 1400 in fig. 14 is a service-based representation for representing NFs within a CP that enable other authorized NFs to access their services. The 5G system 1400 includes the following service-based interfaces (SBIs): namf (SBI shown by AMF 1412), Nsmf (SBI shown by SMF 1414), Nnef (SBI shown by NEF 1318), Npcf (SBI shown by PCF 1422), Nudm (SBI shown by UDM 1424), Naf (SBI shown by AF 1426), Nnrf (SBI shown by NRF 1420), Nnssf (SBI shown by NSSF 1416), Nausf (SBI shown by AUSF 1410). Other SBIs (e.g., Nudr, N5g-eir, and Nudsf) not shown in fig. 14 may also be used.

NEF 1318 provides a means for securely providing services and capabilities for open 3GPP NFs such as third party, internal open/reopen AF 1464, edge computing or fog computing systems. NEF 1318 may authenticate, authorize, and/or throttle AF 1464. NEF 1318 may also translate information exchanged with AF 1464 and information exchanged with internal NFs. NEF 1318 may also receive information from other NFs based on their ability to open. This information may be stored as structured data at NEF 1318 or at data store NF using a standardized interface. The stored information may then be re-opened by the NEF 1318 to other NFs and AFs, and/or used for other purposes, such as analysis. In this example, the NEF 1318 provides an interface to the MEC hosts in the MEC systems 1490, 1491 that may be used to handle wireless connections with the RAN 1404.

The NRF 1420 supports a service discovery function, receives NF discovery requests from NF instances or SCPs 1428, and provides the NF instances or SCPs 1428 with information of NF instances that have been discovered (or are to be discovered). NRF 1420 maintains NF profiles of available NF instances and the services that they support (e.g., IP address of NF instance ID, NF type, PLMN ID, FQDN or NF, NF capability information, NF priority information, etc.). SCP 1428 (or various instances of SCP 1428) supports indirect communication between two or more NFs (see, e.g., [ R14] section 7.1.1); delegated discovery (see, e.g., [ R14] section 7.1.1); message forwarding and routing to a destination NF/NF service, communication security (e.g., authorization of NF service consumers to access NF service producer APIs) (see, e.g., 3GPP TS 33.501), load balancing, monitoring, overload control, etc.; and discovery and selection functions of UDM, AUSF, UDR, PCF, wherein subscription data stored in UDR is accessed based on SUPI, suii or GPSI of the UE (see e.g., [ R14] section 6.3). The load balancing, monitoring, overload control functions provided by the SCP 1428 may be implementation specific. The SCP 1428 may be deployed in a distributed manner. There may be multiple SCPs 1428 in the communication path between multiple NF services. The SCP 1428, although not an NF instance, may also be distributively, redundantly, and extendably deployed.

MEC system 1490 may include an MEC orchestrator 1470 (operating at a system level) and the following MEC entities operating at a distributed host level: one or more applications 1472, one or more services 1474, virtualization infrastructure 1476, MEC platform 1478, and MEC platform manager 1480. The components of MEC system 1490 are discussed in more detail below.

Integrated MEC deployment 14B includes the same MECs and 5GC NFs as in non-integrated deployment 14A discussed previously. In this implementation, the integrated MEC deployment 14B is located at least partially within the 5G network 1401. The 5G network 1401 is the same as or similar to the 5G system 1400, however, not all NFs in the 5G network 1401 are shown. The integrated MEC deployment 14B may be configured using one or more of the following techniques: (1) local routing and traffic steering; (2) AF 1426 affects the capability of UPF 1406 (re) selection and traffic routing, either directly via PCF 1422 or indirectly via NEF 1418 (depending on the operator's policy); (3) session and Service Continuity (SSC) mode for UE 1402 and application mobility scenarios; (4) the 5G network 1401 supports a Local Area Data Network (LADN)1408 by providing support for connection to the LADN 1408 in certain areas where applications 1472 are deployed. Access to the LADN 1408 may be available in a particular LADN service area (defined as a set of tracking areas in the UE's serving PLMN). The LADN 1408 may be configured as a service provided by the UE's serving PLMN. For local routing and traffic steering, the 5G network 1401 may be configured to select traffic to be routed to an application 1472 in the LADN 1408, which LADN 1408 may be part of the MEC system 1491. The PDU session may have multiple N6 interfaces towards the data network 1408. The UPF 1406 terminating these interfaces may be configured to support PDU session anchor functionality. Traffic steering by the UPF 1406 is supported by a UL classifier operating on a set of traffic filters matching the steered traffic, or alternatively by IPv6 multi-homing, where multiple IPv6 prefixes have been associated with the PDU session in question.

The NFs within the 5G network 1401 and their generated services are registered in the NRF 1420, while in the MEC system 1491, the services generated by the MEC application 1472 are registered in the service registration of the MEC platform 1478. The service registration may be part of the application enablement function. To use a service, the NF may interact directly with the NF that generated the service, if authorized. A list of available MEC services may be discovered from NRF 1420. Some services may be accessed via NEF 1418, NEF 1418 also being available to untrusted entities outside the domain to access the services. In other words, NEF 1418 can serve as a centralized point of service opening and also have a critical role in authorizing all access requests originating outside the system. Authentication related procedures may be served by the AUSF 1410.

The 5G network 1401 may use network slices, which allows the required features and resources from the available NFs to be allocated to different services or tenants that are using these services. A Network Slice Selection Function (NSSF)1416 may be configured to help select the appropriate network slice instance for the user and help allocate the necessary AMFs 1412. MEC application 1472 (e.g., an application hosted in a distributed cloud of MEC system 1490) may belong to one or more network slices that have been configured in 5G network 1401.

PCF 1422 is also a function of AF 1426 (e.g., MEC platform 1478) requesting its services to affect traffic steering rules. PCF 1422 may be accessed directly or via NEF 1418, depending on whether AF 1426 is considered trusted and, in the case of traffic steering, whether the corresponding PDU session is known at the time of request. UDM 1424 is responsible for services related to users and subscriptions. For example, UDM 1424 may be configured to: generating 3GPP Authentication and Key Agreement (AKA) authentication credentials, processing user identity related information, managing access authorization (e.g., roaming restrictions), registering users of the service NF (serving AMF 1412, SMF 1414), supporting service continuity by keeping a record of SMF/DNN assignments, supporting intercept procedures in outbound roaming by acting as a contact point, and performing subscription management procedures.

The UPF 1406 may be configured to facilitate integrated MEC deployment in the 5G network 1401. From the perspective of the MEC system 1491, the UPF 1406 may be considered a distributed and configurable data plane. Control of the data plane (e.g., in a traffic rule configuration) may follow the NEF-PCF-SMF communication route. Thus, the local UPF 1406 may be part of a MEC implementation as shown in deployment 14B.

MEC orchestrator 1470 in deployment 14B is an MEC system level functional entity that acts as an AF, may interact with NEF 1418, or in some scenarios, directly with target 5G NF. At the distributed host level (or "MEC host level"), MEC platform 1478 may be configured to interact with the 5G NF, also playing the role of AF 1426. The MEC host (see, e.g., MEC host 1502 in fig. 15) and/or other host-level functional entities may be deployed in a data network (e.g., 1408) in a 5G system. While NEF 1418, which is a 5GC NF, is a system-level entity that is centrally deployed with similar NFs, instances of NEF 1418 may also be deployed at the edge to allow low-latency, high-throughput service access from MEC hosts.

In deployment 14B, the MEC system 1491 is deployed on the N6 reference point of the UPF 1406, which may be in the data network 1408 outside of the 5G system 1401. This functionality may be achieved through the flexibility of locating the UPF 1406. In addition to MEC application 1472, the distributed MEC host may also host another MEC platform service that acts as a message broker for MEC platform service 1474 and directs traffic to local accelerators. The choice of whether to run the service as an MEC application or as a platform service may be implementation specific and may take into account the level of sharing and authentication required to access the service. MEC services, such as message brokers, may be initially deployed as MEC applications 1472 and then available as MEC platform services 1474.

The MEC hosts of MEC system 1491 are deployed in an edge or central data network. The UPF 1406 may be configured to manage to direct user plane traffic to a target MEC application 1472 in the DN 1408. The locations of the DN 1408 and UPF 1406 are network operator choices, and the network operator may choose to place physical computing resources based on technical and business parameters, such as available site facilities, supported applications and their requirements, measured or estimated user load, and the like. An MEC management system orchestrating the operation of MEC hosts and applications may dynamically decide where to deploy MEC applications 1472. In terms of physical deployment of MEC hosts, the following options may be used in different aspects: (1) the MEC host and the local UPF 1406 are co-sited with the base station of the base station edge layer; (2) the MEC host is co-sited with a transport node that may include a local UPF 1406; (3) the MEC host and local UPF 1406 are co-sited with the network aggregation point; (4) the MEC hosts are co-located (e.g., in the same data center) with the 5G core NF.

Fig. 15 shows an MEC system reference architecture (or MEC architecture) 1500 that provides functionality according to R05. MECs provide cloud computing functionality and IT service environments for application developers and content providers at the edge of the network. The environment is characterized by ultra-low latency and high bandwidth, as well as real-time access to radio network information that is available to applications. MEC technology allows flexible, rapid deployment of innovative applications and services to mobile subscribers, enterprises and vertically subdivided markets. In particular, in the automotive field, applications such as V2X (e.g., IEEE 802.11p based protocols (e.g., DSRC/ITS-G5), or 3GPP C-V2X based protocols) require exchanging data, providing data to aggregation points, and accessing data in databases that provide an overview of local conditions derived from a large number of sensors (by various automobiles, roadside units, etc.).

The MEC architecture 1500 includes a MEC host 1502, a Virtualization Infrastructure Manager (VIM)1508, a MEC platform manager 1506, a MEC orchestrator 1510, an Operations Support System (OSS)1512, a user application agent 1514, UE applications 1518 running on UEs 1520, and a CFS portal 1516. MEC host 1502 may include MEC platform 1532 with filter rule control component 1540, DNS processing component 1542, service registration 1538, and MEC service 1536. The MEC service 1536 may include at least one scheduler that may be used to select resources for instantiating the MEC application (or NFV)1526 on the Virtualization Infrastructure (VI) 1522. The MEC application 1526 may be configured to provide services 1530 (which may include handling different types of network communication traffic associated with one or more wireless connections (e.g., connections to one or more RAN or core network functions)) and/or some other services, such as those discussed herein. Other MEC hosts 1502 may have the same or similar configuration/implementation as MEC hosts 1502, and other MEC applications 1526 instantiated within other MEC hosts 1502 may be similar to MEC applications 1526 instantiated within MEC hosts 1502. VI 1522 includes a data plane 1524 coupled to MEC platform 1522 via an MP2 interface. Additional interfaces between the various network entities of the MEC architecture 1500 are shown in fig. 15.

MEC system 1500 includes three sets of reference points, including an "Mp" reference point for MEC platform functionality; an "Mm" reference point, which is a management reference point; and an "Mx" reference point connecting the MEC entity to an external entity. The interface/reference point in the MEC system 1500 may comprise an IP-based connection and may be used to provide representational state transfer (REST or RESTful) services, and the messages communicated using the reference point/interface may be XML, HTML, JSON, or some other desired format, such as the formats discussed herein. In other embodiments, suitable authentication, authorization, and accounting (AAA) protocols, such as radius or diameter protocols, may also be used for communication over the reference point/interface.

The logical connections between the various entities of MEC architecture 1500 may be access agnostic and independent of the particular deployment. MEC enables the MEC application 1526 to be implemented as a pure software entity running on top of a VI 1522 located at or near the edge of the network. MEC application 1526 is an application that may be instantiated on MEC host 1502 within MEC system 1500 and that may potentially provide or consume MEC services 1536.

The MEC entities shown in fig. 15 may be grouped into MEC system-level entities, MEC host-level entities, and network-level entities (not shown). The network level (not shown) includes various external network level entities such as a 3GPP network, a local area network (e.g., LAN, WLAN, PAN, DN, LADN, etc.), and an external network. The MEC system level includes a MEC system level management entity and a UE 1520 and is discussed in more detail below. The MEC host level includes one or more MEC hosts 1502, 1504 and MEC management entities that provide functionality to run MEC applications 1526 within a carrier network or a subset of a carrier network. The MEC management entity includes various components that handle management of MEC-specific functions of a particular MEC platform 1532, MEC host 1502, and MEC application 1526 to be run.

The MEC platform manager 1506 is an MEC management entity that includes a MEC platform element management component 1544, a MEC application rules and requirements management component 1546, and a MEC application lifetime management component 1548. Various entities within MEC architecture 1500 may perform the functions discussed in [ R05 ]. The remote application 1550 is configured to: communicate with MEC host 1502 (e.g., with MEC application 1526) via MEC orchestrator 1510 and MEC platform manager 1506.

MEC host 1502 is an entity that contains MEC platforms 1532 and VI 1522, which provide computing, storage, and network resources for running MEC application 1526. VI 1522 includes a Data Plane (DP)1524 that executes business rules 1540 received by MEC platform 1532 and routes traffic between MEC application 1526, MEC services 1536, DNS servers/proxies (see, e.g., via DNS processing entity 1542), 3GPP network, local network, and external networks. The MEC DP 1524 may be connected to the (R) AN node and the 3GPP core network, and/or may be connected to the access point via a broader network (e.g., the internet, AN enterprise network, etc.).

MEC platform 1532 is a collection of basic functions required to run MEC applications 1526 on a particular VI 1522 and enable them to provide and consume MEC services 1536, and may itself provide multiple MEC services 937 a. MEC platform 1532 may also provide various services and/or functionality, such as providing an environment in which MEC applications 1526 are able to discover, advertise, consume, and provide MEC services 1536 (discussed below), including MEC services 1536 available via other platforms when supported. MEC platform 1532 may be capable of allowing authorized MEC applications 1526 to communicate with third party servers located in external networks. MEC platform 1532 may receive business rules from MEC platform manager 1506, an application or service, and indicate the data plane accordingly (see, e.g., business rule controls 1540). MEC platform 1532 may send instructions to DP 1524 within VI 1522 via the Mp2 reference point. The Mp2 reference point between MEC platform 1532 and DP 1524 of VI 1522 may be used to indicate how DP 1534 routes traffic between applications, networks, services, etc. MEC platform 1532 may translate the token representing UE 1520 in the traffic rule to a specific IP address. The MEC platform 1532 also receives DNS records from the MEC platform manager 1506 and configures the DNS proxy/server accordingly. MEC platform 1532 hosts MEC service 1536, which includes the multiple access edge services discussed below, and provides access to persistent storage and time information. In addition, MEC platform 1532 may communicate with other MEC platforms 1532 of other MEC servers 1502 via the Mp3 reference point.

VI 1522 represents the sum of all hardware and software components that build the deployment, management, and execution MEC application 1526 and/or MEC platform 1532 legal environment. The VI 1522 may span several locations and the network providing the connections between these locations is considered to be part of the VI 1522. The physical hardware resources of VI 1522 include computing resources, storage resources, and network resources that provide processing, storage, and connectivity to MEC applications 1526 and/or MEC platform 1532 through virtualization layers (e.g., hypervisors, VM monitors (VMMs), etc.). The virtualization layer may abstract and/or logically divide the physical hardware resources of the MEC server 1502 into hardware abstraction layers. The virtualization layer may also enable software that implements MEC application 1526 and/or MEC platform 1532 to use underlying VI 1522 and may provide virtualized resources to MEC application 1526 and/or MEC platform 1532 so that MEC application 1526 and/or MEC platform 1532 may be executed.

MEC application 1526 is an application that may be instantiated on MEC host/server 1502 within MEC system 1500 and that may potentially provide or consume MEC service 1536. The term "MEC service" refers to a service provided via MEC platform 1532 through MEC platform 1532 itself or through MEC application 1526. MEC application 1526 may run as a VM on top of VI 1522 provided by MEC server 1502 and may interact with MEC platform 1532 to consume and provide MEC services 1536. The Mp1 reference point between MEC platform 1532 and MEC application 1526 is used to consume and provide service specific functionality. Mp1 provides service registration 1538, service discovery, and communication support for various services (e.g., MEC service 1536 provided by MEC host 1502). Mp1 may also provide application availability, session state relocation support procedures, business rule and DNS rule activation, access to persistent storage and time information, etc.

The MEC application 1526 is instantiated on the VI 1522 of the MEC server 1502 based on a configuration or request validated by the MEC management (e.g., MEC platform manager 1506). MEC application 1526 may also interact with MEC platform 1532 to perform certain support procedures related to the lifetime of MEC application 1526, such as indicating availability, preparing for relocation of user status, and the like. The MEC application 1526 may have a number of rules and requirements associated with them, such as required resources, maximum latency, required or useful services, and the like. These requirements may be verified by MEC management and, if missing, may be assigned to default values. MEC service 1536 is a service that is provided and/or consumed by MEC platform 1532 and/or MEC application 1526. Service consumers (e.g., MEC applications 1526 and/or MEC platform 1532) may communicate with a particular MEC service 1536 through various APIs, including MEC V2X API and other MEC APIs discussed herein. When provided by an application, MEC service 1536 may register with MEC platform 1532 through an Mp1 reference point in a list of services in service registration 1538. Further, MEC application 1526 may subscribe to one or more services 1530/1536 for which it is authorized through the Mp1 reference point.

Examples of MEC services 1536 include VIS, RNIS [ R09], LS [ R10], UE _ ID services [ R11], BWMS [ R12], WAIS, FAIS [ R13], and/or other MEC services. When available, the RNIS provides radio network related information to the authorized MEC application 1526 and opens up the appropriate up-to-date radio network information to the MEC application 1526. The RNI may include radio network conditions, measurements and statistics related to the user plane, information related to UEs 1520 served by radio nodes associated with the MEC host 1502 (e.g., UE context and radio access bearers), changes in information related to UEs 1520 served by radio nodes associated with the MEC host XE136, and the like. The RNI may be provided at a related granularity (e.g., per UE 1520, per cell, per time period).

Service consumers (e.g., MEC applications 1526, MEC platform 1532, etc.) may communicate with the RNIs through the RNI API to obtain context information from the corresponding RAN. The RNI may be provided to the service consumer via a NAN (e.g., (R) AN node, RRH, AP, etc.). The RNI APIs may support query and subscription (e.g., publish/subscribe) based mechanisms that are used on a representation state transition (RESTful) API or on a message broker (not shown) of the MEC platform 1532. The MEC application 1526 may query for information about the message broker via a transport information query process, where transport information may be pre-provisioned to the MEC application 1526 via a suitable configuration mechanism. The various messages passed via the RNI API may be in XML, JSON, Protobuf, or some other suitable format.

The VIS provides support for various V2X applications, including trip-aware QoS prediction according to various embodiments discussed herein. The RNI may be used by MEC applications 1526 and MEC platform 1532 to optimize existing services and provide new types of services based on up-to-date information of radio conditions. As an example, the MEC application 1526 may use the RNI to optimize current services, such as video throughput guidance. In throughput guidance, the radio analysis MEC application 1526 may use the MEC service to provide a back-end video server with a near real-time indication of the estimated throughput available at the radio DL interface at the next time. The throughput guidance radio analysis application computes throughput guidance based on the required radio network information it obtains from the multi-access edge service running on the MEC server 1502. The RNI may also be used by the MEC platform 1532 to optimize mobility procedures needed to support service continuity, for example, when a certain MEC application 1526 requests a piece of information using a simple request-response model (e.g., using a RESTful mechanism), while other MEC applications 1526 subscribe to multiple different notifications of information changes (e.g., using a publish/subscribe mechanism and/or a message broker mechanism).

When available, the LS may provide location related information to the authorized MEC application 1526 and open such information to the MEC application 1526. With location-related information, MEC platform 1532 or one or more MEC applications 1526 performs active device location tracking, location-based service recommendations, and/or other similar services. The LS supports a location retrieval mechanism, e.g. reporting location only once per location information request. LS supports a location subscription mechanism, e.g., location can be reported periodically or multiple times based on a particular event (e.g., a location change) for each location request. The location information may include, among other things, the location of a particular UE 1520 currently served by a radio node associated with MEC server 1502, information about the locations of all UEs 1520 currently served by radio nodes associated with MEC server XE136, information about the locations of a particular class of UEs 1520 currently served by radio nodes associated with MEC server XE136, a list of UEs 1520 in a particular location, information about the locations of all radio nodes currently associated with MEC master 1502, and so on. The location information may be in the form of a geographic location, Global Navigation Satellite Service (GNSS) coordinates, cell Identity (ID), and the like. The LS may be accessed through an API defined in the Open Mobile Alliance (OMA) specification "RESTful Network API for Zonal Presence" OMA-TS-REST-NetAPI-ZonalPresence-V1-0-20160308-C. The regional presence service utilizes the concept of "regions" where regions facilitate grouping of all radio nodes associated with MEC hosts 1502, or a subset thereof, according to a desired deployment. In this regard, the OMA zone presence API provides the MEC application 1526 with a means to obtain information about the zone, the access points associated with the zone, and the users connected to the access points. In addition, the OMA area presence API allows authorized applications to subscribe to a notification mechanism, reporting user activity within an area. The MEC server 1502 may use the OMA zone presence API to access location information or zone presence information for individual UEs 1520 to identify the relative location or position of the UEs 1520.

BWMS provides bandwidth allocation to certain traffic routed to and from MEC application 1526 and specifies static/dynamic upstream/downstream bandwidth resources, including bandwidth size and bandwidth priority. MEC application 1526 may use BWMS to update/receive bandwidth information to/from MEC platform 1532. Different MEC applications 1526 running in parallel on the same MEC server 1502 may be allocated specific static, dynamic upstream/downstream bandwidth resources, including bandwidth size and bandwidth priority. BWMS includes a bandwidth management (BWM) API to allow registered applications to statically and/or dynamically register specific bandwidth allocations per session/application. The BWM API includes HTTP protocol binding of BWM functions using RESTful services or some other suitable API mechanism.

The purpose of the UE identity feature is to allow UE-specific business rules in the MEC system 1500. When MEC system 1500 supports UE identity features, MEC platform 1532 provides functionality (e.g., UE identity APIs) for MEC applications 1526 to register tags on behalf of UEs 1520 or lists of tags on behalf of individual UEs 1520. Each tag is mapped to a specific UE 1520 in the MNO's system, and the MEC platform 1532 is provided with the mapping information. The UE identity tag registration triggers the MEC platform 1532 to activate the corresponding business rules 1540 linked to the tag. MEC platform 1532 also provides functionality (e.g., a UE identity API) for MEC application 1526 to invoke a deregistration procedure to disable or otherwise stop using business rules for that user.

The WAIS is a service that provides WLAN access related information to service consumers within the MEC system 1500. WAIS is available for authorized MEC applications 1526 and is found through the Mp1 reference point specified in [ R03 ]. The granularity of the WLAN access information may be adjusted based on parameters such as information per station, per NAN/AP, or per multiple AP (multi-AP). The service consumer may use the WLAN access information to optimize existing services and provide new types of services based on up-to-date information from the WLAN AP (possibly in combination with information such as the RNI or fixed access network information). WAIS defines protocols, data models, and interfaces in the form of RESTful APIs. Information about the AP and client stations may be requested by queries or by subscribing to notifications, each notification including attribute-based filtering and an attribute selector.

The FAIS is a service that provides fixed access network information (or FAI) to service consumers within the MEC system 1500. FAIS is available for authorized MEC applications 1526 and is discovered through the Mp1 reference point. The FAI may be used by the MEC application 1526 and MEC platform 1532 to optimize existing services and provide new types of services based on up-to-date information from fixed access (e.g., NAN) (possibly in conjunction with other information such as RNI or WLAN information from other access technologies). The service consumer interacts with the FAIs through the FAI API to obtain context information from the fixed access network. Both MEC application 1526 and MEC platform 1532 may consume FAIS; and MEC platform 1532 and MEC application 1526 may both be providers of FAI. The FAI API supports queries and subscriptions (publish/subscribe mechanisms) used on the RESTful API or on alternate transports (e.g., message buses). Alternative transmissions may also be used.

The MEC management includes MEC system level management and MEC host level management. The MEC management includes an MEC platform manager 1506 and a VI manager (VIM)1508, and handles management of MEC-specific functions of the specific MEC server 1502 and applications running thereon. In some implementations, some or all of the multiple access edge management components may be implemented by one or more servers located at one or more data centers and may use a virtualization infrastructure that is connected to or uses the same hardware as the NFV infrastructure used to virtualize NFs.

The MEC platform manager 1506 is responsible for managing the lifetime of the application, including notifying the MEC orchestrator (MEC O)1510 of relevant application related events. MEC platform manager 1506 may also provide MEC platform element management functions 1544 to MEC platform 1532, manage MEC application rules and requirements 1546 (including service authorization, business rules, DNS configuration, and conflict resolution), and manage MEC application lifetime management 1548. The MEC platform manager 1506 may also receive virtualized resources, fault reports, and performance measurements from the VIM 1508 for further processing. The Mm5 reference point between MEC platform manager 1506 and MEC platform 1532 is used to perform the configuration of platform configurations, MEC platform element management 1544, MEC applications and requirements 1546, configuration of MEC application lifetime management 1548, and management of application relocation.

The VIM 1508 may be an entity that allocates, manages, and releases the virtualized (computing, storage, and network) resources of the VI 1522 and prepares the VI 1522 to run software images. To this end, the VIM 1508 may communicate with the VI 1522 through the Mm7 reference point between the VIM 1508 and the VI 1522. Preparing VI 1522 may include configuring VI 1522, and receiving/storing software images. When supported, VIM 1508 can provide fast provisioning of applications as described in "Openstack + + for Cloudlet Deployments" available at http:// reports-archive.adm.cs.cmu.edu/anon/2015/CMU-CS-15-123. pdf. The VIM 1508 may also collect and report performance and failure information about virtualized resources and perform application relocation when supported. For application relocation from/to an external cloud environment, the VIM 1508 may interact with an external cloud manager to perform application relocation, e.g., using the mechanisms described in "Adaptive VM Handoff Across clouds," and/or possibly through a proxy. Further, the VIM 1508 may communicate with the MEC platform manager 1506 via an Mm6 reference point, and an Mm6 reference point may be used to manage virtualized resources, e.g., to implement application lifetime management. Further, VIM 1508 may communicate with MEC O1510 via an Mm4 reference point, and an Mm4 reference point may be used to manage virtualized resources of MEC server 1502, as well as to manage application images. Managing virtualized resources may include tracking available resource capacity, and the like.

MEC system level management includes MEC O1510, which has an overview of the complete MEC system 1500. MEC-O1510 may maintain an overall view 1536 of MEC system 1500 based on the deployed MEC hosts 1502, available resources, available MEC services, and topology. The Mm3 reference point between MEC-O1510 and MEC platform manager 1506 may be used for management of application lifetimes, application rules and requirements, and to track available MEC services 1536. MEC-O1510 may communicate with user application lifetime management agent (UALMP)1514 via Mm9 reference point in order to manage MEC application 1526 requested by UE application 1518.

MEC-O1510 may also be responsible for the online of application packages, including checking the integrity and authenticity of the packages, verifying application rules and requirements and adjusting them if necessary to comply with operator policies, keeping records of the online packages, and preparing VIM 1508 to process the application. MEC-O1510 may select an appropriate MEC host 901 for application instantiation based on constraints such as latency, available resources, and available services. MEC-O1510 can also trigger application instantiation and termination, and application relocation when needed and supported.

The Operations Support System (OSS)1512 is an operator's OSS that receives requests from UE applications 1518 via a customer service oriented (CFS) portal 1516 over the Mx1 reference point for instantiation or termination of MEC application 1526. The OSS 1512 makes decisions regarding approving these requests. A third party may use CFS portal 1516 (and Mx1 interface) to request MEC system 1500 to run application 1518 in MEC system 1500. The approved request may be forwarded to MEC-O1510 for further processing. When supported, the OSS 1512 also receives a request from the UE application 1518 to relocate the application between the external cloud and the MEC system 1500. The Mm2 reference point between the OSS 1512 and the MEC platform manager 1506 is used for MEC platform manager 1506 configuration, fault and performance management. The Mm1 reference point between MEC-O1510 and OSS 1512 is used to trigger instantiation and termination of MEC application 1526 in MEC system 1500.

UE applications 1518 (also referred to as "device applications" or the like) are one or more applications running in devices 1520 that have the capability to interact with MEC system 1500 via user application lifetime management agent 1514. The UE applications 1518 may be, include, or interact with one or more client applications, which in the context of a MEC, are application software running on the device 1518 that utilize functionality provided by one or more particular MEC applications 1526. The user application LCM agent 1514 may authorize requests from UE applications 1518 in the UE 1520 and interact with the OSS 1512 and MEC-O1510 for further processing of these requests. In the context of MECs, the term "lifecycle management" refers to a set of functions required to manage instantiation, maintenance, and termination of an MEC application 1526 instance. The user application LCM agent 1514 may interact with the OSS 1512 via the Mm8 reference point and be used to handle requests by the UE 1518 to run applications in the MEC system 1500. The user application may be a MEC application 1526 instantiated in the MEC system 1500 in response to a request by a user via an application running in the UE 1520 (e.g., UE application 1518). The user application LCM agent 1514 allows the UE application 1518 to request the user application to go online, instantiate, terminate, and, if supported, relocate the user application into and out of the MEC system 1500. It also allows the user application to be informed of its status. The user application LCM agent 1514 is accessible only from within the mobile network and is only available when supported by the MEC system 1500. The UE application 1518 may request the MEC system 1500 to run an application in the MEC system 1500, or move an application in or out of the MEC system 1500, using the Mx2 reference point between the user application LCM agent 1514 and the UE application 1518. The Mx2 reference point may be accessible only within the mobile network and only available when supported by MEC system 1500.

To run MEC application 1526 in MEC system 1500, MEC-O1510 receives a request triggered by OSS 1512, a third party, or UE application 1518. In response to receiving these requests, MEC-O1510 selects MEC server/host 1502 to host MEC application 1526 for computing offloading, and the like. These requests may include information about the application to be run, and possibly other information such as where the application needs to be active, other application rules and requirements, and the location of the application image (if it is not already on-line with MEC system 1500).

MEC-O1510 can select one or more MEC servers 1502 for the compute intensive task. The selected one or more MEC servers XE136 may offload computing tasks for UE applications 1518 based on various operating parameters, such as network capabilities and conditions, computing capabilities and conditions, application requirements, and/or other similar operating parameters. The application requirements can be rules and requirements associated with one or more MEC applications 1526, such as a deployment model of the application (e.g., it is one instance per user, one instance per host, etc.); required virtualized resources (e.g., computing resources, storage resources, network resources, including specific hardware support); latency requirements (e.g., maximum latency, how strict latency constraints are, fairness of latencies between users); a requirement for location; the MEC application 1526 is capable of running required and/or useful multi-access edge services; the multi-access edge services that MEC application 1526 is capable of utilizing (if available); connectivity or mobility support/requirements (e.g., application state relocation, application instance relocation); required multi-access edge functionality, such as VM relocation support or UE identity; required network connectivity (e.g., connectivity to applications within MEC system 1500, connectivity to a local network or the internet); information about operator's MEC system 1500 deployment or mobile network deployment (e.g., topology, cost); requirements regarding access to user services; requirements for persistent storage; business rules 1540; DNS rules 1542; and the like.

MEC-O1510 selects one or more MEC servers 1502 to host MEC applications 1526 and/or for computing offloading in view of the requirements and information listed above and information about resources currently available in MEC system 1500. After selecting one or more MEC servers XE136, MEC-O1510 requests selected MEC host 1502 to instantiate an application or application task. The actual algorithm used to select the MEC server 1502 depends on the implementation, configuration, and/or operator deployment. The selection algorithm may be based on task offloading criteria/parameters, for example by considering network, computational and energy consumption requirements for performing application tasks, as well as network functions, processing and offloading coding/encoding, or differentiating traffic between various RATs. In certain cases (e.g., UE mobility events leading to increased latency, load balancing decisions, etc.), and if supported, MEC-O1510 may decide to select one or more new MEC hosts 1502 as the master node and initiate application instance or application related state information to be transferred from one or more source MEC hosts 1502 to one or more target MEC hosts 1502.

In a first implementation, UPF 1374 of 5G system 1300 is mapped into MEC architecture 1500 as MEC data plane 1524. In these implementations, the UPF 1374 handles the user plane path for the PDU session. In addition, UPF 1374 provides an interface to data networks (e.g., DNs 1372, 1376) and supports the functionality of PDU session anchoring.

In a second implementation, AF 1364 of 5G system 1300 is mapped into MEC architecture 1500 as MEC platform 1532. In these implementations, the AF 1364 may be configured or operable to perform the impact on traffic routing, access network capability is open, and interacts with the policy framework for policy control. The second implementation may be combined with the first implementation or may be a separate implementation. In the first and/or second implementations, as user traffic is routed to local DN 1372, MEC applications 1526, 1527 and/or 1528 may be mapped to DNs 1372 and/or 1376 at or to 5G system 1300.

In a third implementation, the RAN 1368 of the 5G system 1300 may be a VNF-based virtual RAN, and the UPF 1374 may be configured or operable to serve as the MEC data plane 1524 within a NF virtualization infrastructure (NFVI) (e.g., VI 1522). In these implementations, the AF 1364 may be configured as an MEC platform VNF (see, e.g., the discussion of fig. 16, with MEC APIs, MEC application enablement functions (see, e.g., [ R08]), and API principle functions (see, e.g., [ R06 ])). Furthermore, local DN 1372 may include MEC applications 1526, 1527, and/or 1528 instantiated as VNFs. The implementation may be configured to provide functionality in accordance with [ R05] and/or ETSI GR MEC 017V1.1.1(2018-02) ("[ R07 ]"). The third implementation may be combined with the first implementation and/or the second implementation, or may be a separate implementation.

Additionally or alternatively, the access level edges (e.g., NANs 2128, 2130, and 2132 of fig. 21 and/or other NANs previously discussed) may use one or more APIs to communicate with the local/area level edge network. The local/regional level edge network may include network nodes that communicate with the country level edge network using corresponding applications. The country-level edge may include various NANs that use applications to access one or more remote clouds within the global-level edge. The NAN may also be configured or operable for vertical subdivision management and SLA compliance. Additionally or alternatively, MEC deployment may provide freedom for MNOs based on the definition of "edges", especially when MECs are deployed in NFV environments (e.g., MEC entities may be instantiated as virtualized nfs (vnfs), thus having high flexibility in operator deployment).

In some embodiments, the MEC system 1500 may be flexibly deployed according to use cases/vertical subdivisions/information to be processed. Some components of MEC system 1500 may be co-located with other elements of the system. As an example, in certain use cases (e.g., enterprises), the MEC application 1526 may need to use MEC services locally, and it may be efficient to deploy MEC hosts that are locally equipped with the required set of APIs. In another example, deploying the MEC server 1502 in a data center (which may be remote from the access network) may not require hosting some APIs, such as the RNI APIs (which may be used to collect radio network information from radio base stations). On the other hand, the RNI information may be detailed and provided at the aggregation point in a cloud ran (cran) environment, enabling the execution of suitable radio-aware traffic management algorithms. In some other aspects, bandwidth management APIs may exist at the access level edge, as well as at more remote edge locations, in order to establish a transport network (e.g., for CDN-based services).

Fig. 16 shows a MEC reference architecture 1600 in an NFV environment. MEC architecture 1600 may be configured to provide functionality according to [ R07 ]. The MEC architecture 1600 includes a MEC platform 1602, a MEC platform manager-NFV (MEPM-V)1614, a data plane 1608, a NFV infrastructure (NFVI)1610, VNF managers (VNFM)1620 and 1622, a NFV orchestrator (NFVO)1624, a MEC application orchestrator (MEAO)1626, OSS 1628, a user application LCM agent 1630, a UE application 1634, and a CFS portal 1632. The MEC platform manager 1614 may include MEC platform element management 1616 and MEC application rules and requirements management 1618. MEC platform 1602 may be coupled to another MEC platform 1606 via an MP3 interface.

In this embodiment, MEC platform 1602 is deployed as a VNF. The MEC application 1604 may look like a VNF to ETSI NFV management and orchestration (MANO) components. This allows the ETSI NFV MANO functionality to be reused. The full set of MANO functions may not be used and some additional functionality may be required. This particular MEC application is denoted by the name "MEC application VNF" or "MEA-VNF". The virtualization infrastructure is deployed as NFVI 1610, and its virtualized resources are managed by Virtualization Infrastructure Manager (VIM) 1612. To this end, one or more procedures defined by the ETSI NFV infrastructure specifications may be used (see, e.g., ETSI GS NFV-INF 003V2.4.1(2018-02), ETSI GS NFV-INF 004V2.4.1(2018-02), ETSI GS NFV-INF 005V3.2.1(2019-04), and ETSI GS NF09 V1.1.1(2016-07) (collectively, "[ R31 ]")). The MEA-VNF 1604 manages like individual VNFs, allowing MEC-in-NFV deployments to delegate certain orchestration and LCM tasks to the NFVO 1624 and VNFMs 1620 and 1622, as defined by the ETSI NFV MANO.

When the MEC platform is implemented as a VNF (e.g., MEC platform VNF 1602), the MEPM-V1614 may be configured to function as an Element Manager (EM). The MEAO 1626 uses the NFVO 1624 for resource orchestration and orchestrates the set of MEA-VNFs 1604 into one or more NFV Network Services (NS). MEPM-V1614 delegates the LCM component to one or more VNFMs 1620 and 1622. Specific or generic VNFMs 1620, 1622 are used to perform LCM. MEPM-V1614 and VNFM (ME platform LCM)1620 may be deployed as a single package according to the integration concept in 3GPP TR 32.842v13.1.0(2015-12-21) ("[ R32 ]"), or as [ R31], VNFM is a general VNFM, and MEC platform VNF 1602 and MEPM-V1614 are provided by a single vendor.

The Mp1 reference point between MEC application 1604 and MEC platform 1614 may be optional for MEC application 1604 unless it is an application that provides and/or consumes MEC services. The Mm3 reference point between the MEAO 1626 and the MEPM-V1614 is based on the Mm3 reference point (see e.g. [ R05 ]). This reference point may be changed to meet the division between MEPM-V1614 and VNFM (ME application LCM) 1622. The following new reference points (Mv1, Mv2, and Mv3) are introduced between the elements of the ETSI MEC architecture and the elements of the ETSI NFV architecture to support management of the ME application VNF 1604.

The following reference points relate to existing NFV reference points, but only a part of the functionality may be used for ETSI MEC and may need to be extended. Mv1 is the reference point connecting MEAO 1626 and NFVO 1624, and is related to the Os-Ma-NFVO reference point defined in ETSI NFV. Mv2 is a reference point to connect VNFM 1622, which executes the LCM of MEC application VNF 1604, with MEPM-V1614 to allow LCM related notifications to be exchanged between these entities. Mv2 relates to the Ve-Vnfm-em reference point defined in ETSI NFV, but may possibly include additional functions, and may not use all of the functions for which Ve-Vnfm-em is intended. Mv3 is a reference point that connects VNFM 1622 with the ME application VNF 1604 instance to allow messages to be exchanged (e.g., related to MEC application LCM or initial deployment specific configuration). Mv3 relates to the Ve-Vnfm-vnf reference point defined in ETSI NFV, but may possibly include additional functionality and may not use all of the functionality provided by Ve-Vnfm-vnf.

The following reference points are used because they are defined by ETSI NFV: the Nf-Vn reference point connects each ME application VNF 1604 with NFVI 1610. The Nf-Vi reference point connects NFVI 1610 and VIM 1612. The Os-Ma-NFVO reference point connects OSS 1628 and NFVO 1624 and is primarily used to manage the NS (e.g., multiple VNFs connected and orchestrated to provide services). The Or-Vnfm reference point connects NFVO 1624 and Vnfm (MEC platform LCM)1620, and is used primarily for NFVO 1624 to invoke VNF LCM operations. The Vi-Vnfm reference point connects VIM 1612 and Vnfm (MEC platform LCM)1620, and is primarily used by Vnfm 1620 to invoke resource management operations to manage the cloud resources needed by VNF (assuming that in NFV-based MEC deployments, this reference point 1:1 corresponds to Mm 6). The Or-Vi reference point connects NFVO 1624 and VIM 1612 and is primarily used by NFVO 1624 to manage cloud resource capacity. The Ve-Vnfm-em reference point connects VNFM (MEC platform LCM)1620 to MEPM-V1614. The Ve-Vnfm-VNF reference point connects Vnfm (MEC platform LCM)1620 to MEC platform VNF 1602.

III.C. hardware component

Fig. 17A illustrates a first edge computing hardware configuration that maps various architectural aspects of the edge platform 1710 (e.g., computing hardware, network features, power management features, etc.) to specific edge platform capabilities 1720 (e.g., I/O pooling, accelerated pooling, memory pooling, acceleration techniques, storage capabilities). To provide edge configuration as an overall solution for services, then the workload or underlying hardware components for services and service requirements/constraints (e.g., network and I/O, platform acceleration, power) are considered according to the available architectural aspects (e.g., pooling, storage, etc.).

Within the edge platform capability 1720, a particular acceleration type may be configured or identified to ensure that service density is met on the edge cloud. Specifically, four main acceleration types may be deployed in an edge cloud configuration: (1) general purpose acceleration (e.g., FP)GA) for implementing basic blocks such as Fast Fourier Transforms (FFT), k-nearest neighbor algorithms (KNN), and machine learning workloads; (2) an image, video and transcoding accelerator; (3) a reasoning accelerator; (4) (for example, inQuickAssist^TMImplemented in the technology) encryption and compression related workloads. Thus, the particular design or configuration of the edge platform capability 1720 may take into account which is the correct type of acceleration and platform product model that needs to be selected in order to accommodate the service and throughput densities and available power.

FIG. 17B illustrates a second edge computing hardware configuration that provides a second edge platform 1730 with a second set of edge platform capabilities 1740. This configuration may be deployable as a low power but more service intensive solution. This approach is intended to define a low power solution that uses an acceleration scheme in order to achieve better service density per watt or service throughput. This major design tradeoff has led to platforms that use sacrificial general purpose computing to support specialized hardware (e.g., FPGAs, inference accelerators) that can perform the same work at better per watt performance rates. In this example, a "service intensive" solution enables more service actions per platform and per watt, or can drive more throughput per watt service level.

Platform capabilities 1740 may be designed to be advantageous in terms of both power envelope as well as in terms of physical space. As a result, the configuration of fig. 17B may provide suitable targets for base station deployment. However, platform capabilities 1740 may have tradeoffs, including: (1) requirements in orchestration, maintenance, and system management (which can be translated into OPEX/TCO costs); (2) the operator ecosystem is required to enable all system stacks to work with different accelerators that are open. However, these drawbacks can be mitigated by the software abstraction layer developed.

FIG. 17C illustrates a third edge computing hardware configuration that provides a third edge platform 1750 having a second set of edge platform capabilities 1760. This configuration provides a high power but homogenous and versatile architecture. Fig. 17C provides an opposite approach compared to fig. 17B to provide a platform architecture with reduced heterogeneity of different types of resources that an operator or edge owner has to deal with respect to administrative, maintenance and orchestration. However, the cost of removing accelerators to support homogeneity is to have a smaller per watt service density and service throughput at the platform level. In a further example, the edge platform capability 1760 may implement a generic acceleration (e.g., in the form of an FPGA).

Other derivative functions of the edge platform depicted in fig. 17A-C may also be adjusted. For example, the platform may be sized and designed to incorporate new components to make its services and throughput more, but to remain more homogenous by including accelerators, e.g., inside the platform or on the die, so that operators can manage them seamlessly.

Fig. 18 and 19 depict further examples of edge computing systems and environments in which any of the computing nodes or devices discussed herein may be implemented. Each edge compute node may be embodied as a type of device, appliance, computer, or other "thing" that is capable of communicating with other edge, network, or endpoint components. For example, the edge computing device may be embodied as a smart phone, mobile computing device, smart appliance, in-vehicle computing system (e.g., navigation system), or other device or system capable of performing the described functions.

In fig. 18, edge compute node 1800 includes a compute engine (also referred to herein as "compute circuitry") 1802, an input/output (I/O) subsystem 1808, a data store 1810, a communication circuitry subsystem 1812, and optionally, one or more peripherals 1814. In other examples, the respective computing devices may include other or additional components, such as those typically found in a computer (e.g., a display, a peripheral device, etc.). Further, in some examples, one or more illustrative components may be incorporated in, or otherwise form a part of, another component.

Computing node 1800 may be embodied as any type of engine, device, or collection of devices capable of performing various computing functions. In some examples, the compute node 1800 may be embodied as a single device, such as an integrated circuit, an embedded system, an FPGA, a system on a chip (SoC), or other integrated system or device. The computing node 1800 includes or is embodied as a processor 1804 and memory 1806. The processor 1804 may be embodied as any type of processor capable of performing the functions described herein (e.g., executing applications). For example, the processor 1804 may be embodied as a multicore processor, microcontroller, or other processor or processing/control circuit. In some examples, the processor 1804 may be embodied as, include or be coupled to an FPGA, an Application Specific Integrated Circuit (ASIC), reconfigurable hardware or hardware circuits, or other dedicated hardware to facilitate performance of the functions described herein.

Main memory 1806 may be embodied as any type of volatile (e.g., Dynamic Random Access Memory (DRAM), etc.) or non-volatile memory or data storage capable of performing the functions described herein. Volatile memory can be a storage medium that requires power to maintain the state of data stored by the medium. Non-limiting examples of volatile memory may include various types of Random Access Memory (RAM), such as DRAM or Static Random Access Memory (SRAM). One particular type of DRAM that may be used in memory modules is Synchronous Dynamic Random Access Memory (SDRAM).

In one example, the memory devices are block addressable memory devices, such as those based on NAND or NOR technology. The memory devices may also include three-dimensional cross-point memory devices (e.g.,3D XPoint^TMmemory) or other byte addressable write-in-place non-volatile memory devices. Memory devices may refer to the die itself and/or packaged memory products. In some examples, a 3D cross-point memory (e.g.,3D XPoint^TMmemory) may include a transistor-less stackable cross-point architecture in which memory cells are located at the intersections of word lines and bit lines and are individually addressable, And wherein the bit storage is based on a change in the bulk resistance. In some examples, all or a portion of the main memory 1806 may be integrated into the processor 1804. The main memory 1806 may store various software and data used during operation, such as one or more applications, data operated on by applications, libraries, and drivers.

The computing circuitry 1802 is communicatively coupled to other components of the computing node 1800 via the I/O subsystem 1808, which I/O subsystem 1808 may embody circuitry and/or components for facilitating input/output operations with the computing circuitry 1802 (e.g., with the processor 1804 and/or the main memory 1806) and other components of the computing circuitry 1802. For example, the I/O subsystem 1808 may embody or otherwise include a memory controller hub, an input/output control hub, an integrated sensor hub, firmware devices, communication links (e.g., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.), and/or other components and subsystems to facilitate input/output operations. In some examples, the I/O subsystem 1808 may form part of a system on a chip (SoC) and be incorporated into the compute circuitry 1802 along with one or more of the processor 1804, the main memory 1806, and other components of the compute circuitry 1802.

The one or more illustrative data storage devices 1810 may be embodied as any type of device configured for short-term or long-term storage of data, such as memory devices and circuits, memory cards, hard drives, solid state drives, or other data storage devices. Each data storage device 1810 may include a system partition that stores data and firmware code for data storage device 1810. Each data storage device 1810 may also include one or more operating system partitions that store data files and executable files for an operating system, depending on, for example, the type of computing node 1800.

The communication circuit 1812 may be embodied as any communication circuit, device, or collection thereof that enables communication between the computing circuit 1802 and another computing device (e.g., an edge gateway node, etc.) over a network. The communication circuitry 1812 may be configured to use any one or more communication techniques (e.g., withWired or wireless communication) and associated protocols (e.g., cellular network protocols (e.g., 3GPP 4G or 5G standards), wireless local area network protocols (e.g., IEEE 802.11 @)) Wireless wide area network protocol, Ethernet,Bluetooth low energy, IoT protocol (e.g., IEEE 802.15.4 or ) A Low Power Wide Area Network (LPWAN) or a Low Power Wide Area (LPWA) protocol, etc.).

The illustrative communication circuit 1812 includes a Network Interface Controller (NIC)1820, which may also be referred to as a Host Fabric Interface (HFI). NIC 1820 may be embodied as one or more plug-in boards, daughter cards, network interface cards, controller chips, chipsets, or other devices that may be used by computing node 1800 to connect with another computing device. In some examples, NIC 1820 may be embodied as part of a system on a chip (SoC) that includes one or more processors, or included in a multi-chip package that also contains one or more processors. In some examples, NIC 1820 may include a local processor (not shown) and/or a local memory (not shown), both of which are local to NIC 1820. In such examples, the local processor of NIC 1820 may be capable of performing one or more functions of the computing circuitry 1802 described herein. Additionally or alternatively, in such examples, the local memory of NIC 1820 may be integrated into one or more components of the client computing node at a board level, a socket level, a chip level, and/or other levels.

Additionally, in some examples, respective computing node 1800 may include one or more peripheral devices 1814. Such peripheral devices 1814 may include any type of peripheral device found in a computing device or server, such as audio input devices, displays, other input/output devices, interface devices, and/or other peripheral devices, depending on the particular type of computing node 1800. In further examples, computing node 1800 may be embodied by a respective edge computing node (e.g., a client computing node, an edge gateway node, an edge aggregation node, a vUE as discussed above, etc.) or similar form of appliance, computer, subsystem, circuit, or other component in an edge computing system.

Fig. 19 illustrates an example of components that may be present in an edge compute node 1950 for implementing the techniques (e.g., operations, processes, methods, and methodologies) described herein. When implemented as a computing device (e.g., as a mobile device, base station, server, gateway, etc.) or as part of a computing device, the edge computing node 1950 provides a more close-up view of the various components of the node 1900. Edge computing node 1950 may include any combination of hardware or logic components referenced herein, and it may include or be coupled to any device used with an edge communication network or combination of such networks. The components may be implemented as ICs, portions thereof, discrete electronic devices or other modules, instruction sets, programmable logic or algorithms, hardware accelerators, software, firmware, or combinations thereof suitable for use in the edge compute node 1950, or as components otherwise contained in a chassis of a larger system.

The edge compute node 1950 includes one or more processing circuits in the form of processors 1852. Processor circuit 1952 includes circuits such as, but not limited to, one or more processor cores and cache memory, low dropout regulator (LDO), interrupt controller, serial interface (e.g., SPI, I) ²C or universal programmable serial interface circuit), a Real Time Clock (RTC), timer counters (including interval timers and watchdog timers), universal I/O, a memory card controller (e.g., secure digital/multimedia card (SD/MMC), etc.), an interface, a Mobile Industry Processor Interface (MIPI) interface, and a Joint Test Access Group (JTAG) test access port. In some implementations, the processor circuit 1952 may include one or more hardware accelerators (e.g., the same as or similar to the acceleration circuit 1964), which may be microprocessors, programmable processing devices (e.g., FPGAs, ASICs, etc.), or the like.The one or more accelerators may include, for example, computer vision and/or deep learning accelerators. In some implementations, the processor circuit 1952 may include an on-chip memory circuit, which may include any suitable volatile and/or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, flash, solid state memory, and/or any other type of memory device technology, such as those discussed herein.

Processor circuit 1952 may include, for example, one or more processor Cores (CPUs), an application processor, a GPU, a RISC processor, an Acorn RISC Machine (ARM) processor, a CISC processor, one or more DSPs, one or more FPGAs, one or more PLDs, one or more ASICs, one or more baseband processors, one or more Radio Frequency Integrated Circuits (RFICs), one or more microprocessors or controllers, multi-core processors, multi-threaded processors, ultra low voltage processors, embedded processors, or any other known processing element, or any suitable combination thereof. Processor (or core) 1952 may be coupled to or may include memory/storage and may be configured to: instructions stored in the memory/storage are executed to enable various applications or operating systems to run on platform 1950. Processor (or core) 1952 is configured to: application software is operated to provide specific services to users of platform 1950. In some embodiments, processor 1952 may be a special purpose processor/controller configured (or configurable) to operate in accordance with various embodiments herein.

As an example, processor 1952 may include: based onArchitecture Core^TME.g., processors based on i3, i5, i7, i 9; based onProcessors for microcontrollers, e.g. based on Quark^TM、Atom^TMOr a processor of another MCU;a processor,Processor or slaveCorporation, Santa Clara, California. However, any number of other processors may be used, such as one or more of the following: advanced Micro Devices (AMD)Architectures, e.g.OrA processor, an Accelerated Processing Unit (APU), an MxGPU,A processor, etc.;A5-A12 and/or S1-S4 processors, Inc,Snapdagon of Technologies, Inc^TMOr Centriq^TMA processor, Texas Instruments,open Multimedia Application Platform (OMAP)^TMA processor; MIPS-based designs from MIPS Technologies, Inc., such as MIPS Warrior M-class, Warrior I-class, and Warrior P-class processors; licensed ARM-based designs, such as the ARM Cortex-A, Cortex-R and Cortex-M series of processors, are obtained from ARM Holdings, Ltd; cavium^TMProvided by incAnd the like. In some implementations, processor 1952 may be part of a system on a chip (SoC), System In Package (SiP), multi-chip package (MCP), etc., in which processor 1952 and other components are formed as a single integrated circuit or a single package, e.g. Edison from Corporation^TMOr Galileo^TMAnd (6) an SoC board. Other examples of processor 1952 are mentioned elsewhere in this disclosure.

The processor 1952 may communicate with a system memory 1954 via an Interconnect (IX) 1956. Any number of memory devices may be used to provide a fixed amount of system memory. By way of example, the memory may be a Random Access Memory (RAM) compliant with Joint Electron Device Engineering Council (JEDEC) designs, such as DDR or mobile DDR standards (e.g., LPDDR2, LPDDR3, or LPDDR 4). In a particular example, the memory component may conform to a DRAM standard promulgated by JEDEC, such as JESD79F for DDR SDRAM, JESD79-2F for DDR2 SDRAM, JESD79-3F for DDR3 SDRAM, JESD79-4A for DDR4 SDRAM, JESD209 for low power DDR (LPDDR), JESD209-2 for LPDDR2, JESD209-3 for LPDDR3, and JESD209-4 for LPDDR 4. Other types of RAM may also be included, such as Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), and the like. Such standards (and similar standards) may be referred to as DDR-based standards, and the communication interface of a memory device implementing such standards may be referred to as DDR-based interfaces. In various implementations, each memory device may have any number of different package types, such as a Single Die Package (SDP), a Dual Die Package (DDP), or a quad die package (Q17P). In some examples, these devices may be soldered directly to the motherboard to provide a lower profile solution, while in other examples, these devices are configured as one or more memory modules that are in turn coupled to the motherboard by a given connector. Any number of other memory implementations may be used, such as other types of memory modules, such as different kinds of dual in-line memory modules (DIMMs), including but not limited to microdimms or minidimms.

Storage 1958 can also be coupled to processor 1952 via IX 1956 in order to provide persistent storage of information such as data, applications, operating systems, and the like. In one example, the storage 1958 may be implemented via a Solid State Disk Drive (SSDD) and/or high speed electrically erasable memory (commonly referred to as "flash memory"). Other devices that may be used for storage 1958 include flash memory cards, such as SD cards, microsD cards, XD picture cards, and the like, as well as USB flash drives. In one example, the memory device may be or may include a memory device using chalcogenide glass, multi-threshold level NAND flash memory, NOR flash memory, single or multi-level Phase Change Memory (PCM), resistive memory, nanowire memory, ferroelectric transistor random access memory (FeTRAM), antiferroelectric memory, magnetoresistive Random Access Memory (MRAM) memory employing memristor technology, phase change RAM (pram), resistive memory (including metal oxide based, oxygen vacancy based, and conductive bridge random access memory (CB-RAM) or Spin Transfer Torque (STT) -MRAM), spin electron magnetic junction memory-based devices, Magnetic Tunnel Junction (MTJ) -based devices, Domain Wall (DW) and Spin Orbit Transfer (SOT) -based memory devices, thyristor-based memory devices, or any combination of the above, or other memory. Memory circuit 1954 and/or memory circuit 1958 may also incorporate a memory circuit from Anda three-dimensional (3D) cross point (XPOINT) memory.

In a low power implementation, storage 1958 may be on-die memory or registers associated with processor 1952. However, in some examples, storage 1858 may be implemented using a micro Hard Disk Drive (HDD). Further, any number of new technologies may be used for storage 1958, in addition to or in place of the described technologies, such as resistance change memory, phase change memory, holographic memory, or chemical memory, among others.

Components of the edge computing device 1950 may communicate through IX 1956. IX 1956 may include any number of technologies, including ISA, extended ISA, I²C. SPI, point-to-point interface, Power management bus (PMbus), PCI, PCIe, PCIx, and,UPI、An accelerator link,CXL、CAPI、OpenCAPI、QPI、UPI、OPA IX、RapidIO^TMSystems IX, CCIX, Gen-Z Consortium IX, HyperTransport, interconnected byNVLink, Time Triggered Protocol (TTP) systems, FlexRay systems, PROFIBUS, and/or any number of other IX technologies are provided. IX 1956 may be a dedicated bus, such as used in SoC-based systems.

IX 1956 couples processor 1952 to communication circuitry 1966 for communicating with other devices, such as a remote server (not shown) and/or connected edge devices 1962. The communication circuit 1966 is a hardware element or collection of hardware elements for communicating over one or more networks (e.g., the cloud 1963) and/or with other devices (e.g., the edge devices 1962).

Transceiver 1966 may use any number of frequencies and protocols, such as 2.4 gigahertz (GHz) transmission under the IEEE 802.15.4 standard, usingLow power consumption for ad hoc interest group definition(BLE) standard, orStandards, and the like. Any number of radios configured for a particular wireless communication protocol may be used for a connection to a connected edge device 1962. For example, a Wireless Local Area Network (WLAN) unit may be used for an Institute of Electrical and Electronics Engineers (IEEE)802.11 standard implementationAnd (4) communication. Further, wireless wide area communication, e.g., according to a cellular or other wireless wide area protocol, may be conducted via a Wireless Wide Area Network (WWAN) unit.

The wireless network transceiver 1966 (or transceivers) may communicate using multiple standards or radios for different ranges of communication. For example, the edge computing node 1950 may use a BLE-based local transceiver or another low power radio to communicate with close range devices, e.g., within about 10 meters, to save power. Can pass throughOr other medium power radio, reaches a more distant connected edge device 1962, for example, within about 50 meters. The two communication techniques may be performed at different power levels on a single radio, or may be performed on separate transceivers, e.g., a local transceiver using BLE and a local transceiver using BLE A separate mesh transceiver.

A wireless network transceiver 1966 (e.g., a radio transceiver) may be included to communicate with devices or services in the edge cloud 1963 via a local area network protocol or a wide area network protocol. The wireless network transceiver 1966 may be an LPWA transceiver compliant with IEEE 802.15.4 or IEEE 802.15.4g standards, etc. The edge compute node 1963 may use LoRaWAN developed by Semtech and LoRa alliance^TM(long-haul wide area networks) communicate over a wide area. The techniques described herein are not limited to these techniques, but may be used with any number of other cloud transceivers and other techniques that enable long-range, low-bandwidth communications (e.g., Sigfox). In addition, other communication techniques described in the IEEE 802.15.4e specification, such as slotted channel hopping, may be used.

Any number of other radio communications and protocols may be used in addition to the systems mentioned for the wireless network transceiver 1966 as described herein. For example, the transceivers 1966 may include cellular transceivers that use spread spectrum (SPA/SAS) communications to enable high speed communications. In addition, any number of other protocols may be used, such as for medium speed communications and for providing network communications A network. The transceiver 1966 may include radios compatible with any number of 3GPP specifications, such as LTE and 5G/NR communication systems, discussed in further detail at the end of this disclosure. A Network Interface Controller (NIC)1968 may be included to provide wired communication to nodes of the edge cloud 1963 or to other devices such as connected edge devices 1962 (e.g., operating in mesh). The wired communication may provide an ethernet connection, or may be based on other types of networks, such as a Controller Area Network (CAN), a Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway +, or PROFINET, among others. Additional NICs 1968 may be included to enable connection to a second network, e.g., the first NIC 1968 provides communication with the cloud over ethernet and the second NIC 1968 provides communication with other devices over another type of network.

Given the various types of applicable communications from a device to another component or network, the applicable communication circuits used by the device may include or be embodied by any one or more of the components 1964, 1966, 191868, or 1970. Thus, in various examples, applicable means for communicating (e.g., receiving, transmitting, etc.) may be embodied by such communication circuitry.

The edge compute node 1950 may include or be coupled to an acceleration circuit 1964, which acceleration circuit 1964 may be embodied by: one or more AI accelerators, neural computing sticks, neuromorphic hardware, FPGAs, an arrangement of GPUs, one or more socs (including programmable socs), one or more CPUs, one or more digital signal processors, application specific ASICs (including programmable ASICs), PLDs (e.g., CPLDs or HCPLDs), and/or other forms of special purpose processors or circuitry designed to perform one or more specialized tasks. These tasks may include AI processing (including machine learning, training, reasoning, and classification operations), visual data processing, network data processing, object detection, rule analysis, and so forth. In an FPGA-based implementation, the acceleration circuit 1964 may include logic blocks or logic constructs and other interconnection resources that may be programmed (configured) to perform various functions (e.g., the processes, methods, functions, etc., of the various embodiments discussed herein). In such implementations, the acceleration circuit 1964 may also include memory cells (e.g., EPROM, EEPROM, flash, static memory (e.g., SRAM, antifuse, etc.) for storing logic blocks, logic constructs, data, etc. in a LUT or the like).

IX 1956 also couples processor 1952 to a sensor hub or external interface 1970 for connecting additional devices or subsystems. The additional/external devices may include sensors 1972, actuators 1974, and positioning circuitry 1945.

Sensor circuit 1972 includes a device, module, or subsystem that is intended to detect an event or change in its environment and to transmit information (sensor data) about the detected event to some other device, module, subsystem, or the like. Examples 1972 of such sensors include, among others: an Inertial Measurement Unit (IMU) comprising an accelerometer, a gyroscope, and/or a magnetometer; a microelectromechanical system (MEMS) or nanoelectromechanical system (NEMS) comprising a 3-axis accelerometer, a 3-axis gyroscope, and/or a magnetometer; a liquid level sensor; a flow sensor; temperature sensors (e.g., thermistors); a pressure sensor; an air pressure sensor; a gravimeter; an altimeter; an image capture device (e.g., a camera); a light detection and ranging (LiDAR) sensor; proximity sensors (e.g., infrared radiation detectors, etc.); a depth sensor, an ambient light sensor; an optical light sensor; an ultrasonic transceiver; a microphone, etc.

Actuator 1974 allows platform 1950 to change its state, position, and/or orientation, or to move or control a mechanism or system. Actuator 1974 comprises an electrical and/or mechanical device for moving or controlling a mechanism or system and converts energy (e.g., current or moving air and/or liquid) into some motion. Actuator 1974 may include one or more electronic (or electrochemical) devices such as piezoelectric biomorphic, solid state actuators, Solid State Relays (SSRs), shape memory alloy-based actuators, electroactive polymer-based actuators, relay driver Integrated Circuits (ICs), and the like. The actuators 1974 may include one or more electromechanical devices such as pneumatic actuators, hydraulic actuators, electromechanical switches including electromechanical relays (EMRs), motors (e.g., DC motors, stepper motors, servomechanisms, etc.), power switches, valve actuators, wheels, propellers, claws, clamps, hooks, audible sound generators, visual warning devices, and/or other similar electromechanical components. The platform 1950 may be configured to: one or more actuators 1974 are operated based on one or more captured events and/or instructions or control signals received from a service provider and/or various client systems.

The positioning circuitry 1945 comprises circuitry for receiving and decoding signals transmitted/broadcast by a positioning network of a Global Navigation Satellite System (GNSS). Examples of navigation satellite constellations (or GNSS) include the Global Positioning System (GPS) in the united states, the global navigation system in russia (GLONASS), the galileo system in the european union, the beidou navigation satellite system in china, regional navigation systems or GNSS augmentation systems (e.g., indian constellation Navigation (NAVIC), quasi zenith satellite system in japan (QZSS), doppler orbital imaging in france, and satellite radio positioning integration (DORIS), etc.), among others. The positioning circuitry 1945 includes various hardware elements (e.g., including hardware devices such as switches, filters, amplifiers, antenna elements, etc. to facilitate OTA communication) to communicate with components of a positioning network (e.g., navigation satellite constellation nodes). In some embodiments, positioning circuitry 1945 may include a Micro-technology (Micro-PNT) IC for positioning, navigation, and timing that performs position tracking/estimation using a master timing clock without GNSS assistance. The positioning circuitry 1945 may also be part of, or interact with, the communication circuitry 1966 to communicate with the nodes and components of the positioning network. The positioning circuit 1945 may also provide location data and/or time data to the application circuit, which may use the data to operate in synchronization with various infrastructure (e.g., radio base stations) for turn-by-turn navigation, etc. When GNSS signals are not available or GNSS positioning accuracy is not sufficient for a particular application or service, positioning augmentation techniques may be used to provide augmented positioning information and data to the application or service. Such positioning enhancement techniques may include, for example, satellite-based positioning enhancement (e.g., EGNOS) and/or terrestrial-based positioning enhancement (e.g., DGPS). In some implementations, the positioning circuitry 1945 is or includes an INS, which is a system or device that continuously calculates (e.g., using dead reckoning, triangulation, etc.) the position, orientation, and/or velocity (including direction and speed of movement) of the platform 1950 without external reference using sensor circuitry 1972 (e.g., motion sensors such as accelerometers, rotation sensors such as gyroscopes, and altimeters, magnetic sensors, etc.).

In some alternative examples, various input/output (I/O) devices may be present in or connected to edge compute node 1950, which are referred to in fig. 19 as input circuitry 1986 and output circuitry 1984. Input circuitry 1986 and output circuitry 1984 include one or more user interfaces designed to enable user interaction with platform 1950 and/or peripheral component interfaces designed to enable peripheral component interaction with platform 1950. The input circuitry 1986 may include any physical or virtual means for accepting input, including, inter alia, one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touch screen, a microphone, a scanner, a headset, etc. Output circuitry 1984 may be included to display information or otherwise convey information, such as sensor readings, actuator position, or other similar information. Data and/or graphics may be displayed on one or more user interface components of output circuitry 1984. Output circuitry 1984 may include any number and/or combination of audio or visual displays, including, among other things, one or more simple visual outputs/indicators (e.g., binary status indicators (e.g., Light Emitting Diodes (LEDs)) and multi-character visual outputs, or more complex outputs such as display devices or touch screens (e.g., Liquid Crystal Displays (LCDs), LED displays, quantum dot displays, projectors, etc.), wherein the output of characters, graphics, multimedia objects, etc. is generated or produced from operation of platform 1950. Actuators providing tactile feedback, etc.). In another example, Near Field Communication (NFC) circuitry may be included that includes an NFC controller coupled with the antenna element and the processing device to read the electronic tag and/or connect with another NFC-enabled device. The peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a USB port, an audio jack, a power interface, and the like. In the context of the present system, display or console hardware may be used to: providing an output and receiving an input of an edge computing system; managing components or services of an edge computing system; identifying a state of an edge computing component or service; or perform any other number of administrative or administrative functions or service use cases.

A battery 1976 may power the edge computing node 1950, although in the example where the edge computing node 1950 is installed in a fixed location, it may have a power source coupled to the power grid, or the battery may be used as a backup or temporary capability. Battery 1976 may be a lithium ion battery or a metal air battery (e.g., zinc air battery, aluminum air battery, lithium air battery, etc.).

A battery monitor/charger 1978 may be included in the edge computing node 1950 to track the state of charge (SoCh) of the battery 1976 (if included). The battery monitor/charger 1978 may be used to monitor other parameters of the battery 1976 to provide fault prediction, such as the state of health (SoH) and functional state (SoF) of the battery 1976. The battery monitor/charger 1978 may include a battery monitoring integrated circuit such as LTC4020 or LTC2990 from Linear Technologies, ADT7488A from ON Semiconductor of Phoenix Arizona, or UCD90xxx series ICs from Texas Instruments of Dallas. The battery monitor/charger 1978 may communicate information about the battery 1976 to the processor 1952 via the IX 1956. The battery monitor/charger 1978 may also include an analog-to-digital (ADC) converter that enables the processor 1952 to directly monitor the voltage of the battery 1976 or the current from the battery 1976. The battery parameters may be used to determine actions that the edge computing node 1950 may perform, such as transmission frequency, mesh network operation, sensing frequency, and the like.

A power block 1980 or other power source coupled to the power grid may be coupled to the battery monitor/charger 1978 to charge the battery 1976. In some examples, the power block 1980 may be replaced with a wireless power receiver to obtain power wirelessly, for example, through a loop antenna in the edge computing node 1950. Wireless battery charging circuitry, such as LTC4020 chips from Linear Technologies, Milpitas, California, and the like, may be included in the battery monitor/charger 1978. The particular charging circuit may be selected based on the size of the battery 1976 and the current required thereby. The charging may be performed using the Airfuel standard promulgated by the Airfuel consortium, the Qi wireless charging standard promulgated by the wireless power consortium, or the rezene charging standard promulgated by the wireless power consortium, or the like.

Storage 1958 may include instructions 1982 in the form of software, firmware, or hardware commands to implement the techniques described herein. Although such instructions 1982 are shown as blocks of code included in memory 1954 and storage 1958, it will be appreciated that any of the blocks of code may be replaced by hardwired circuitry (e.g., built into an Application Specific Integrated Circuit (ASIC)).

In an example, instructions 1882 provided via memory 1954, storage 1958, or processor 1952 may be embodied in a non-transitory machine-readable medium 1960 including code to direct processor 1952 to perform electronic operations in an edge compute node 1950. The processor 1952 can access the non-transitory machine-readable medium 1960 through IX 1956. For example, the non-transitory machine-readable medium 1960 may be embodied by a device as described for storage 1958, or may include particular storage elements such as an optical disk, a flash drive, or any number of other hardware devices. The non-transitory machine-readable medium 1960 may include instructions to direct the processor 1952 to perform a particular sequence of acts or flow, e.g., as described with respect to the flowcharts and block diagrams of the operations and functions described above. As used herein, the terms "machine-readable medium" and "computer-readable medium" are interchangeable.

In further examples, a machine-readable medium further includes any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Thus, a "machine-readable medium" may include, but is not limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media include non-volatile memory, including, but not limited to, semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices, for example; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The instructions embodied by the machine-readable medium may also be transmitted or received over a communication network using a transmission medium via a network interface device utilizing any one of a number of transmission protocols (e.g., HTTP).

The machine-readable medium may be provided by a storage device or other apparatus capable of hosting data in a non-transitory format. In an example, information stored or otherwise provided on a machine-readable medium may represent instructions, such as the instructions themselves or the format from which the instructions may be derived. Such formats from which instructions may be derived may include source code, encoded instructions (e.g., in compressed or encrypted form), packed instructions (e.g., divided into multiple packets), and so forth. Information representing instructions in a machine-readable medium may be processed by processing circuitry into instructions to implement any of the operations discussed herein. For example, deriving instructions from information (e.g., for processing by processing circuitry) may include: compiling (e.g., from source code, object code, etc.), interpreting, loading, organizing (e.g., dynamic or static linking), encoding, decoding, encrypting, decrypting, packaging, unpacking, or otherwise manipulating information into instructions.

In an example, derivation of the instructions may include assembly, compilation, or interpretation of the information (e.g., by processing circuitry) to create the instructions in some intermediate or pre-processed format provided from the machine-readable medium. Information, when provided in multiple parts, can be combined, unpacked, and modified to create instructions. For example, the information may be located in multiple compressed source code packages (or object code, or binary executable code, etc.) on one or several remote servers. The source code packets may be encrypted when transmitted over a network and decrypted, decompressed, assembled (e.g., linked) when needed, and compiled or interpreted (e.g., compiled or interpreted into libraries, stand-alone executable files, etc.) on and executed by the local machine.

Fig. 20 depicts communication components within an example mobile device 1832. When implemented as user equipment or as a component of user equipment, the mobile device 1832 provides a more close-up view of the communication processing components of the node 1800 or device 1850. The mobile device 1832 may include radio Front End Module (FEM) circuitry 1834, radio IC circuitry 1836, and baseband processing circuitry 1838. The mobile device 1832 as shown includes both Wireless Local Area Network (WLAN) functionality and Bluetooth (BT) functionality, although the device aspects are not so limited and the other radio technologies discussed herein may be implemented by similar circuitry. FEM circuitry 1834 may include, for example, WLAN or Wi-Fi FEM circuitry 1834A and Bluetooth (BT) FEM circuitry 1834B. The WLAN FEM circuitry 1834A may include a receive signal path including circuitry configured to operate on WLAN RF signals received from one or more antennas 1831A, amplify the receive signals, and provide amplified versions of the receive signals to WLAN radio IC circuitry 1836A for further processing. BT FEM circuitry 1834B may include a receive signal path that may include circuitry configured to operate on BT RF signals received from one or more antennas 1831B, amplify the receive signal, and provide an amplified version of the receive signal to BT radio IC circuitry 1836B for further processing. FEM circuitry 1834A may also include a transmit signal path, which may include circuitry configured to amplify WLAN signals provided by radio IC circuitry 1836A for wireless transmission through one or more antennas 1831A. Furthermore, FEM circuitry 1834B may also include a transmit signal path, which may include circuitry configured to amplify BT signals provided by radio IC circuitry 1836B for wireless transmission through one or more antennas 1831B. In the example of fig. 20, although FEMs 1834A and 1834B are shown as being distinct from one another, aspects of the disclosure are not so limited and include within their scope the use of a FEM (not shown) that includes a transmit path and/or a receive path for both WLAN and BT signals, or the use of one or more FEM circuits that share transmit and/or receive signal paths for both WLAN and BT signals using at least some FEM circuits.

The radio IC circuit 1836 as shown may include a WLAN radio IC circuit 1836A and a BT radio IC circuit 1836B. The WLAN radio IC circuitry 1836A may include a receive signal path that may include circuitry to down-convert WLAN RF signals received from the FEM circuitry 1834A and provide baseband signals to the WLAN baseband processing circuitry 1838A. BT radio IC circuitry 1836B may, in turn, include a receive signal path that may include circuitry to down-convert BT RF signals received from FEM circuitry 1834B and provide baseband signals to BT baseband processing circuitry 1838B. The WLAN radio IC circuitry 1836A may also include a transmit signal path that may include circuitry to up-convert WLAN baseband signals provided by the WLAN baseband processing circuitry 1838A and provide WLAN RF output signals to the FEM circuitry 1834A for subsequent wireless transmission by the one or more antennas 1831A. BT radio IC circuitry 1836B may also include a transmit signal path that may include circuitry to upconvert BT baseband signals provided by BT baseband processing circuitry 1838B and provide BT RF output signals to FEM circuitry 1834B for subsequent wireless transmission by one or more antennas 1831B. In the example of fig. 20, although the radio IC circuits 1836A and 1836B are shown as being distinct from one another, aspects of the present disclosure are not so limited and include within their scope the use of radio IC circuits (not shown) that include transmit and/or receive signal paths for both WLAN and BT signals, or the use of one or more radio IC circuits that share transmit and/or receive signal paths for both WLAN and BT signals using at least some of the radio IC circuits.

The baseband processing circuits 1838 may include WLAN baseband processing circuits 1838A and BT baseband processing circuits 1838B. The WLAN baseband processing circuitry 1838A may include a memory, such as a set of RAM arrays in a fast fourier transform or inverse fast fourier transform block (not shown) of the WLAN baseband processing circuitry 1838A. Each of the WLAN baseband circuitry 1838A and BT baseband circuitry 1838B may also include one or more processors and control logic to process signals received from a corresponding WLAN or BT receive signal path of the radio IC circuitry 1836 and also to generate a corresponding WLAN or BT baseband signal for a transmit signal path of the radio IC circuitry 1836. Each of the baseband processing circuits 1838A and 1838B may also include a physical layer (PHY) and a media access control layer (MAC) circuit and may further interface with an application processor 1851 (or in other examples, a processor circuit 1850) for generating and processing baseband signals and for controlling operation of the radio IC circuit 1836.

Still referring to fig. 20, in accordance with the illustrated aspects, the WLAN-BT coexistence circuit 1843 may include logic to provide an interface between the WLAN baseband circuit 1838A and the BT baseband circuit 1838B to implement use cases requiring WLAN and BT coexistence. Further, a switch 1833 may be provided between the WLAN FEM circuitry 1834A and the BT FEM circuitry 1834B to allow switching between WLAN and BT radios according to application needs. Further, although antennas 1831A, 1831B are depicted as being connected to WLAN FEM circuitry 1834A and BT FEM circuitry 1834B, respectively, aspects of the present disclosure include within their scope sharing one or more antenna FEMs between WLAN and BT, or providing more than one antenna connected to each of FEMs 1834A or 1834B.

In some aspects of the disclosure, the front-end module circuitry 1834, the radio IC circuitry 1836, and the baseband processing circuitry 1838 may be provided on a single radio card. In other aspects, the one or more antennas 1831A, 1831B, FEM circuit 1834 and radio IC circuit 1836 may be provided on a single radio card. In some other aspects of the disclosure, the radio IC circuitry 1836 and the baseband processing circuitry 1838 may be provided on a single chip or Integrated Circuit (IC).

Fig. 21 illustrates rack-scale design (RSD) components that may be included as part of a server or other discrete computing node in an edge platform architecture. When implemented as a server (e.g., in a server rack, blade, etc.), this arrangement provides a closer view of configurable processing components of the node 1800 or the device 1950. This configurable architecture differs from some others in that: decomposing Field Programmable Gate Arrays (FPGAs), non-volatile memory (NVMe), and input output (I/O) pooled resources. The FPGA and NVMe resources provide elements that can be used for any type of edge service (e.g., video or voice analysis). I/O pooling may be used to provide flexible NF. The architecture enables scaling of the network interfaces according to the expected data rate or network load of a particular VNF. The architecture may also enable flexibility in mapping different network cards to compute nodes depending on the type of network processing occurring on a given node.

The RSD architecture shown includes a point of delivery (POD) manager 2142. The POD manager 2142 is responsible for managing resources within a POD (e.g., one or more chassis) -including computing resources and disaggregation resources. The POD manager 2142 opens an interface to the orchestrator to create, manage, or destroy synthetic nodes. Managing synthetic nodes includes features to scale up or down the amount of pooled resources 2148 connected to a particular computing pad 2140. The POD manager 2142 typically runs on a node controller. The POD manager 2142 is responsible for discovering resources in a POD, configuring and managing resources, and composing a logical server. In an example, the POD manager 2142 is an optional, separate component, not required in the chassis. However, in an example, to be "RSD compliant," a chassis may be managed by an authenticated POD manager.

The following are some example attributes of the POD manager 2142. For example, a chassis may include a set of computing boards (slids) 2140 for executing edge services and other related system software stacks (e.g., orchestration or other system services). One type of computing pad 2140 may be a pooled resource pad. The computing pad 2140 may manage a set of decomposed resources. Here, the computing board 1840 may include pooled system management engine software (PSME) 2141. PSME 2141 provides a management interface to manage modules or blades at the drawer level. In an example, a chassis contains one or more logical PSMEs. For example, each drawer may have a PSME, or server drawers may share a PSME, or a PSME may run on a top of rack (TOR)2144 switch or on a separate host. In an example, PSME 2141 supports the RSD API.

In an example, the computing pad 2140 may include a processor (e.g., CLX) to run an RSD software stack that implements the NVM-af or FPGA-af acting as the target system and manages a set oF decomposed resources. In an example, the processor is connected to PCIe switch 2146 using a PCIe x16 bifurcated port, providing access to a target resource (FPGA or NVME in RSD 2148).

Various RSD edge synthesized node styles may be used in the computing pad 2140 to run edge services. Services running on these nodes may use client software libraries or drivers to provide transparent access to the decomposed FPGA and NVME in RSD 2148. In other examples, the chassis includes one or more pctes that connect the computing board 2140 to a set of decomposed resources (e.g., RSD 2148).

The illustrations of fig. 18, 19, 20, and 21 are intended to depict high-level views of components of different devices, subsystems, or arrangements of edge compute nodes. However, it will be understood that some of the components shown may be omitted, that additional components may be present, and that different arrangements of the components shown may be present in other implementations. Further, these arrangements may be used in a variety of use cases and environments, including those discussed below (e.g., mobile UEs in industrial computing for smart cities or smart factories, among many other examples).

The respective computing platforms of fig. 18, 19, 20, and 21 can support multiple edge instances (e.g., edge clusters) by using tenant containers running on a single computing platform. Likewise, multiple edge nodes may exist as child nodes running on tenants within the same computing platform. Thus, based on the available resource partitioning, a single system or computing platform may be partitioned or partitioned to support multiple tenants and edge node instances, each of which may support multiple services and functions, even when potentially operated or controlled by multiple owners in multiple computing platform instances. These various types of partitions may support multiple combinations of complex multi-tenants and multi-stakeholders by using LSM or other implementations of isolation/security policies. Therefore, reference to using an LSM and security features that enhance or implement such security features is mentioned in the following sections. Also, services and functions operating on these various types of multi-entity partitions may be load balanced, migrated, and orchestrated to accomplish desired service goals and operations.

Example implementation

Additional examples of the presently described method, system, and apparatus embodiments include the following non-limiting implementations. Each of the following non-limiting examples can exist independently or can be combined in any permutation or combination with any one or more of the other examples provided below or throughout this disclosure.

Example 1 includes: a method of operating an MEC host co-located with a network access infrastructure, the method comprising: receiving a request message for a predicted quality of service (QoS) for a wireless communication service along a planned route of a vehicle user equipment (vUE), the request message including location information (LocationInfo) for each of at least two points along the planned route and a timestamp for each of the at least two points; and in response to receipt of the request message, determining the predicted QoS for the wireless communication services for the vUE along the planned route based on the location and the timestamp for each point.

Example 2a includes: the method of example 1, wherein the request message further comprises a route data element comprising information about potential routes of the vUE.

Example 2b includes: the method of example 2a and/or some other example herein, wherein the request message further includes a predicted QoS data structure, and the predicted QoS data structure includes the route data element.

Example 3a includes: the method of claims 1-2a and/or some other example herein, wherein the route data element comprises a route information (routeInfo) data element for each of the at least two points.

Example 3b includes: the method of example 2b and/or some other example herein, wherein the predicted QoS data structure includes the route data element and a routeInfo data element for each of the at least two points.

Example 4 includes: the method of examples 3a-3b and/or some other example herein, wherein a forwardmost routeInfo data element included in the route data element corresponds to a start of the planned route and a forwardmost routeInfo data element included in the route data element corresponds to an end of the planned route.

Example 5 includes: the method of example 4 and/or some other example herein, wherein the route data elements further include one or more intermediate routeInfo data elements, each of the intermediate routeInfo data elements corresponding to a respective intermediate point between the start point of the planned route and the end point of the planned route.

Example 6 includes: the method of examples 3a-5 and/or some other example herein, wherein the routeInfo data element for each point includes a location data element including the LocationInfo and a time data element including the timestamp.

Example 7 includes: the method of example 6 and/or some other example herein, wherein the LocationInfo includes longitude and latitude coordinates or a global cell identifier of a serving cell to which the vUE is attached, and the timestamp is an estimated time at a location indicated by the LocationInfo.

Example 8a includes: the method of examples 3a-6 and/or some other example herein, wherein the request message further includes a time granularity data element and a location granularity data element, the time granularity data element including a timestamp value indicating a time granularity of the visited location, and the location granularity data element including a string indicating a granularity of the visited location measured in meters by longitude and latitude margins.

Example 8b includes: the method of example 8a and/or some other example herein, wherein the time granularity data element and the location granularity data element are included in the predictive QoS data structure.

Example 9a includes: the method of examples 1-8b and/or some other example herein, further comprising: generating a response message including radio measurements for each point along the planned route; and sending the response message to the vUE.

Example 9b includes: the method of example 9a and/or some other example herein, further comprising: generating the response message to include another predicted QoS data structure that includes the radio measurements for each point along the planned route.

Example 10a includes: the method of examples 9a-9b and/or some other example herein, wherein the response message further includes another route data element including another routeInfo data element for each of the at least two points, and the routeInfo data element for each point includes a location data element including a LocationInfo for a corresponding point of the at least two points, a reference signal received power (rsrp) data element including a predicted rsrp value for the corresponding point, and a reference signal received quality (rsrq) data element including a predicted rsrq value for the corresponding point.

Example 10b includes: the method of example 10a and/or some other example herein, wherein the another predicted QoS data structure includes the another route data element.

Example 11 includes: the method of example 10 and/or some other example herein, wherein a first other routeInfo data element included in the other route data element corresponds to a start point of the planned route, a last other routeInfo data element included in the other route data element corresponds to an end point of the planned route, and one or more other intermediate routeInfo data elements included in the other route data element correspond to respective intermediate points between the start point of the planned route and the end point of the planned route.

Example 12 includes: the method of examples 9-11, wherein the request and the response are passed through a VIS Application Programming Interface (API).

Example 13 includes: the method of examples 1-12 and/or some other example herein, wherein determining the predicted QoS for the vUE along the planned route comprises: identifying a spatio-temporal correlation between radio information collected by one or more other vues and the at least two points along the planned route.

Example 14a includes: the method of examples 1-13 and/or some other example herein, wherein determining the predicted QoS for the vUE for the wireless communication services of the vUE along the planned route comprises: requesting information from the MEC information service via the corresponding MEC API; receiving the requested information from the MEC information service; and predicting a radio signal quality network at each of the at least two points using the received information, wherein the MEC information service is a radio network information service, an MEC location service, a subscriber identity service, a bandwidth management service, a wireless local area network access information service, or a fixed access information service. Example 14b includes: the method of example 14a and/or some other example herein, wherein the radio signal quality prediction indicates a level or amount of network congestion.

Example 15 includes: a method of operating a vUE, the method comprising: generating a request message to request a quality of service (QoS) prediction for vehicle-to-anything (V2X) service along a planned route, the request message including a predicted QoS data structure including location information (LocationInfo) for each of at least two points along the planned route and a timestamp for each of the at least two points; and sending the request message to a multiple access edge computing (MEC) host via a V2X Information Service (VIS) Application Programming Interface (API); and receiving a response message from the MEC host via the VIS API, the response message including another predicted QoS data structure containing predicted QoS for the V2X service for each of the at least two points.

Example 16 includes: the method of example 15 and/or some other example herein, wherein the predicted QoS data structure includes a route data element including a route information (routeInfo) data element for a corresponding point of the at least two points, and the routeInfo data element for the corresponding point includes a location data element including a LocationInfo for the corresponding point and a time data element including the timestamp for the corresponding point.

Example 17 includes: the method of example 16 and/or some other example herein, wherein the corresponding point of a most forward routeInfo data element included in the route data element is a start point of the planned route, and the corresponding point of a last routeInfo data element included in the route data element is an end point of the planned route.

Example 18 includes: the method of example 17 and/or some other example herein, wherein the timestamp for the starting point is a time at which the vUE visited the location indicated by the LocationInfo in the frontmost routeInfo data element, and the timestamp for the ending point is a predicted time at which the vUE will visit the location indicated by the LocationInfo in the last routeInfo data element.

Example 19 includes: the method of examples 17-18 and/or some other example herein, wherein the route data element further includes one or more intermediate routeInfo data elements, each of the one or more intermediate routeInfo data elements corresponding to a waypoint between the start point and the end point.

Example 20 includes: the method of example 19 and/or some other example herein, wherein the timestamp for at least one waypoint is a time at which the vUE accessed the location indicated by the LocationInfo in the intermediate routeInfo data element corresponding to the at least one waypoint, and the timestamp for another waypoint is a predicted time at which the vUE will access the location indicated by the LocationInfo in the routeInfo data element corresponding to the another waypoint.

Example 21 includes: the method of examples 16-20 and/or some other example herein, wherein the other predicted QoS data structure includes another route data element including another routeInfo data element for the corresponding point of the at least two points, and the routeInfo data element for the corresponding point includes: a location data element including the LocationInfo for the corresponding point, a temporal data element including the timestamp for the corresponding point, a reference signal received power (rsrp) data element including a predicted rsrp value at a location indicated by the LocationInfo for the corresponding point and during a time of the timestamp in the temporal data element, and a reference signal received quality (rsrq) data element including a predicted rsrq value at the location indicated by the LocationInfo for the corresponding point and during the time of the timestamp in the temporal data element.

Example 22 includes: a method for obtaining a trip-specific QoS prediction for V2X service, the method comprising: sending, by the vUE to the MEC host via a VIS API, a request for the trip-specific QoS forecast, the request indicating a planned route comprising a start point, an end point, and zero or more waypoints between the start point and the end point; and receiving, by the vUE from the MEC host via the VIS API, a response message including a predicted QoS for V2X service for each of the start point, the end point, and the zero or more waypoints.

Example 23a includes: the method of example 22 and/or some other example herein, further comprising: at each period of the determined radio information reporting periodicity, collecting radio information comprising one or more radio measurement reports; and transmitting the radio information to the MEC host via the VIS API or another MEC API.

Example 23b includes: the method of examples 22-23a and/or some other example herein, further comprising: determining whether to perform data transfer at each of the at least two points based on the predicted QoS for each point.

Example 24 includes: a method comprising instructions for providing trip-specific QoS prediction for network services, the method comprising: receiving a request for the trip-specific QoS prediction from a vehicle user Equipment (vUE) via a vehicle-to-everything information service (VIS) Application Programming Interface (API), the request indicating a planned route for the vUE, the planned route including a start point, an end point, and zero or more waypoints between the start point and the end point that are planned to be visited at a particular point in time; obtaining, by the MEC host, radio information from one or more vUEs and other information from one or more other MEC hosts using a corresponding MEC API; determining, by the MEC host, a predicted QoS for network services for each of the start point, the end point, and the zero or more waypoints based on the radio information and the other information; and sending, by the MEC host, a TPC to the vUE via the VIS API, a message, the response message including the predicted QoS for network services for the start point, the end point, and the zero or more waypoints.

Example 25 includes: the method of example 24 and/or some other example herein, wherein the other information is one or more of: an RNI obtained from a Radio Network Information (RNI) service, location information obtained from a location service, user identity information obtained from a user identity service, bandwidth management (BWM) information obtained from a BWM service, a WAI obtained from a wireless local area network access information (WAI) service, and a FAI obtained from a Fixed Access Information (FAI) service.

An example implementation is an edge computing system that includes respective edge processing devices and nodes to invoke or perform operations of examples 1-25 or other subject matter described herein. Another example implementation is a client endpoint node operable to invoke or perform the operations of examples 1-25 or other subject matter described herein. Another example implementation is an aggregation node, a hub node, a gateway node, or a core data processing node, within or coupled to an edge computing system, operable to invoke or perform operations of examples 1-25 or other subject matter described herein. Another example implementation is an access point, base station, roadside unit, street unit, or preset unit, located within or coupled to an edge computing system, operable to invoke or perform the operations of examples 1-25 or other subject matter described herein. Another example implementation is an edge provisioning node, a service orchestration node, an application orchestration node, or a multi-tenant management node, within or coupled to an edge computing system, operable to invoke or perform the operations of examples 1-25 or other subject matter described herein.

Another example implementation is an edge node operating an edge provisioning service, an application or service orchestration service, a virtual machine deployment, a container deployment, a function deployment, and a computing management, within or coupled to an edge computing system, operable to invoke or perform operations of examples 1-25 or other subject matter described herein. Another example implementation is an edge computing system operable as an edge grid, an edge grid with sidecar loading, or with grid-to-grid communications, operable to invoke or perform the operations of examples 1-25 or other subject matter described herein. Another example implementation is an edge computing system that includes aspects of network functions, acceleration hardware, storage hardware, or computing hardware resources, operable to invoke or perform the use cases discussed herein, using examples 1-25 or other subject matter described herein. Another example implementation is an edge computing system adapted to support client mobility, vehicle-to-vehicle (V2V), vehicle-to-everything (V2X), or vehicle-to-infrastructure (V2I) scenarios, and optionally operating in accordance with ETSI MEC specifications, operable to invoke or perform the use cases discussed herein using examples 1-25 or other subject matter described herein. Another example implementation is an edge computing system adapted for mobile wireless communications, comprising a configuration in accordance with 3GPP4G/LTE or 5G network capabilities operable to invoke or perform a use case as discussed herein, using examples 1-25 or other subject matter described herein.

Example Z01 includes: an apparatus comprising means for performing one or more elements of a method described in or relating to any one of examples 1-25 or any other method or process described herein. Example Z02 includes: one or more non-transitory computer-readable media comprising instructions, wherein execution of the instructions by an electronic device is operable to cause the electronic device to perform one or more elements of a method described in or relating to any of examples 1-25 or any other method or process described herein. Example Z03 includes: a computer program comprising instructions, wherein execution of the program by a processing element is operable to cause the processing element to perform performing any one of the methods, techniques, or processes described in or relating to any one of examples 1-25 and/or portions thereof. Example Z04 includes: an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or relating to any one of examples 1-25/or any other method or process described herein. Example Z05 includes: an apparatus configured to perform one or more elements of a method described in or relating to any of examples 1-25/and/or any other method or process described herein.

Example Z06 includes: a method, technique or process described in or relating to any one of examples 1-25/and/or portions thereof. Example Z07 includes: an apparatus, comprising: a processor circuit; and a computer-readable medium comprising instructions, wherein the one or more processors are configurable to perform a method, technique, or process described in or related to any of examples 1-25 and/or portions thereof. Example Z08 includes: a signal as described in or relating to any one of examples 1-25/and/or a part or portion thereof. Example Z09 includes: a datagram, packet, frame, segment, Protocol Data Unit (PDU), or message as described in or relating to any one of examples 1-25/or portions thereof and/or otherwise described in this disclosure. Example Z10 includes: a signal encoded by a datagram, packet, frame, segment, PDU, or message as described in or relating to any one of examples 1-25/or portions thereof and/or otherwise described in this disclosure.

Example Z11 includes: a signal encoded by data described in or relating to any one of examples 1-25/and/or portions thereof and/or otherwise described in this disclosure. Example Z12 includes: an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors is operable or configurable to cause the one or more processors to perform a method, technique, or process described in or relating to any one of examples 1-25/or portions thereof. Example Z13 includes: an API or specification defining functions, methods, variables, data structures, protocols, etc., defining or relating to any one of examples 1-25/or portions thereof or otherwise relating to use of any one of examples 1-25/or portions thereof. Example Z14 includes: a multi-access edge computing (MEC) host that executes a service as part of one or more MEC applications instantiated on a virtualization infrastructure, the service relating to any one of examples 1-25 or portions thereof, and wherein the MEC host is configured to operate according to standards from one or more ETSI MEC standards families.

Example Z15 includes a signal in a wireless network as shown and described herein. Example Z16 includes a method of communicating in a wireless network as shown and described herein. Example Z17 includes a system for providing wireless communication as shown and described herein. Example Z18 includes an apparatus for providing wireless communication as shown and described herein.

Term of V

As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. The phrase "A and/or B" means (A), (B) or (A and B). For the purposes of this disclosure, the phrase "A, B and/or C" means (a), (B), (C), (a and B), (a and C), (B and C), or (A, B and C). The description may use the phrases "in an embodiment" or "in some embodiments," which may each refer to one or more of the same or different embodiments. Furthermore, the terms "comprising," "including," "having," and the like, as used with respect to embodiments of the present disclosure, are synonymous.

The terms "coupled," "communicatively coupled," along with their derivatives, are used herein. The term "coupled" may mean that two or more elements are in direct physical or electrical contact with each other, that two or more elements are in indirect contact with each other but yet still co-operate or interact with each other, and/or that one or more other elements are coupled or connected between the elements that are said to be coupled to each other. The term "directly coupled" may mean that two or more elements are in direct contact with each other. The term "communicatively coupled" may mean that two or more elements may be in contact with each other through communications (including through a wired or other interconnection, through a wireless communication channel or link, etc.).

The term "circuitry" refers to a circuit or system of circuits configured to perform a particular function in an electronic device. A circuit or system of circuits may be part of, or include, one or more hardware components (e.g., logic circuits, processors (shared, dedicated, or group) and/or memories (shared, dedicated, or group), ASICs, FPGAs, Programmable Logic Controllers (PLCs), socs, sips, multi-chip packages (MCPs), DSPs, etc.) configured to provide the described functionality. Furthermore, the term "circuitry" may also refer to a combination of one or more hardware elements and program code that performs the function of the program code. Some types of circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The combination of such hardware elements and program code may be referred to as a particular type of circuitry.

It should be appreciated that the functional units or capabilities described in this specification may have been referred to or labeled as components or modules, in order to more particularly emphasize their implementation independence. These components may be embodied in any number of software or hardware forms. For example, a component or module may be implemented as a hardware circuit comprising custom Very Large Scale Integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors (e.g., logic chips), transistors, or other discrete components. A component or module may also be implemented in programmable hardware devices (e.g., field programmable gate arrays, programmable array logic, programmable logic devices, etc.). The components or modules may also be implemented in software for execution by various types of processors. For example, an identified component or module of executable code may comprise one or more physical or logical blocks of computer instructions which may, for example, be organized as an object, procedure, or function. Nevertheless, the executables of an identified component or module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the component or module and achieve the stated purpose for the component or module.

Indeed, a component or module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices or processing systems. In particular, some aspects of the described processes (e.g., code rewriting and code analysis) may occur on a different processing system (e.g., in a computer of a data center) than the processing system that deploys the code (e.g., in a computer embedded in a sensor or robot). Similarly, operational data may be identified and illustrated herein within components or modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. A component or module may be passive or active, including an agent operable to perform a desired function.

The term "processor circuit" as used herein refers to, is part of, or includes circuitry capable of sequentially and automatically performing a series of arithmetic or logical operations or recording, storing and/or transmitting digital data. The term "processor circuit" may refer to one or more application processors, one or more baseband processors, physical CPUs, single-core processors, dual-core processors, tri-core processors, quad-core processors, and/or any other device capable of executing or otherwise operating computer-executable instructions (e.g., program code, software modules, and/or functional processes). The terms "application circuitry" and/or "baseband circuitry" may be considered synonymous with "processor circuitry" and may be referred to as "processor circuitry".

The term "memory" and/or "memory circuitry" as used herein refers to one or more hardware devices for storing data, including RAM, MRAM, PRAM, DRAM and/or SDRAM, kernel memory, ROM, magnetic disk storage media, optical storage media, flash memory devices, or other machine-readable media for storing data. The term "computer-readable medium" can include, but is not limited to, memory, portable or fixed storage devices, optical storage devices, and various other media capable of storing, containing, or carrying instruction(s) or data.

The term "interface circuit" as used herein refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term "interface circuit" may refer to one or more hardware interfaces (e.g., a bus, an I/O interface, a peripheral component interface, a network interface card, etc.).

The term "element" refers to a unit that is indivisible and has well-defined boundaries at a given level of abstraction, where an element may be any type of entity including, for example, one or more devices, systems, controllers, network elements, modules, or the like, or a combination thereof. The term "device" refers to a physical entity that is embedded within or attached to another physical entity in its vicinity, with the ability to communicate digital information to and from that physical entity. The term "entity" refers to a distinct component of an architecture or device, or information conveyed as a payload. The term "controller" refers to an element or entity that has the ability to affect a physical entity, for example, by changing its state or causing the physical entity to move.

As used herein, the term "edge computing" encompasses many implementations of distributed computing, moving processing activities and resources (e.g., computing, storage, accelerated resources) towards the "edge" of the network in an effort to reduce latency and increase throughput for end users (client devices, user devices, etc.). Such edge computing implementations typically involve providing such activities and resources in cloud-like services, functions, applications, and subsystems from one or more locations accessible via a wireless network. Thus, as used herein, a reference to an "edge" of a network, cluster, domain, system, or computing arrangement is a group or grouping of functionally distributed computing elements, and thus is generally independent of the "edge" (links or connections) used in graph theory). A particular arrangement of edge computing applications and services accessible via mobile wireless networks (e.g., cellular and WiFi data networks) may be referred to as "mobile edge computing" or "multi-access edge computing," which may be referred to by the acronym "MEC. The use of "MEC" herein may also refer to a standardized implementation promulgated by the European Telecommunications Standards Institute (ETSI), referred to as an "ETSI MEC". Terms used by the ETSI MEC specifications are generally incorporated by reference herein, unless a conflicting definition or usage is provided herein.

As used herein, the term "compute node" or "computing device" refers to an identifiable entity, whether part of a larger system, a collection of distributed systems, or a stand-alone apparatus, that implements aspects of edge computing operations. In some examples, a computing node may be referred to as an "edge node," "edge device," "edge system," whether operating as a client, server, or intermediate entity. Specific implementations of the computing node may be incorporated into a server, a base station, a gateway, a roadside unit, a premise unit, a UE, or a terminal consumer device, etc.

The term "computer system" as used herein refers to any type of interconnected electronic devices, computer devices, or components thereof. Moreover, the terms "computer system" and/or "system" may refer to various components of computers that are communicatively coupled to each other. Moreover, the terms "computer system" and/or "system" may refer to multiple computer devices and/or multiple computing systems communicatively coupled to one another and configured to share computing and/or networking resources.

The term "architecture" as used herein refers to a computer architecture or a network architecture. A "network architecture" is a physical and logical design or arrangement of software and/or hardware elements in a network, including communication protocols, interfaces, and media transports. "computer architecture" is the physical and logical design or arrangement of software and/or hardware elements in a computing system or platform, including the technical standards for interaction between them.

The terms "appliance," "computer appliance," and the like as used herein refer to a computer device or computer system having program code (e.g., software or firmware) specifically designed to provide specific computing resources. A "virtual appliance" is a virtual machine image to be implemented by a hypervisor-equipped device that virtualizes or emulates a computer appliance or is otherwise dedicated to providing specific computing resources.

The term "user equipment" or "UE" as used herein refers to a device having radio communication capabilities and may describe a remote user of network resources in a communication network. The terms "user equipment" or "UE" may be considered synonymous and may refer to clients, mobiles, mobile devices, mobile terminals, user terminals, mobile units, stations, mobile users, subscribers, users, remote stations, access agents, user agents, receivers, radios, reconfigurable mobiles, and the like. Furthermore, the term "user equipment" or "UE" may include any type of wireless/wired device or any computing device that includes a wireless communication interface. The term "station" or "STA" refers to a logical entity that is an individually addressable instance of the Medium Access Control (MAC) and physical layer (PHY) interfaces to the Wireless Medium (WM). The term "wireless medium" or "WM" refers to a medium used to enable the transfer of Protocol Data Units (PDUs) between peer physical layer (PHY) entities of a wireless Local Area Network (LAN).

The term "network element" as used herein refers to an entity or virtualized device and/or infrastructure to provide wired or wireless communication network services. The term "network element" may be considered synonymous with networked computer, networking hardware, network device, network node, router, switch, hub, bridge, radio network controller, RAN device, RAN node, gateway, server, virtualized VNF, NFVI, etc.

As used herein, the term "access point" or "AP" refers to an entity that contains one Station (STA) and provides access to distribution services for the associated STA via the Wireless Medium (WM). The AP includes STAs and a Distribution System Access Function (DSAF). As used herein, the term "base station" refers to a network element in a Radio Access Network (RAN) (e.g., a fourth generation (4G) or fifth generation (5G) mobile communication network) that is responsible for sending and receiving radio signals to or from User Equipment (UE) in one or more cells. The base station may have an integrated antenna or may be connected to the antenna array by a feeder cable. The base station uses dedicated digital signal processing and network function hardware. In some examples, a base station may be partitioned into multiple functional blocks operating in software for flexibility, cost, and performance. In some examples, the base station may include an evolved node b (enb) or a next generation node b (gnb). In some examples, a base station may operate or include computing hardware to operate as a computing node. However, in many scenarios discussed herein, the RAN base station may be replaced with an access point (e.g., a wireless network access point) or other network access hardware.

As used herein, the term "central office" (or CO) indicates an aggregation point of telecommunications infrastructure within an accessible or defined geographical area, generally where a telecommunications service provider has traditionally located switching equipment for one or more types of access networks. The CO may be physically designed to house telecommunications infrastructure equipment or computing, data storage and network resources. However, the CO need not be a location specified by the telecommunication service provider. The CO may host any number of computing devices for edge applications and services or even local implementations of cloud-like services.

The term "cloud computing" or "cloud" refers to a paradigm that enables a scalable and resilient pool of sharable computing resources with on-demand self-service provisioning and management and without active management by users. Cloud computing provides cloud computing services (or cloud services) that are one or more capabilities provided via cloud computing invoked using defined interfaces (e.g., APIs, etc.). The term "computing resource" or simply "resource" refers to any physical or virtual component of limited availability within a computer system or network or the use of such components. Examples of computing resources include use/access for a period of time to servers, processors, storage devices, memory regions, networks, power, input/output (peripheral) devices, mechanical devices, network connections (e.g., channels/links, ports, network sockets, etc.), operating systems, Virtual Machines (VMs), software/applications, computer files, and so forth. "hardware resources" may refer to computing, storage, and/or network resources provided by a physical hardware element. "virtualized resources" may refer to computing, storage, and/or network resources provided by a virtualization infrastructure to an application, device, system, etc. The term "network resource" or "communication resource" may refer to a resource accessible to a computer device/system via a communication network. The term "system resource" may refer to any kind of shared entity for providing a service, and may include computing and/or network resources. System resources may be viewed as a collection of consistent functions, network data objects, or services that may be accessed by a server, where these system resources reside on a single host or multiple hosts and are clearly identifiable.

The term "workload" refers to the amount of work performed by a computing system, device, entity, etc., during a period of time or at a particular moment in time. The workload may be represented as a benchmark (e.g., response time, throughput (e.g., how much work is done within a time period), etc.). Additionally or alternatively, the workload may be represented as a memory workload (e.g., the amount of memory space required for program execution to store temporary or permanent data and perform intermediate computations), a processor workload (e.g., the number of instructions being executed by the processor during a given time period or at a particular time), an I/O workload (e.g., the number of inputs and outputs or system accesses during a given time period or at a particular time), a database workload (e.g., the number of database queries during a time period), a network-related workload (e.g., the number of network attachments, the number of mobility updates, the number of radio link failures, the number of handovers, the amount of data to be communicated over the air interface, etc.), and so forth. Various algorithms may be used to determine the workload and/or workload characteristics, which may be based on any of the aforementioned workload types.

As used herein, the term "cloud service provider" (or CSP) indicates an organization that typically operates large-scale "cloud" resources (e.g., used in the context of a public cloud) composed of centralized, regional, and edge data centers. In other examples, the CSP may also be referred to as a Cloud Service Operator (CSO). References to "cloud computing" generally refer to computing resources and services provided by a CSP or CSO at a remote location having at least an increased latency, distance, or constraint relative to edge computing.

As used herein, the term "data center" refers to a specially designed structure intended to accommodate multiple high performance computing and data storage nodes such that a large amount of computing, data storage, and network resources exist at a single location. This typically necessitates dedicated rack and enclosure systems, appropriate heating, cooling, ventilation, safety, fire suppression and power delivery systems. In some contexts, the term may also refer to compute and data storage nodes. The data centers may scale between a centralized or cloud data center (e.g., max), an area data center, and an edge data center (e.g., min).

As used herein, the term "access edge layer" indicates the sub-layer closest to the infrastructure edge of an end user or device. For example, such a layer may be implemented by an edge data center deployed at a cellular network site. The access edge layer operates as a front line of the infrastructure edge and can connect to higher aggregation edge layers in the hierarchy.

As used herein, the term "aggregate edge layer" indicates a layer of the infrastructure edge that is one hop away from the access edge layer. This tier may exist as a medium-scale data center in a single location, or may be formed by multiple interconnected mini-data centers to form a hierarchical topology with the access edge to allow better collaboration, workload failover, and scalability than a single access edge.

As used herein, the term "network function virtualization" (or NFV) indicates the migration of NFs from embedded services inside private hardware devices to standardized CPUs (e.g., within a standard) using industry standard virtualization and cloud computing technologiesAndwithin a server, e.g. comprisingXeon^TMOrEpyc^TMOr Opteron^TMA CPU of a processor) is executed. In some aspects, NFV processing and data storage will occur within the infrastructure edge directly connected to the local cellAt the edge data center of the site.

As used herein, the term "virtualized NF" (or VNF) indicates a software-based NF operating on a multi-function, multi-purpose computing resource (e.g., x86, ARM processing architecture) that is used by the NFV in place of a dedicated physical device. In some aspects, several VNFs will operate on edge data centers at the edge of the infrastructure.

As used herein, the term "edge compute node" refers to a real-world, logical, or virtualized implementation of a computing-capable element in the form of a device, gateway, bridge, system or subsystem, component, whether operating in server, client, endpoint, or peer-to-peer mode, and whether located at the "edge" of a network or at a more distant connection location within a network. As used herein, references to "nodes" are generally interchangeable with "devices," "components," and "subsystems"; however, references to an "edge computing system" generally refer to a distributed architecture, organization, or collection of multiple nodes and devices, and which are organized to accomplish or provide some aspect of a service or resource in an edge computing environment.

As used herein, the term "cluster" refers to a collection or grouping of entities that are part of one edge computing system (or multiple systems), logical entities (e.g., applications, functions, security constructs, containers), etc., in the form of physical entities (e.g., different computing systems, networks, or groups of networks). In some locations, a "cluster" is also referred to as a "group" or "domain". The membership of the cluster may be modified or acted upon based on conditions or functions, including according to dynamic or attribute-based membership, according to network or system management scenarios, or according to various example techniques discussed below in which entities may be added, modified, or deleted in the cluster. The cluster may further include or be associated with a plurality of layers, levels, or attributes (including changes in security features and results based on those layers, levels, or attributes).

As used herein, the term "radio technology" refers to technology for the wireless transmission and/or reception of electromagnetic radiation for the transfer of information. The term "radio access technology" or "RAT" refers to a technology used for the underlying physical connection to a radio-based communication network. The term "V2X" refers to vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), infrastructure-to-vehicle (I2V), vehicle-to-network (V2N), and/or network-to-vehicle (N2V) communication and associated Radio Access Technologies (RATs).

As used herein, the term "communication protocol" (wired or wireless) refers to a standardized set of rules or instructions implemented by a communication device and/or system to communicate with other devices and/or systems, including implementations for packetizing/depacketizing data, modulating/demodulating signals, protocol stacks, and the like. The term "channel" as used herein refers to any tangible or intangible transmission medium to communicate data or a stream of data. The term "channel" may be synonymous and/or equivalent to "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," and/or any other similar term denoting a path or medium through which data is communicated. Additionally, the term "link" as used herein refers to a connection between two devices over a RAT in order to send and receive information.

The term "quality of service" or "QoS" refers to a description or measurement of the overall performance of a service (e.g., telephony and/or cellular services, network services, wireless communication/connectivity services, cloud computing services, etc.). In some cases, QoS may be described or measured from the perspective of a user of the service, and thus, QoS may be a common effect of service performance in determining a degree of satisfaction of the user of the service. In other cases, QoS refers to traffic priority and resource reservation control mechanisms, rather than the perception of the quality of service achieved. In these cases, QoS is the ability to provide different priorities to different applications, users, or data flows or to guarantee a particular level of performance for a data flow. In either case, the QoS features a combination of performance factors (e.g., such as service operability performance, service accessibility performance, service reservation capability performance, service reliability performance, service integrity performance, and other factors specific to each service) that apply to one or more services. When quantifying QoS, several relevant aspects of the service may be considered, including packet loss rate, bit rate, throughput, transmission delay, availability, reliability, jitter, signal strength and/or quality measurements and/or other measurements (e.g., the measurements discussed herein).

The terms "instantiate," "instantiate," and the like as used herein refer to the creation of an instance. An "instance" also refers to a specific occurrence of an object, such as may occur during execution of program code. The term "information element" refers to a structural element that contains one or more fields. The term "field" refers to either the individual content of an information element or a data element containing content. The terms "database object," "data structure," and the like may refer to any representation of information in the form of objects, Attribute Value Pairs (AVPs), Key Value Pair (KVP) tuples, and the like, and may include variables, data structures, functions, methods, classes, database records, database fields, database entities, associations (also referred to as "relationships") between data and/or database entities, links between blocks and blocks in a block chain implementation, and the like. The term "data element" or "DE" refers to a data type that contains a single datum. The term "dataframe" or "DF" refers to a data type that contains more than one data element in a predetermined order.

As used herein, the term "reliability" refers to the ability of a computer-related component (e.g., software, hardware, or network element/entity) to consistently perform desired functions and/or operate in accordance with a specification. Reliability in the context of network communications (e.g., "network reliability") may refer to the ability of a network to perform communications. Network reliability may also be (or measure) the probability of delivering a specified amount of data from a source to a sink (or sink).

The term "application" may refer to a complete and deployable package, environment for implementing specific functionality in an operating environment. The term "AI/ML application" or the like can be an application that contains some AI/ML models and application level descriptions. The term "machine learning" or "ML" refers to the use of a computer system that implements algorithms and/or statistical models to perform specific tasks without the use of explicit instructions, but instead rely on patterns and inferences. ML algorithms build or estimate mathematical models (referred to as "ML models" or the like) based on sample data (referred to as "training data," "model training information," or the like) to make predictions or decisions without explicit programming to perform such tasks. In general, an ML algorithm is a computer program that learns from experience with some task and some performance measure, while an ML model may be any object or data structure that is created after training the ML algorithm with one or more training data sets. After training, the ML model may be used to predict a new data set. Although the term "ML algorithm" refers to a different concept than the term "ML model," these terms discussed herein may be used interchangeably for purposes of this disclosure.

While many of the previous examples are provided through the use of specific cellular/mobile network terminology, including through the use of 4G/5G3GPP network components (or contemplated terahertz-based 6G/6G + technology), it will be appreciated that these examples may be applied to many other deployments of wide and local wireless networks, as well as the integration of wired networks, including optical networks and associated optical fibers, transceivers, etc.

While these implementations have been described with reference to specific exemplary aspects, it will be evident that various modifications and changes may be made to these aspects without departing from the broader scope of the disclosure. Many of the arrangements and processes described herein may be used in combination or in parallel implementations to provide greater bandwidth/throughput and support edge service selection that may be made available to the edge systems being serviced. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof show by way of illustration, and not of limitation, specific aspects in which the subject matter may be practiced. The aspects illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other aspects may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. The detailed description is, therefore, not to be taken in a limiting sense, and the scope of various aspects is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

These aspects of the inventive subject matter may be referred to herein, individually and/or collectively, merely for convenience and without intending to voluntarily limit the scope of this application to any single aspect or inventive concept if more than one is in fact disclosed. Thus, although specific aspects have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific aspects shown. This disclosure is intended to cover any and all adaptations or variations of various aspects. Combinations of the above aspects and other aspects not specifically described herein will be apparent to those of skill in the art upon reviewing the above description.