Google Patentsopen access

Multi-slice support for MEC-enabled 5G deployments — Intel Corporation (US12047986B2)

ABSTRACT

Abstract

A system configured to track network slicing operations within a 5G communication network includes processing circuitry configured to determine a network slice instance (NSI) associated with a QoS flow of a UE. The NSI communicates data for a network function virtualization (NFV) instance of a Multi-Access Edge Computing (MEC) system within the 5G communication network. Latency information for a plurality of communication links used by the NSI is retrieved. The plurality of communication links includes a first set of non-MEC communication links associated with a radio access network (RAN) of the 5G communication network and a second set of MEC communication links associated with the MEC system. A slice configuration policy is generated based on the retrieved latency information and slice-specific attributes of the NSI. Network resources of the 5G communication network used by the NSI are reconfigured based on the generated slice configuration policy.

Description

PRIORITY CLAIM

This application is a continuation of U.S. patent application Ser. No. 17/430,282, filed Aug. 11, 2021, which is a U.S. National Stage Filing under 35 U.S.C. 371 from International Application No. PCT/US2020/021914, filed Mar. 10, 2020 and published in English as WO 2020/185794 on Sep. 17, 2020, which claims the benefit of priority to the U.S. Provisional Patent Application Ser. No. 62/816,616, filed Mar. 11, 2019, and titled “E2E MULTI-SLICE SUPPORT FOR MEC-ENABLED 5G DEPLOYMENTS,” each of which application is incorporated herein by reference in its entirety.

TECHNICAL FIELD

Embodiments described herein generally relate to data processing, network communication, and communication system implementations, and in particular, to techniques for implementing end-to-end (E2E) support for multi-access edge computing (MEC)-enabled 5G deployments.

BACKGROUND

Internet-of-Things (IoT) devices are physical or virtualized objects that may communicate on a network and may include sensors, actuators, and other input/output components, such as to collect data or perform actions from the real-world environment. For example, IoT devices may include low-powered endpoint devices that are embedded or attached to everyday things, such as buildings, vehicles, packages, etc., to provide an additional level of artificial sensory perception of those things. Recently, IoT devices have become more popular and thus applications using these devices have proliferated.

Edge computing, at a more general level, refers to the movement of compute and storage resources closer to, or into, smart endpoint devices to optimize total cost of ownership, reduce application latency, improve service capabilities, and improve compliance with security or data privacy requirements. Edge computing may in some scenarios provide a cloud-like distributed service, which offers orchestration and management for applications among many types of storage and compute resources. Edge computing may be further integrated with use cases and technology developed for the IoT and Fog networking, as endpoint devices and gateways attempt to access network resources and applications at locations moved closer to the “edge” of the network.

MEC encompasses architectures that enable cloud computing functionality or information technology (IT) services at the network (e.g., cellular network) edges. MEC may reduce network congestion by moving applications, data, discovery, etc. closer to the user (e.g., mobile device, user equipment (UE), station (STA), etc.). Some MEC details dealing with security (e.g., both user security as well as application integrity), radio use, etc., have been promulgated by European Telecommunications Standards Institute (ETSI), such as described in the “Mobile Edge Computing Introductory Technical White Paper,” published Sep. 1, 2014. A set of specifications and white papers providing further details and implementation use cases for MEC scenarios is being developed and published on an ongoing basis by ETSI as part of the ETSI MEC industry specification group (ISG).

The MEC environment is characterized by ultra-low latency and high bandwidth as well as real-time access to radio network information that may be leveraged by applications. MEC technology permits operators to flexibly and rapidly deploy innovative applications and services towards mobile subscribers, enterprises and vertical segments. MEC is intended to support developing mobile use cases of edge computing, to allow application developers and content providers to access computing capabilities and an IT service environment in dynamic settings at the edge of the network. In these and other settings, edge computing attempts to offer reduced latency, increased responsiveness, and more available computing power than offered in traditional cloud network services and wide area network connections. Despite the rapid activity occurring with the development of standards and architectures involving these technologies, many limitations and technical problems still exist in the design and use of IoT, MEC, and next-generation edge networks.

BRIEF DESCRIPTION OF THE 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 limitation, in the figures of the accompanying drawings in which:

FIG. 1 A illustrates a MEC communication infrastructure with a common core network, the MEC infrastructure including slice management, resource management, and traceability functions, according to an example;

FIG. 1 B illustrates an overview of an edge cloud configuration for edge computing, according to an example;

FIG. 2 A illustrates an example Cellular Internet-of-Things (CIoT) network architecture with a MEC host using a MEC QoS manager, according to an example;

FIG. 2 B illustrates an example Service Capability Exposure Function (SCEF) used by the CIoT network architecture of FIG. 2 A , according to an example;

FIG. 3 A is a simplified diagram of an exemplary Next-Generation (NG) system architecture with a MEC host using a MEC QoS manager, according to an example;

FIG. 3 B illustrates an exemplary functional split between next generation radio access network (NG-RAN) and the 5G Core network (5GC) in connection with the NG system architecture of FIG. 3 A , according to an example;

FIG. 3 C and FIG. 3 D illustrate non-roaming 5G system architectures with a MEC host using resource management and traceability functions, according to an example;

FIG. 3 E illustrates components of an exemplary 5G-NR architecture with control unit control plane (CU-CP)—control unit user plane (CU-UP) separation, according to an example;

FIG. 3 F illustrates a user plane protocol stack, according to an example;

FIG. 3 G illustrates examples of network slices, according to an example;

FIG. 4 A illustrates a MEC network architecture modified for supporting slice management, resource management, and traceability functions, according to an example;

FIG. 4 B illustrates a MEC reference architecture in a Network Function Virtualization (NFV) environment, according to an example;

FIG. 5 illustrates a MEC and FOG network topology, according to an example;

FIG. 6 illustrates the processing and storage layers in a MEC and FOG network, according to an example;

FIG. 7 illustrates a domain topology for respective Internet-of-Things (IoT) networks coupled through links to respective gateways, according to an example;

FIG. 8 illustrates a cloud-computing network in communication with a mesh network of computing devices operating as fog devices at the edge of the cloud computing network, according to an example;

FIG. 9 illustrates a block diagram of a cloud computing network in communication with several computing devices, according to an example;

FIG. 10 A illustrates an overview of example components deployed at a compute node system, according to an example;

FIG. 10 B illustrates a further overview of example components within a computing device for implementing the techniques (e.g., operations, processes, methods, and methodologies) described herein, according to an example;

FIG. 11 illustrates a 3GPP-based 5G system architecture and example of the mapping of MEC entities to some of the 5G system's components (namely, AF and UPF), according to an example;

FIG. 12 illustrates aspects of the disclosed techniques for E2E multi-slice support for MEC-enabled 5G deployments, according to an example;

FIG. 13 illustrates a flowchart of disclosed techniques for slice-aware VM allocation in MEC-enabled 5G system deployments, according to an example;

FIG. 14 is a message sequence chart illustrating the various latency components during the direct communication between a UE client and a MEC app at the edge (which consumes some MEC services running on the MEC platform), according to an example;

FIG. 15 is a message sequence chart illustrating example communication for deriving and implementing a slice-aware VM allocation policy, according to an example; and

FIG. 16 A - FIG. 16 H illustrate various example and implementation aspects of techniques disclosed herein.

DETAILED DESCRIPTION

In the following description, methods, configurations, and related apparatuses are disclosed for support for multi-slice support for MEC-enabled deployments. As an overview, the technological solutions disclosed herein integrate MEC with various types of implementations as well as dynamic network slicing and resource utilization management. These may benefit a variety of use cases, such as fifth-generation (5G) network communications among automotive devices, including those use cases termed as vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X). As with most MEC installations, the goal with the present configurations is to bring the application endpoints as close to the vehicular environment, or other endpoints, as possible and to dynamically adjust compute resources as well as resources used by one or more network (e.g., 5G) slices to enable low latency or high bandwidth services with optimal QoS. These systems and techniques may be implemented in, or augment, virtualized environments that may be implemented within various types of MEC, network function virtualization (NFV), or fully virtualized 5G network environments.

As is understood, MEC architectures offer application developers and content providers cloud-computing capabilities and an IT service environment at the edge of the network. This environment offers ultra-low latency and high bandwidth throughput as well as real-time access to radio network information that may be leveraged by applications. MEC technology permits flexible and rapid deployments of innovative applications and services towards mobile subscribers, enterprises, or vertical segments.

The present techniques and configurations may be utilized in connection with many aspects of current networking systems, but are provided with reference to IoT, MEC, and NFV deployments. The present techniques and configurations specifically may be (but are not required to be) relevant to the standards and approaches published in ETSI GS MEC-003 “Mobile Edge Computing (MEC); Framework and Reference Architecture” (e.g., V2.0.3); ETSI GR MEC-024 “Support for Network Slicing”; ETSI GS NFV-SEC 013 “Network Functions Virtualization (NFV) Release 3; Security; Security Management and Monitoring” (e.g., v. 3.1.1) and related MEC, NFV, or networked operational implementations. However, while the present techniques and configurations may provide significant benefits to MEC architectures and other IoT device network architectures, the applicability of the present techniques and configurations may be extended to any number of edge computing devices or fog computing platforms.

The following provides a detailed discussion of these techniques within specific systems and services, but which applies to the larger context of IoT, Fog network, and edge computing deployments. Further, the disclosed MEC architectures and service deployment examples provide one illustrative example of a Fog device or Fog system, but many other combinations and layouts of devices and systems located at the edge of a network may be provided. Further, the techniques disclosed herein may relate to other IoT and network communication standards and configurations, and other intermediate processing entities and architectures.

Techniques disclosed herein are focused on the role of Multi-access Edge Computing (MEC) in supporting 5G network slicing. In some aspects, techniques disclosed herein can be used to achieve and guarantee E2E latency requirements of a network slice when instantiated in a MEC-enabled 5G deployments using a slice control function (SCF) within a network function virtualization (NFV) domain (also referred to as NFV-SCF). The discussed communication systems incorporate a MEC system, the architecture of which (including the various MEC-related interfaces and reference points) is specified in ETSI GS MEC-003 and ETSI GR MEC-024, deployed in a 5G system (which may or may not be virtualized), the system architecture of which is specified in at least 3GPP TS 23.501. In some aspects, the 5G system may be fully virtualized, with all logical functions (i.e., network functions (NFs) and also application functions (AFs)) being virtualized. Various MEC-related interfaces and reference points discussed herein are further defined in the following ETSI-related technical specifications: ETSI GS MEC-003 and ETSI GR MEC-024 specifications.

More specifically, the NFV-SCF is configured to perform E2E latency function modeling and evaluation using latency information obtained from network management nodes of the 5G system as well as the MEC system, and identify delay bottlenecks associated with E2E communications within a network slice. The NFV-SCF further generates a slice configuration policy to optimize the instantiation of MEC application (apps) and the allocation of virtualized resources (e.g., virtual machines or VMs) across the edge cloud, according to a slice-aware strategy based on the E2E latency function modeling and evaluation. In this regard, the NFV-SCF may be used to dynamically monitor and reconfigure network resources used by network slice instances to meet E2E performance requirements of the slice (which may be part of a Service Level Agreement (SLA), between the network operator and a vertical industry).

FIG. 1 A illustrates a MEC communication infrastructure 100 A with a common core network, the MEC infrastructure including slice management, resource management, and traceability functions, according to an example. The connections represented by some form of a dashed line (as noted in the legend in FIG. 1

PRIORITY CLAIM

This application is a continuation of U.S. patent application Ser. No. 17/430,282, filed Aug. 11, 2021, which is a U.S. National Stage Filing under 35 U.S.C. 371 from International Application No. PCT/US2020/021914, filed Mar. 10, 2020 and published in English as WO 2020/185794 on Sep. 17, 2020, which claims the benefit of priority to the U.S. Provisional Patent Application Ser. No. 62/816,616, filed Mar. 11, 2019, and titled “E2E MULTI-SLICE SUPPORT FOR MEC-ENABLED 5G DEPLOYMENTS,” each of which application is incorporated herein by reference in its entirety.

TECHNICAL FIELD

Embodiments described herein generally relate to data processing, network communication, and communication system implementations, and in particular, to techniques for implementing end-to-end (E2E) support for multi-access edge computing (MEC)-enabled 5G deployments.

BACKGROUND

Internet-of-Things (IoT) devices are physical or virtualized objects that may communicate on a network and may include sensors, actuators, and other input/output components, such as to collect data or perform actions from the real-world environment. For example, IoT devices may include low-powered endpoint devices that are embedded or attached to everyday things, such as buildings, vehicles, packages, etc., to provide an additional level of artificial sensory perception of those things. Recently, IoT devices have become more popular and thus applications using these devices have proliferated.

Edge computing, at a more general level, refers to the movement of compute and storage resources closer to, or into, smart endpoint devices to optimize total cost of ownership, reduce application latency, improve service capabilities, and improve compliance with security or data privacy requirements. Edge computing may in some scenarios provide a cloud-like distributed service, which offers orchestration and management for applications among many types of storage and compute resources. Edge computing may be further integrated with use cases and technology developed for the IoT and Fog networking, as endpoint devices and gateways attempt to access network resources and applications at locations moved closer to the “edge” of the network.

MEC encompasses architectures that enable cloud computing functionality or information technology (IT) services at the network (e.g., cellular network) edges. MEC may reduce network congestion by moving applications, data, discovery, etc. closer to the user (e.g., mobile device, user equipment (UE), station (STA), etc.). Some MEC details dealing with security (e.g., both user security as well as application integrity), radio use, etc., have been promulgated by European Telecommunications Standards Institute (ETSI), such as described in the “Mobile Edge Computing Introductory Technical White Paper,” published Sep. 1, 2014. A set of specifications and white papers providing further details and implementation use cases for MEC scenarios is being developed and published on an ongoing basis by ETSI as part of the ETSI MEC industry specification group (ISG).

The MEC environment is characterized by ultra-low latency and high bandwidth as well as real-time access to radio network information that may be leveraged by applications. MEC technology permits operators to flexibly and rapidly deploy innovative applications and services towards mobile subscribers, enterprises and vertical segments. MEC is intended to support developing mobile use cases of edge computing, to allow application developers and content providers to access computing capabilities and an IT service environment in dynamic settings at the edge of the network. In these and other settings, edge computing attempts to offer reduced latency, increased responsiveness, and more available computing power than offered in traditional cloud network services and wide area network connections. Despite the rapid activity occurring with the development of standards and architectures involving these technologies, many limitations and technical problems still exist in the design and use of IoT, MEC, and next-generation edge networks.

BRIEF DESCRIPTION OF THE 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 limitation, in the figures of the accompanying drawings in which:

FIG. 1 A illustrates a MEC communication infrastructure with a common core network, the MEC infrastructure including slice management, resource management, and traceability functions, according to an example;

FIG. 1 B illustrates an overview of an edge cloud configuration for edge computing, according to an example;

FIG. 2 A illustrates an example Cellular Internet-of-Things (CIoT) network architecture with a MEC host using a MEC QoS manager, according to an example;

FIG. 2 B illustrates an example Service Capability Exposure Function (SCEF) used by the CIoT network architecture of FIG. 2 A , according to an example;

FIG. 3 A is a simplified diagram of an exemplary Next-Generation (NG) system architecture with a MEC host using a MEC QoS manager, according to an example;

FIG. 3 B illustrates an exemplary functional split between next generation radio access network (NG-RAN) and the 5G Core network (5GC) in connection with the NG system architecture of FIG. 3 A , according to an example;

FIG. 3 C and FIG. 3 D illustrate non-roaming 5G system architectures with a MEC host using resource management and traceability functions, according to an example;

FIG. 3 E illustrates components of an exemplary 5G-NR architecture with control unit control plane (CU-CP)—control unit user plane (CU-UP) separation, according to an example;

FIG. 3 F illustrates a user plane protocol stack, according to an example;

FIG. 3 G illustrates examples of network slices, according to an example;

FIG. 4 A illustrates a MEC network architecture modified for supporting slice management, resource management, and traceability functions, according to an example;

FIG. 4 B illustrates a MEC reference architecture in a Network Function Virtualization (NFV) environment, according to an example;

FIG. 5 illustrates a MEC and FOG network topology, according to an example;

FIG. 6 illustrates the processing and storage layers in a MEC and FOG network, according to an example;

FIG. 7 illustrates a domain topology for respective Internet-of-Things (IoT) networks coupled through links to respective gateways, according to an example;

FIG. 8 illustrates a cloud-computing network in communication with a mesh network of computing devices operating as fog devices at the edge of the cloud computing network, according to an example;

FIG. 9 illustrates a block diagram of a cloud computing network in communication with several computing devices, according to an example;

FIG. 10 A illustrates an overview of example components deployed at a compute node system, according to an example;

FIG. 10 B illustrates a further overview of example components within a computing device for implementing the techniques (e.g., operations, processes, methods, and methodologies) described herein, according to an example;

FIG. 11 illustrates a 3GPP-based 5G system architecture and example of the mapping of MEC entities to some of the 5G system's components (namely, AF and UPF), according to an example;

FIG. 12 illustrates aspects of the disclosed techniques for E2E multi-slice support for MEC-enabled 5G deployments, according to an example;

FIG. 13 illustrates a flowchart of disclosed techniques for slice-aware VM allocation in MEC-enabled 5G system deployments, according to an example;

FIG. 14 is a message sequence chart illustrating the various latency components during the direct communication between a UE client and a MEC app at the edge (which consumes some MEC services running on the MEC platform), according to an example;

FIG. 15 is a message sequence chart illustrating example communication for deriving and implementing a slice-aware VM allocation policy, according to an example; and

FIG. 16 A - FIG. 16 H illustrate various example and implementation aspects of techniques disclosed herein.

DETAILED DESCRIPTION

In the following description, methods, configurations, and related apparatuses are disclosed for support for multi-slice support for MEC-enabled deployments. As an overview, the technological solutions disclosed herein integrate MEC with various types of implementations as well as dynamic network slicing and resource utilization management. These may benefit a variety of use cases, such as fifth-generation (5G) network communications among automotive devices, including those use cases termed as vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X). As with most MEC installations, the goal with the present configurations is to bring the application endpoints as close to the vehicular environment, or other endpoints, as possible and to dynamically adjust compute resources as well as resources used by one or more network (e.g., 5G) slices to enable low latency or high bandwidth services with optimal QoS. These systems and techniques may be implemented in, or augment, virtualized environments that may be implemented within various types of MEC, network function virtualization (NFV), or fully virtualized 5G network environments.

As is understood, MEC architectures offer application developers and content providers cloud-computing capabilities and an IT service environment at the edge of the network. This environment offers ultra-low latency and high bandwidth throughput as well as real-time access to radio network information that may be leveraged by applications. MEC technology permits flexible and rapid deployments of innovative applications and services towards mobile subscribers, enterprises, or vertical segments.

The present techniques and configurations may be utilized in connection with many aspects of current networking systems, but are provided with reference to IoT, MEC, and NFV deployments. The present techniques and configurations specifically may be (but are not required to be) relevant to the standards and approaches published in ETSI GS MEC-003 “Mobile Edge Computing (MEC); Framework and Reference Architecture” (e.g., V2.0.3); ETSI GR MEC-024 “Support for Network Slicing”; ETSI GS NFV-SEC 013 “Network Functions Virtualization (NFV) Release 3; Security; Security Management and Monitoring” (e.g., v. 3.1.1) and related MEC, NFV, or networked operational implementations. However, while the present techniques and configurations may provide significant benefits to MEC architectures and other IoT device network architectures, the applicability of the present techniques and configurations may be extended to any number of edge computing devices or fog computing platforms.

The following provides a detailed discussion of these techniques within specific systems and services, but which applies to the larger context of IoT, Fog network, and edge computing deployments. Further, the disclosed MEC architectures and service deployment examples provide one illustrative example of a Fog device or Fog system, but many other combinations and layouts of devices and systems located at the edge of a network may be provided. Further, the techniques disclosed herein may relate to other IoT and network communication standards and configurations, and other intermediate processing entities and architectures.

Techniques disclosed herein are focused on the role of Multi-access Edge Computing (MEC) in supporting 5G network slicing. In some aspects, techniques disclosed herein can be used to achieve and guarantee E2E latency requirements of a network slice when instantiated in a MEC-enabled 5G deployments using a slice control function (SCF) within a network function virtualization (NFV) domain (also referred to as NFV-SCF). The discussed communication systems incorporate a MEC system, the architecture of which (including the various MEC-related interfaces and reference points) is specified in ETSI GS MEC-003 and ETSI GR MEC-024, deployed in a 5G system (which may or may not be virtualized), the system architecture of which is specified in at least 3GPP TS 23.501. In some aspects, the 5G system may be fully virtualized, with all logical functions (i.e., network functions (NFs) and also application functions (AFs)) being virtualized. Various MEC-related interfaces and reference points discussed herein are further defined in the following ETSI-related technical specifications: ETSI GS MEC-003 and ETSI GR MEC-024 specifications.

More specifically, the NFV-SCF is configured to perform E2E latency function modeling and evaluation using latency information obtained from network management nodes of the 5G system as well as the MEC system, and identify delay bottlenecks associated with E2E communications within a network slice. The NFV-SCF further generates a slice configuration policy to optimize the instantiation of MEC application (apps) and the allocation of virtualized resources (e.g., virtual machines or VMs) across the edge cloud, according to a slice-aware strategy based on the E2E latency function modeling and evaluation. In this regard, the NFV-SCF may be used to dynamically monitor and reconfigure network resources used by network slice instances to meet E2E performance requirements of the slice (which may be part of a Service Level Agreement (SLA), between the network operator and a vertical industry).

FIG. 1 A illustrates a MEC communication infrastructure 100 A with a common core network, the MEC infrastructure including slice management, resource management, and traceability functions, according to an example. The connections represented by some form of a dashed line (as noted in the legend in FIG. 1 A ) may be defined according to a specification from an ETSI MEC standards family.

The MEC communication infrastructure 100 A can include entities from a MEC-based architecture as well as entities from a third-generation partnership project (3GPP) based architecture. For example, the MEC communication infrastructure 100 A can include a plurality of MEC hosts such as MEC hosts 102 and 104 , a MEC platform manager 106 , and a MEC orchestrator 108 . The 3GPP based entities can include a centralized core network (CN) 110 coupled to an application server 114 via the network 112 (e.g., the Internet), as well as radio access networks (RANs) represented by base stations

148 and 150 coupled to corresponding user equipments (UEs) 152 and 154 . The base stations

148 and 150 can include evolved Node-Bs (eNBs), Next Generation Node-Bs (gNBs), or other types of base stations operating in connection with a 3GPP wireless family of standards or another type of wireless standard.

In some aspects, the MEC communication infrastructure 100 A can be implemented by different network operators in the same country and/or in different countries, using different network traffic types. For example, the radio access network associated with base station 148 (with a coverage area 149 ) can be within a first public land mobile network (PLMN) (i.e., associated with a first mobile services provider or operator and a first network traffic type), and base station 150 (with a coverage area 151 ) can be within a second public land mobile network (PLMN) (i.e., associated with a second mobile services provider or operator and a second network traffic type). As used herein, the terms “mobile services provider” and “mobile services operator” are interchangeable.

In this regard, the MEC communication infrastructure 100 A can be associated with a multi-operator scenario composed of two coverage areas

149 and 151 where communication services (e.g., V2X services) can be provided, with each coverage area being operated by a mobile services operator. Additionally, each of the UEs

152 and 154 can be configured for network slice operation, where each UE can use one or more types of network slice instances configured by, e.g., the core network 110 using the slice management functionality 164 in coordination with one or more entities of the MEC communication infrastructure 100 A, such as the MEC network function virtualization (NFV) slice control function (SCF) (MEC NFV-SCF) (e.g., 121 and 131 ). Techniques disclosed herein can be used to provide E2E multi-slice support for MEC-enabled 5G deployments using the MEC NFV-SCF. In some aspects, the MEC NFV- SCF 121 can be within an NFV orchestrator (NFVO) 160 , which can be coupled to the MEC orchestrator 108 , as well as to other MEC entities, as illustrated in FIG. 4 B , FIG. 11 , and FIG. 12 .

The solid line connections in FIG. 1 A represent non-MEC connections (or reference points), such as utilizing 3GPP cellular network connections S1, S1-AP, etc. Other connection techniques (e.g., protocols) and connections may also be used. Accordingly, in the scenario of FIG. 1 A , the MEC system entities (e.g., the MEC orchestrator 108 , the MEC platform manager 106 , the MEC hosts 102 , 104 are connected by MEC (or NFV) logical links (indicated with dashed lines), in addition to network infrastructure links (e.g., a 5G Long Term Evolution (LTE) network, such as provided among UEs

152 , 154 , eNBs

148 , 150 , a CN site 110 , etc.) (indicated with solid lines). A further connection to cloud services (e.g., an application server 114 access via the network 112 ) may also be connected via backhaul network infrastructure links.

Techniques disclosed herein apply to 2G/3G/4G/LTE/LTE-A (LTE Advanced) and 5G networks, with the examples and aspects disclosed using 4G/LTE networks. In aspects, the CN 110 may be an evolved packet core (EPC) network, a NextGen Packet Core (NPC) network (e.g., a 5G network), or some other type of CN (e.g., as illustrated in reference to FIGS. 2 A- 3 E ). In an EPC (Evolved Packet Core), which is associated with 4G/LTE, the CN 110 can include a serving gateway (S-GW or SGW) 138 , a packet data network (PDN) gateway (P-GW or PGW) 140 , a mobility management entity (MME) 142 , and a home subscriber server (HSS) 144 coupled to a V2X control function 146 . In the Core Network is referred to as the NextGen Packet Network (NPC). In NPC (and as illustrated in FIGS. 3 A- 3 D ), the S/P-GW is replaced with a user plane function (UPF), and the MME is replaced with two individual functional components, the Access Management Function (AMF) and the Session Management Function (SMF). The 4G HSS is split into different entities in 5G: the Authentication Server Function (AUSF) and the Universal Data Management (UDM), with the subscription data being managed via the Universal Data Management (UDM) function. In EPC, the S1 interface can be split into two parts: the S1-U (user plane) interface which carries traffic data between the eNBs

148 , 150 and the S- GW 138 via the MEC hosts 102 , 104 , and the S1-AP (control plane) interface which is a signaling interface between the eNBs

148 , 150 and the MME 142 .

The MME 142 may be similar in function to the control plane of legacy Serving General Packet Radio Service (GPRS) Support Nodes (SGSN). The MME 142 may manage mobility aspects in access such as gateway selection and tracking area list management. The HSS 144 may comprise a database for network users, including subscription-related information to support the network entities' handling of communication sessions, including subscription information associated with V2X communications. The CN 110 may comprise one or several HSSs 144 , depending on the number of mobile subscribers, on the capacity of the equipment, on the organization of the network, etc. For example, the HSS 144 can provide support for routing/roaming, authentication, authorization (e.g., V2X communication authorization), naming/addressing resolution, location dependencies, etc.

The S- GW 138 may terminate the S1 interface 413 towards the RANs of eNBs

148 , 150 , and route data packets between the RANs and the CN 110 . Also, the S- GW 138 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include charging and some policy enforcement.

The P- GW 140 may terminate an SGi interface toward a PDN. The P- GW 140 may route data packets between the RANs and external networks such as a network including the application server (AS) 114 (alternatively referred to as application function (AF)) via an Internet Protocol (IP) interface (e.g., an interface to the network 112 coupled to the AS 114 . The P- GW 140 can also communicate data to other external networks, which can include the Internet, IP multimedia subsystem (IPS) network, and other networks. Generally, the application server 114 may be an element offering applications that use IP bearer resources with the core network (e.g., UMTS Packet Services (PS) domain, LTE PS data services, etc.). The application server 114 can also be configured to support one or more communication services (e.g., Voice-over-Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UEs

152 , 154 via the CN 110 and one or more of the MEC hosts 102 , 104 .

The P- GW 140 may further include a node for policy enforcement and charging data collection. A Policy and Charging Enforcement Function (PCRF) (not illustrated in FIG. 1 A ) can be the policy and charging control element of the CN 110 . In a non-roaming scenario, there may be a single PCRF in the Home Public Land Mobile Network (HPLMN) associated with a UE's Internet Protocol Connectivity Access Network (IP-CAN) session. In a roaming scenario with a local breakout of traffic, there may be two PCRFs associated with a UE's IP-CAN session: a Home PCRF (H-PCRF) within an HPLMN and a Visited PCRF (V-PCRF) within a Visited Public Land Mobile Network (VPLMN). The PCRF may be communicatively coupled to the application server 114 via the P- GW 140 . The application server 114 may signal the PCRF to indicate a new service flow and select the appropriate Quality of Service (QoS) and charging parameters.

The V2X control function 146 is used in connection with authorizing UEs to use V2X services based on HSS information (e.g., subscription information managed by the HSS 144 ), assist one or more UEs in obtaining the network address of an application server (e.g., 114 ) or a V2X application server, as well as providing V2X configuration parameters for direct communication (i.e., device-to-device communications). The interface for direct device-to-device communication is referred to as PC5. The PC5 parameters may be provided by the V2X control function 146 to one or more UEs for purposes of configuring V2X communication between the UEs.

The slice management function 164 can be used for configuring one or more network slice instances (NSIs) (e.g., 5G slices or 5G NSIs) for use by UEs or other devices within the communication architecture 100 A, where the slice configuration maybe with the assistance of the MEC NFV-SCF (e.g., 121 and 131 ) as discussed herein.

The MEC hosts 102 , . . . , 104 can be configured per the ETSI GS MEC-003 and ETSI GR MEC-024 specifications. The MEC host 102 can include a MEC platform 118 , which can be coupled to one or more MEC applications (apps) such as MEC apps 116 A, . . . , 116 N (collectively, MEC app 116 ) and to a MEC data plane 122 . The MEC host 104 can include a MEC platform 126 , which can be coupled to a MEC app 116 and a MEC data plane 130 . The MEC platform manager 106 can include a MEC platform element management module 132 , a MEC application rules and requirements management module 134 , and a MEC application lifecycle management module 136 . The MEC host 102 also includes MEC hardware 123 , such as network interfaces (e.g. network interface cards or NICs) 125 A, . . . , 125 N, one or more CPUs 127 , and memory 129 . Additional description of the MEC related

entities

102 , 104 , 106 , and 108 are provided hereinbelow in connection with FIG. 4 A and FIG. 4 B .

In some aspects, the MEC apps 116 A, . . . , 116 N can each provide an NFV instance configured to process network connections associated with a specific network traffic type (e.g., 2G, 3G, 4G, 5G or another network traffic type) associated with a UE quality of service (QoS) flow for a network slice instance. In this regard, the terms “MEC app” and “NFV” (or “MEC NFV”) are used interchangeably. Additionally, the term “NFV” and “NFV instance” are used interchangeably. The MEC platform 118 can further include one or more schedulers 120 A, . . . , 120 N (collectively, a scheduler 120 ). Each of the schedulers 120 A, . . . , 120 N may comprise suitable circuitry, logic, interfaces, and/or code and is configured to manage instantiation of NFVs (e.g., as MEC apps) 116 A, . . . , 116 N (collectively, an NFV 116 ). More specifically, a scheduler 120 can select a CPU (e.g., one of the CPUs 127 ) and/or other network resources for executing/instantiating the NFV 116 . Additionally, since each of the NFVs 116 A, . . . , 116 N is associated with processing a different network traffic type, the scheduler 120 can further select a NIC (e.g., from the available NICs 125 A, . . . , 125 N) for use by the NFV 116 . Each of the schedulers 120 A, . . . , 120 N can have a different type of SLA and QoS requirements, based on the network traffic type handled by the associated NFV. For example, each traffic type (e.g., 2G, 3G, 4G, 5G, or any other type of wireless connection to the MEC host) has an associated class of service (CloS) (e.g., 2G_low, 2G_mid, 2G_high, etc.) which can be preconfigured in the MEC host, defining CloS-specific resource requirements (i.e., I/O, memory, processing power, etc.) for different loads of that particular traffic type.

FIG. 1 A further illustrates the MEC host 104 including MEC hardware 133 , a MEC NFV- SCF 131 , and schedulers 128 A, . . . , 128 N, which can have the same functionality as the MEC hardware 123 , the MEC NFV- SCF 121 , and the schedulers 120 A, . . . , 120 N described in connection with MEC host 102 . Even though the MEC NFV- SCF 121 is illustrated as being implemented within the MEC platform 118 , the present disclosure is not limited in this regard and one or more components of the MEC NFV- SCF 121 can be implemented within other modules of the MEC host 102 (such as the MEC data plane 122 ), a network function virtualization infrastructure, a network function virtualization orchestrator (e.g., NFVO 160 ), the MEC orchestrator 108 , the MEC platform manager 106 , or another entity within the architecture 100 A or as a stand-alone node.

In some aspects, the MEC architecture 100 A (or any of the MEC architectures discussed herein) can be configured to provide functionalities per the ETSI GS MEC-003 specification, the ETSI GR MEC-024 specification, and/or the ETSI GR MEC-017 specification.

FIG. 1 B is a block diagram 100 B showing an overview of a configuration for edge computing, which includes a layer of processing referenced in many of the current examples as an “edge cloud”. This network topology, which may include several conventional networking layers (including those not shown herein), may be extended through the use of E2E multi-slice support for configuring network resources associated with network slice instances (NSIs) within MEC-enabled 5G communication systems, to optimize the instantiation of MEC apps and virtualized resources associated with the NSI.

As shown, the edge cloud 110 B is co-located at an edge location, such as the base station 140 B, a local processing hub 150 B, or a central office 120 B, and thus may include multiple entities, devices, and equipment instances. The edge cloud 110 B is located much closer to the endpoint (consumer and producer) data sources 160 B (e.g., autonomous vehicles 161 B, user equipment 162 B, business, and industrial equipment 163 B, video capture devices 164 B, drones 165 B, smart cities and building devices 166 B, sensors and IoT devices 167 B, etc.) than the cloud data center 130 B. Compute, memory, and storage resources which are offered at the edges in the edge cloud 110 B are critical to providing ultra-low latency response times for services and functions used by the endpoint data sources 160 B as well as reduce network backhaul traffic from the edge cloud 110 B toward cloud data center 130 thus improving energy consumption and overall network usages among other benefits.

Compute, memory, and storage are scarce resources, and generally, decrease depending on the edge location (e.g., fewer processing resources being available at consumer endpoint devices than at a base station or a central office). However, the closer that the edge location is to the endpoint (e.g., UEs), the more that space and power are constrained. Thus, edge computing, as a general design principle, attempts to minimize the number of resources needed for network services, through the distribution of more resources which are located closer both geographically and in-network access time.

The following describes aspects of an edge cloud architecture that covers multiple potential deployments and addresses restrictions that some network operators or service providers may have in their infrastructures. These include variation of configurations based on the edge location (because edges at a base station level, for instance, may have more constrained performance); configurations based on the type of compute, memory, storage, fabric, acceleration, or like resources available to edge locations, tiers of locations, or groups of locations; the service, security, and management and orchestration capabilities; and related objectives to achieve usability and performance of end services.

Edge computing is a developing paradigm where computing is performed at or closer to the “edge” of a network, typically through the use of a compute platform implemented at base stations, gateways, network routers, or other devices which are much closer to endpoint devices producing and consuming the data. For example, edge gateway servers may be equipped with pools of memory and storage resources to perform computation in real-time for low latency use-cases (e.g., autonomous driving or video surveillance) for connected client devices. Or as an example, base stations may be augmented with compute and acceleration resources to directly process service workloads for the connected user equipment, without further communicating data via backhaul networks. Or as another example, central office network management hardware may be replaced with compute hardware that performs virtualized network functions and offers compute resources for the execution of services and consumer functions for connected devices. These and other scenarios may involve the use of platform resource management, as provided in the discussion below.

In contrast to the network architecture of FIG. 1 A , traditional endpoint (e.g., UE, vehicle-to-vehicle (V2V), vehicle-to-everything (V2X), etc.) applications are reliant on local device or remote cloud data storage and processing to exchange and coordinate information. A cloud data arrangement allows for long-term data collection and storage but is not optimal for highly time-varying data, such as a collision, traffic light change, etc. and may fail in attempting to meet latency challenges.

Depending on the real-time requirements in a communications context, a hierarchical structure of data processing and storage nodes may be defined in an edge computing deployment. For example, such a deployment may include local ultra-low-latency processing, regional storage, and processing as well as remote cloud data-center based storage and processing. Key performance indicators (KPIs) may be used to identify where sensor data is best transferred and where it is processed or stored. This typically depends on the ISO layer dependency of the data. For example, a lower layer (PHY, MAC, routing, etc.) data typically changes quickly and is better handled locally to meet latency requirements. Higher layer data such as Application-Layer data is typically less time-critical and may be stored and processed in a remote cloud data-center.

FIG. 2 A illustrates an example Cellular Internet-of-Things (CIoT) network architecture with a MEC host using a MEC QoS manager, according to an example. Referring to FIG. 2 A , the CIoT architecture 200 A can include the UE 202 and the RAN 204 coupled to a plurality of core network entities. In some aspects, the UE 202 can be a machine-type communication (MTC) UE. The CIoT network architecture 200 A can further include a mobile services switching center (MSC) 206 , MME 208 , a serving GPRS support node (SGSN) 210, a S- GW 212 , an IP-Short-Message-Gateway (IP-SM-GW) 214 , a Short Message Service-Service Center (SMS-SC)/gateway mobile service center (GMSC)/Interworking MSC (IWMSC) 216 , MTC interworking function (MTC-IWF) 222 , a Service Capability Exposure Function (SCEF) 220 , a gateway GPRS support node (GGSN)/Packet-GW (P-GW) 218 , a charging data function (CDF)/charging gateway function (CGF) 224 , a home subscriber server (HSS)/a home location register (HLR) 226 , short message entities (SME) 228 , MTC authorization, authentication, and accounting (MTC AAA) server 230 , a service capability server (SCS) 232 , and application servers (AS) 234 and 236 . In some aspects, the SCEF 220 can be configured to securely expose services and capabilities provided by various 3GPP network interfaces. The SCEF 220 can also provide means for the discovery of the exposed services and capabilities, as well as access to network capabilities through various network application programming interfaces (e.g., API interfaces

CLAIMS

Claims ( 20 )

What is claimed is:

1. A system configured to evaluate end-to-end (E2E) performance of network slicing operations within a Multi-access Edge Computing-enabled (MEC-enabled) Fifth Generation (5G) communication network, the system comprising:

memory; and

processing circuitry coupled to the memory, the processing circuitry configured to:

determine first latency information for a plurality of non-MEC communication links associated with data communications of a user equipment (UE) using a network slice instance (NSI) in a radio access network (RAN) of the MEC-enabled 5G communication network;

determine second latency information for a plurality of MEC communication links associated with the data communications of the UE using the NSI in a MEC system of the MEC-enabled 5G communication network;

determine a round-trip time (RTT) associated with the data communications of the UE based on the first latency information and the second latency information; and

reconfigure resources of the MEC-enabled 5G communication network used by the NSI based on the determined RTT.

2. The system of claim 1 , wherein the processing circuitry is further configured to:

determine the first latency information based on a first latency associated with the data communications of the UE on a radio link between the UE and a Node-B (NB) of the MEC-enabled 5G communication network.

3. The system of claim 2 , wherein the processing circuitry is further configured to:

determine the first latency information further based on a second latency associated with the data communications of the UE on a Third Generation Partnership Project (3GPP) N3 interface between the NB and one of a MEC data plane (DP) or a 3GPP User-Plane Function (UPF) of the MEC-enabled 5G communication network.

4. The system of claim 3 , wherein the processing circuitry is further configured to:

determine the first latency information further based on a third latency associated with the data communications of the UE on a 3GPP N6 interface between the MEC DP and a MEC application instantiated at a local data network (DN) accessible by the UE.

5. The system of claim 4 , wherein the processing circuitry is further configured to:

determine the second latency information based on a fourth latency associated with the data communications of the UE on a MEC Mp1 interface between the MEC application and a MEC platform of the MEC system.

6. The system of claim 5 , wherein the MEC platform is instantiated as a virtualized network function (VNF) at the local DN.

7. The system of claim 6 , wherein the MEC application is configured to accesses the MEC platform via a MEC application programming interface (API) of the MEC platform.

8. The system of claim 1 , wherein the processing circuitry is further configured to:

determine the second latency information further based on delay experienced by a MEC application when gathering data from a MEC platform of the MEC system.

9. At least one non-transitory machine-readable storage medium comprising instructions, wherein the instructions, when executed by a processing circuitry of a management node operable a Multi-Access Edge Computing (MEC)-enabled Fifth Generation (5G) communication network, cause the processing circuitry to perform operations that:

determine first latency information for a plurality of non-MEC communication links associated with data communications of a user equipment (UE) using a network slice instance (NSI) in a radio access network (RAN) of the MEC-enabled 5G communication network;

determine second latency information for a plurality of MEC communication links associated with the data communications of the UE using the NSI in a MEC system of the MEC-enabled 5G communication network;

determine a round-trip time (RTT) associated with the data communications of the UE based on the first latency information and the second latency information; and

reconfigure resources of the MEC-enabled 5G communication network used by the NSI based on the determined RTT.

10. The at least one non-transitory machine-readable storage medium of claim 9 , wherein the processing circuitry further performs operations to:

determine the first latency information based on a first latency associated with the data communications of the UE on a radio link between the UE and a Node-B (NB) of the MEC-enabled 5G communication network.

11. The at least one non-transitory machine-readable storage medium of claim 10 , wherein the processing circuitry further performs operations to:

determine the first latency information further based on a second latency associated with the data communications of the UE on a Third Generation Partnership Project (3GPP) N3 interface between the NB and one of a MEC data plane (DP) or a 3GPP User-Plane Function (UPF) of the MEC-enabled 5G communication network.

12. The at least one non-transitory machine-readable storage medium of claim 11 , wherein the processing circuitry further performs operations to:

determine the first latency information further based on a third latency associated with the data communications of the UE on a 3GPP N6 interface between the MEC DP and a MEC application instantiated at a local data network (DN) accessible by the UE.

13. The at least one non-transitory machine-readable storage medium of claim 12 , wherein the processing circuitry further performs operations to:

determine the second latency information based on a fourth latency associated with the data communications of the UE on a MEC Mp1 interface between the MEC application and a MEC platform of the MEC system.

14. The at least one non-transitory machine-readable storage medium of claim 13 , wherein the MEC platform is instantiated as a virtualized network function (VNF) at the local DN.

15. The at least one non-transitory machine-readable storage medium of claim 14 , wherein the MEC application is configured to accesses the MEC platform via a MEC application programming interface (API) of the MEC platform.

16. The at least one non-transitory machine-readable storage medium of claim 9 , wherein the processing circuitry further performs operations to:

determine the second latency information further based on delay experienced by a MEC application when gathering data from a MEC platform of the MEC system.

17. An apparatus of a management node operable a Multi-Access Edge Computing (MEC)-enabled Fifth Generation (5G) communication network, the apparatus comprising:

communications circuitry to communicate with one or more computing devices in the MEC-enabled 5G communication network;

processing circuitry; and

a memory device including instructions embodied thereon, wherein the instructions, which when executed by the processing circuitry, configure the processing circuitry to perform operations to:

determine first latency information for a plurality of non-MEC communication links associated with data communications of a user equipment (UE) using a network slice instance (NSI) in a radio access network (RAN) of the MEC-enabled 5G communication network;

determine second latency information for a plurality of MEC communication links associated with the data communications of the UE using the NSI in a MEC system of the MEC-enabled 5G communication network;

determine a round-trip time (RTT) associated with the data communications of the UE based on the first latency information and the second latency information; and

reconfigure resources of the MEC-enabled 5G communication network used by the NSI based on the determined RTT and using the communications circuitry.

18. The apparatus of claim 17 , wherein the processing circuitry further performs operations to:

determine the first latency information based on a first latency associated with the data communications of the UE on a radio link between the UE and a Node-B (NB) of the MEC-enabled 5G communication network.

19. The apparatus of claim 18 , wherein the processing circuitry further performs operations to:

determine the first latency information further based on a second latency associated with the data communications of the UE on a Third Generation Partnership Project (3GPP) N3 interface between the NB and one of a MEC data plane (DP) or a 3GPP User-Plane Function (UPF) of the MEC-enabled 5G communication network.

20. The apparatus of claim 19 , wherein the processing circuitry further performs operations to:

determine the first latency information further based on a third latency associated with the data communications of the UE on a 3GPP N6 interface between the MEC DP and a MEC application instantiated at a local data network (DN) accessible by the UE.

US18/201,321

2019-03-11

2023-05-24

Multi-slice support for MEC-enabled 5G deployments

Active

US12047986B2

( en )

Priority Applications (1)

Application Number

Priority Date

Filing Date

Title

US18/201,321

US12047986B2

( en )

2019-03-11

2023-05-24

Multi-slice support for MEC-enabled 5G deployments

Applications Claiming Priority (4)

Application Number

Priority Date

Filing Date

Title

US201962816616P

2019-03-11

2019-03-11

PCT/US2020/021914

WO2020185794A1

( en )

2019-03-11

2020-03-10

Multi-slice support for mec-enabled 5g deployments

US202117430282A

2021-08-11

2021-08-11

US18/201,321

US12047986B2

( en )

2019-03-11

2023-05-24

Multi-slice support for MEC-enabled 5G deployments

Related Parent Applications (2)

Application Number

Title

Priority Date

Filing Date

PCT/US2020/021914

Continuation

WO2020185794A1

( en )

2019-03-11

2020-03-10

Multi-slice support for mec-enabled 5g deployments

US17/430,282

Continuation

US11700628B2

( en )

2019-03-11

2020-03-10

Multi-slice support for MEC-enabled 5G deployments

Publications (2)

Publication Number

Publication Date

US20230403731A1

US20230403731A1 ( en )

2023-12-14

US12047986B2

true

US12047986B2 ( en )

2024-07-23

Family

ID=72427628

Family Applications (2)

Application Number

Title

Priority Date

Filing Date

US17/430,282

Active

2040-06-13

US11700628B2

( en )

2019-03-11

2020-03-10

Multi-slice support for MEC-enabled 5G deployments

US18/201,321

Active

US12047986B2

( en )

2019-03-11

2023-05-24

Multi-slice support for MEC-enabled 5G deployments

Family Applications Before (1)

Application Number

Title

Priority Date

Filing Date

US17/430,282

Active

2040-06-13

US11700628B2

( en )

2019-03-11

2020-03-10

Multi-slice support for MEC-enabled 5G deployments

Country Status (3)

Country

Link

US

( 2 )

US11700628B2

( en )

DE

( 1 )

DE112020001183T5

( en )

WO

( 1 )

WO2020185794A1

( en )

Cited By (2)

* Cited by examiner, † Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US20230117465A1

( en )

*

2020-07-28

2023-04-20

Lg Electronics Inc.

Device using local server for v2x service

US20230336439A1

( en )

*

2022-04-15

2023-10-19

Dish Wireless L.L.C.

Private network connections for ran distributed units

Families Citing this family (51)

* Cited by examiner, † Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

WO2020074368A1

( en )

*

2018-10-08

2020-04-16

Telefonaktiebolaget Lm Ericsson (Publ)

Isolated e-utran operations for public safety (iops) awareness with multimedia broadcast multicast services (mbms)

US12028754B2

( en )

*

2019-01-31

2024-07-02

Nokia Technologies Oy

Method, apparatus and computer program product for management of mobile entities

US11700628B2

( en )

2019-03-11

2023-07-11

Intel Corporation

Multi-slice support for MEC-enabled 5G deployments

US11838931B2

( en )

*

2019-10-03

2023-12-05

Qualcomm Incorporated

Feedback of remaining delay budget

US20210219190A1

( en )

*

2020-01-10

2021-07-15

Parallel Wireless, Inc.

Fine-Granularity RAN Slicing Control

US11553502B2

( en )

*

2020-02-28

2023-01-10

At&T Intellectual Property I, L.P.

Recalibrating resource profiles for network slices in a 5G or other next generation wireless network

US11588751B2

( en )

2020-03-24

2023-02-21

Apple Inc.

Combined network and computation slicing for latency critical edge computing applications

US11284297B2

( en )

*

2020-04-06

2022-03-22

Cisco Technology, Inc.

Secure creation of application containers for fifth generation cellular network slices

CN116155797A

( en )

*

2020-05-13

2023-05-23

华为技术有限公司

A protocol message processing method, network equipment and computer storage medium

US11663524B2

( en )

*

2020-07-29

2023-05-30

EMC IP Holding Company LLC

Services using AI/ML to select virtual network functions and vendors for supplying the virtual network functions

WO2022038397A1

( en )

*

2020-08-19

2022-02-24

Telefonaktiebolaget Lm Ericsson (Publ)

Generating a machine learning model

US11516634B2

( en )

*

2020-09-29

2022-11-29

Verizon Patent And Licensing Inc.

Methods and system for robust service architecture for vehicle-to-everything communications

CN112203290B

( en )

*

2020-09-30

2022-07-22

中国联合网络通信集团有限公司

MEC node deployment position determining method and MEC node deployment device

US11812518B2

( en )

*

2020-11-17

2023-11-07

Microsoft Technology Licensing, Llc

Virtualized radio access network (vRAN) decoding as a service

CN114567826A

( en )

*

2020-11-27

2022-05-31

中兴通讯股份有限公司

Network slice management method, controller and computer readable storage medium

US20220225174A1

( en )

*

2021-01-08

2022-07-14

Motojeannie, Inc.

Experience-driven network (edn)

WO2022160140A1

( en )

2021-01-27

2022-08-04

Zte Corporation

A method for deployment multi-access edge computing application

US11743062B2

( en )

*

2021-03-05

2023-08-29

Verizon Patent And Licensing Inc.

Method and system for multi-operator anchor service

CN115250482B

( en )

*

2021-04-25

2025-07-25

上海瑄衡科技有限公司

5G section private network suitable for operating room wireless digital signal transmission

TWI765677B

( en )

*

2021-04-27

2022-05-21

啟碁科技股份有限公司

Ultra-reliable and low latency communications local breakout method and system for next generation radio access network

US11743125B2

( en )

*

2021-05-12

2023-08-29

DISH Wireless L.L.C

Cellular network cloud application controlled slice management

CN113271598B

( en )

*

2021-05-18

2022-09-27

全球能源互联网研究院有限公司

Edge safety protection architecture for electric power 5G network

CN115460623A

( en )

*

2021-06-08

2022-12-09

中兴通讯股份有限公司

Network slicing self-optimization method, base station and storage medium

CN115529144B

( en )

*

2021-06-24

2024-06-18

中移(成都)信息通信科技有限公司

Communication system, method, apparatus, first device, second device, and storage medium

US11411815B1

( en )

*

2021-06-28

2022-08-09

Dell Products L.P.

System for data center asset resource allocation

US11722928B1

( en )

2021-07-12

2023-08-08

T-Mobile Innovations Llc

Network slicing in a wireless communication network

US12041671B2

( en )

*

2021-09-21

2024-07-16

Verizon Patent And Licensing Inc.

Systems and methods for indicating the presence of a multi-access edge computing application

US11825309B2

( en )

*

2021-10-27

2023-11-21

Verizon Patent And Licensing Inc.

Provider proxy for controlling network slice access by user equipment

US11968274B2

( en )

*

2021-11-04

2024-04-23

Nokia Solutions And Networks Oy

Multi-access edge computing slicing

US11871318B2

( en )

*

2021-11-08

2024-01-09

Verizon Patent And Licensing Inc.

Systems and methods for tiered network slice design and management in a wireless network

CN114125779B

( en )

*

2021-11-26

2023-05-16

中国联合网络通信集团有限公司

Application program instantiation method, device, server and storage medium

US11838789B2

( en )

2021-12-17

2023-12-05

Microsoft Technology Licensing, Llc

End-to-end secure communications for privileged 5G network traffic

US12170663B2

( en )

*

2022-01-14

2024-12-17

Verizon Patent And Licensing Inc.

Systems and methods for providing secure access to a private multiaccess edge computing device via a multi-tenancy environment

CN116477258A

( en )

*

2022-01-14

2023-07-25

因特利格雷特总部有限责任公司

Mobile Object Handling Workstation with Advanced Networking Capabilities

WO2023167965A1

( en )

*

2022-03-02

2023-09-07

Dish Wireless L.L.C.

External service integration with cellular networks

US20230284323A1

( en )

*

2022-03-02

2023-09-07

Dish Wireless L.L.C.

External service integration with cellular networks

US12457549B2

( en )

*

2022-04-13

2025-10-28

T-Mobile Usa, Inc.

Serving gateway selection based on packet data network type

US11876683B2

( en )

*

2022-05-21

2024-01-16

Microsoft Technology Licensing, Llc

Network functions delivery system for mobile networks

US12389319B2

( en )

*

2022-06-30

2025-08-12

Hewlett Packard Enterprise Development Lp

Power management for virtualized RAN

CN117812599B

( en )

*

2022-09-26

2025-02-14

中国电信股份有限公司

Multi-access edge computing system and service processing method

CN115834430B

( en )

*

2022-11-16

2024-10-18

国网江苏省电力有限公司信息通信分公司

Time-sensitive network testing method, test bed, and storage medium

CN116056150B

( en )

*

2023-01-06

2026-03-27

中国联合网络通信集团有限公司

Resource adjustment method, apparatus and storage medium for QoS-based GBR services

CN120982194A

( en )

*

2023-03-31

2025-11-18

华为技术有限公司

Systems and methods for task management in communication networks

WO2024215228A1

( en )

*

2023-04-13

2024-10-17

Telefonaktiebolaget Lm Ericsson (Publ)

Service request handling

US12328232B2

( en )

2023-08-16

2025-06-10

Bank Of America Corporation

System for automated self-discoverable generation of networked computing application flows

CN117082009B

( en )

*

2023-10-16

2024-02-27

天翼安全科技有限公司

Cloud resource management method and management system based on software-defined security

US20250184796A1

( en )

*

2023-11-30

2025-06-05

Samsung Electronics Co., Ltd.

Apparatus and method for radio access network node optimisation in a wireless communication system

US20250220502A1

( en )

*

2023-12-29

2025-07-03

Verizon Patent And Licensing Inc.

Systems and methods to support event-based demand

EP4694276A1

( en )

*

2024-08-09

2026-02-11

Vodafone Group Services Limited

Network slice configuration

US20260089062A1

( en )

*

2024-09-26

2026-03-26

T-Mobile Usa, Inc.

Terminal-triggered dynamic slice modification

CN119835652A

( en )

*

2025-01-07

2025-04-15

电子科技大学长三角研究院(湖州)

Lightweight slice resource allocation method and system for unmanned aerial vehicle auxiliary network

Citations (12)

* Cited by examiner, † Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

WO2018045990A1

( en )

2016-09-09

2018-03-15

Huawei Technologies Co., Ltd.

Method and apparatus for network slicing

US20180123961A1

( en )

2016-10-31

2018-05-03

Huawei Technologies Co., Ltd.

System and method for policy configuration of control plane functions by management plane functions

US20180317134A1

( en )

2017-04-28

2018-11-01

Huawei Technologies Co., Ltd.

Nssmf nsmf interaction connecting virtual 5g networks and subnets

US20190140933A1

( en )

*

2018-12-28

2019-05-09

Francesc Guim Bernat

Dynamic quality of service in edge cloud architectures

US20190223055A1

( en )

2018-01-12

2019-07-18

Huawei Technologies Co., Ltd.

Network slice provisioning and operation

EP3609161A1

( en )

2017-05-22

2020-02-12

Huawei Technologies Co., Ltd.

Network slice creating method and apparatus, and communication system

US20200052991A1

( en )

2018-08-09

2020-02-13

At&T Intellectual Property I, L.P.

Mobility network slice selection

WO2020185794A1

( en )

2019-03-11

2020-09-17

Intel Corporation

Multi-slice support for mec-enabled 5g deployments

US11064057B2

( en )

2017-11-30

2021-07-13

Intel Corporation

Multi-access edge computing (MEC) translation of radio access technology messages

US11140529B2

( en )

*

2017-11-27

2021-10-05

Intel Corporation

Multi-access edge computing (MEC) based multi operator support for C-V2X systems

US20230074288A1

( en )

*

2019-05-07

2023-03-09

Intel Corporation

V2x services for providing journey-specific qos predictions

US20230164241A1

( en )

*

2020-05-22

2023-05-25

Intel Corporation

Federated mec framework for automotive services

2020

2020-03-10

US

US17/430,282

patent/US11700628B2/en

active

Active

2020-03-10

DE

DE112020001183.6T

patent/DE112020001183T5/en

active

Pending

2020-03-10

WO

PCT/US2020/021914

patent/WO2020185794A1/en

not_active

Ceased

2023

2023-05-24

US

US18/201,321

patent/US12047986B2/en

active

Active

Patent Citations (16)

* Cited by examiner, † Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US10411964B2

( en )

2016-09-09

2019-09-10

Huawei Technologies Co., Ltd.

Method and apparatus for network slicing

WO2018045990A1

( en )

2016-09-09

2018-03-15

Huawei Technologies Co., Ltd.

Method and apparatus for network slicing

US20180123961A1

( en )

2016-10-31

2018-05-03

Huawei Technologies Co., Ltd.

System and method for policy configuration of control plane functions by management plane functions

US20180317134A1

( en )

2017-04-28

2018-11-01

Huawei Technologies Co., Ltd.

Nssmf nsmf interaction connecting virtual 5g networks and subnets

EP3609161A1

( en )

2017-05-22

2020-02-12

Huawei Technologies Co., Ltd.

Network slice creating method and apparatus, and communication system

US11140529B2

( en )

*

2017-11-27

2021-10-05

Intel Corporation

Multi-access edge computing (MEC) based multi operator support for C-V2X systems

US11064057B2

( en )

2017-11-30

2021-07-13

Intel Corporation

Multi-access edge computing (MEC) translation of radio access technology messages

US20190223055A1

( en )

2018-01-12

2019-07-18

Huawei Technologies Co., Ltd.

Network slice provisioning and operation

US20200052991A1

( en )

2018-08-09

2020-02-13

At&T Intellectual Property I, L.P.

Mobility network slice selection

US20190140933A1

( en )

*

2018-12-28

2019-05-09

Francesc Guim Bernat

Dynamic quality of service in edge cloud architectures

WO2020185794A1

( en )

2019-03-11

2020-09-17

Intel Corporation

Multi-slice support for mec-enabled 5g deployments

US20220086864A1

( en )

2019-03-11

2022-03-17

Intel Corporation

Multi-slice support for mec-enabled 5g deployments

DE112020001183T5

( en )

2019-03-11

2022-03-17

Intel Corporation

MULTI-SLICE SUPPORT FOR MEC-READY 5G DEPLOYMENTS

US11700628B2

( en )

2019-03-11

2023-07-11

Intel Corporation

Multi-slice support for MEC-enabled 5G deployments

US20230074288A1

( en )

*

2019-05-07

2023-03-09

Intel Corporation

V2x services for providing journey-specific qos predictions

US20230164241A1

( en )

*

2020-05-22

2023-05-25

Intel Corporation

Federated mec framework for automotive services

Non-Patent Citations (9)

* Cited by examiner, † Cited by third party

Title

" 3GPP; TSG CT; 5G System; Network Slice Selection Services; Stage 3 (Release 15) ", 3GPP TS 29.531 V15.2.0, section 6.1.3.2, (Dec. 19, 2018).

" International Application Serial No. PCT US2020 021914, International Preliminary Report on Patentability mailed Sep. 23, 2021 ", 6 pgs.

" International Application Serial No. PCT US2020 021914, International Search Report mailed Jul. 1, 2020 ", 3 pgs.

" International Application Serial No. PCT US2020 021914, Written Opinion mailed Jul. 1, 2020 ", 4 pgs.

" U.S. Appl. No. 17 430,282 Preliminary Amendment filed Aug. 11, 2021 ", 10 pgs.

" U.S. Appl. No. 17 430,282, Notice of Allowance mailed Mar. 1, 2023 ", 9 pgs.

Huawei, " Solution 8 Updates for QoS monitoring solution based on time synchronization ", S2-1901195, 3GPP TSG-SA WG2 Meeting #130, (Mar. 4, 2019).

Intel, " pCR 28.861 add use case for automatic NSI creation ", S5˜192426, 3GPP TSG SA WG5 (Telecom Management) Meeting #124, section 5, (Mar. 1, 2019).

Nokia, " Add availability in service profile of network slice resource model ", S5-192222, 3GPP TSG-SA5 Meeting #124, section 6.3.3, (Feb. 15, 2019).

Cited By (3)

* Cited by examiner, † Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US20230117465A1

( en )

*

2020-07-28

2023-04-20

Lg Electronics Inc.

Device using local server for v2x service

US12375892B2

( en )

*

2020-07-28

2025-07-29

Lg Electronics Inc.

Device using local server for V2X service

US20230336439A1

( en )

*

2022-04-15

2023-10-19

Dish Wireless L.L.C.

Private network connections for ran distributed units

Also Published As

Publication number

Publication date

US20220086864A1

( en )

2022-03-17

US11700628B2

( en )

2023-07-11

US20230403731A1

( en )

2023-12-14

WO2020185794A1

( en )

2020-09-17

DE112020001183T5

( en )

2022-03-17

Similar Documents

Publication

Publication Date

Title

US20230403731A1

( en )

2023-12-14

Multi-slice support for mec-enabled 5g deployments

US12120012B2

( en )

2024-10-15

Dynamic quality of service in edge cloud architectures

US11943280B2

( en )

2024-03-26

5G network edge and core service dimensioning

US11650851B2

( en )

2023-05-16

Edge server CPU with dynamic deterministic scaling

US11711678B2

( en )

2023-07-25

Multi-access edge computing (MEC) based multi-operator support for C-V2X systems

US11711267B2

( en )

2023-07-25

5G network slicing with distributed ledger traceability and resource utilization inferencing

US11736942B2

( en )

2023-08-22

Multi-domain trust establishment in edge cloud architectures

US12132790B2

( en )

2024-10-29

Quality of service (QoS) management in edge computing environments

US11540355B2

( en )

2022-12-27

MEC-based distributed computing environment with multiple edge hosts and user devices

US12425914B2

( en )

2025-09-23

Technologies for control and management of multiple traffic steering services

US20220353732A1

( en )

2022-11-03

Edge computing technologies for transport layer congestion control and point-of-presence optimizations based on extended inadvance quality of service notifications

US20230353455A1

( en )

2023-11-02

Multi-access management service frameworks for cloud and edge networks

KR20220092366A

( en )

2022-07-01

Interoperable framework for secure dual mode edge application programming interface consumption in hybrid edge computing platforms

US20190138934A1

( en )

2019-05-09

Technologies for distributing gradient descent computation in a heterogeneous multi-access edge computing (mec) networks

Legal Events

Date

Code

Title

Description

2023-05-24

<td

Related documents

• Generating augmented reality experiences utilizing physical objects to … — Meta Platforms Technologies, Llc (US20260037214A1)#653960
• Virtual reality system using multiple force arrays for a solver — DeepMotion, Inc. (US10657696B2)#653961
• Tracking position of device inside-out for virtual reality interactivity — Sony Interactive Entertainment America Llc (US10535153B2)#653962
• Augmented reality system with spatialized audio tied to user manipulated … — Magic Leap, Inc. (US11231770B2)#653963
• Big data-based autonomous flight drone system and autonomous flight method … — Rgblab Co., Ltd. (US20210390867A1)#653964