A policy orchestration framework that supports end-to-end (E2E) multi-access network policy architectures using top-to-bottom policy orchestration

Abstract

To provide a policy orchestration framework to support end-to-end (E2E) policy architecture with top-to-bottom policy orchestration, and a method of using the same.SOLUTION: A method includes: providing, in a mobile network, a frontend network having a first plurality of layers supporting network services; providing a backend network having a second plurality of layers supporting network services; providing an end-to-end view between the frontend network and the backend network; and coordinating end-to-end policy decisions for the first plurality of layers of the frontend and for the second plurality of layers of the backend, based on the end-to-end view, to provide policy orchestration.SELECTED DRAWING: Figure 10

Description

[Technical Field]

[0001] This description relates to a policy orchestration framework and method of using same that uses top-to-bottom policy orchestration to support an end-to-end (E2E) multi-access network policy architecture. [Background technology]

[0002] Mobile networks are transitioning from connectivity-centric networks to application-centric networks. There are specific terms in the market that relate to new or next-generation applications, such as the metaverse. These new applications will impact the network by making it more complex in terms of connectivity and will depend on new application requirements.

[0003] In mobile networks, network operator policies, such as control policies, are defined. Current methods of policy implementation address policy management for specific scenarios, but are limited to those specific network architectures.

[0004] Current policy management potentially does not provide end-to-end visibility of network capabilities, nor does it use top-to-bottom network-specific capability visibility to apply policies to specific services. Summary of the Invention

[0005] In at least embodiments, a method for providing a policy orchestration framework that supports an end-to-end (E2E) policy architecture using top-to-bottom policy orchestration includes providing a front-end network having a first plurality of layers that support network services; providing a back-end network having a second plurality of layers that support network services; and providing policy orchestration by providing an end-to-end view between the front-end network and the back-end network and by coordinating end-to-end policy decisions for the first plurality of layers of the front-end network and the second plurality of layers of the back-end network.

[0006] In at least one embodiment, the policy orchestrator includes a memory storing computer-readable instructions and a processor coupled to the memory, the processor configured to execute the computer-readable instructions to provide an end-to-end view between a network front-end having a first plurality of layers and a network back-end having a second plurality of layers, and to coordinate end-to-end policy decisions for the first plurality of layers of the network front-end and the second plurality of layers of the network back-end based on the end-to-end view.

[0007] In at least one embodiment, a non-transitory computer-readable medium having computer-readable instructions stored therein, when executed by a processor, causes the processor to perform operations including: providing a front-end network having a first plurality of layers supporting a network service; providing a back-end network having a second plurality of layers supporting the network service; and providing policy orchestration by providing an end-to-end view between the front-end network and the back-end network and by coordinating end-to-end policy decisions for the first plurality of layers of the front-end network and the second plurality of layers of the back-end network based on the end-to-end view. [Brief explanation of the drawings]

[0008] Aspects of the present disclosure are best understood from the following detailed description when read in conjunction with the accompanying drawings. It should be noted that, according to standard industry practice, various features have not been drawn to scale. In fact, the dimensions of various features may be increased or decreased for clarity of illustration.

[0009] [Figure 1] 1 illustrates the 3GPP® architecture for Policy and Charging Control (PCC). [Figure 2] It shows a horizontal approach to policy decisions through the 3GPP architecture. [Figure 3] 1 illustrates a top-to-bottom approach to policy orchestration, according to at least one embodiment. [Figure 4] 1 is a policy reference architecture that provides a hierarchical view of architecture levels, according to at least one embodiment. [Figure 5] FIG. 1 illustrates a system-level diagram of a policy orchestrator employed in a multi-access edge computing (MEC) platform, according to at least one embodiment. [Figure 6] FIG. 1 illustrates a detailed system-level diagram of a multi-access edge computing (MEC) system, according to at least one embodiment. [Figure 7] FIG. 1 is a diagram of messages supported by a policy orchestrator, according to at least one embodiment. [Figure 8] 1 illustrates the interaction of pull and push messages according to at least one embodiment. [Figure 9] 1 illustrates metadata for pull and push messages according to at least one embodiment. [Figure 10] 1 is a flowchart of a method for providing a policy orchestration framework for supporting an end-to-end (E2E) policy architecture using top-to-bottom policy orchestration, according to at least one embodiment. [Figure 11] FIG. 1 is a high-level functional block diagram of a processor-based system according to at least one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0010] The embodiments described herein illustrate examples of implementing different features of the provided subject matter. To simplify the disclosure, certain examples of components, values, operations, materials, arrangements, and the like are described below. Of course, these are merely examples and are not intended to be limiting. Other components, values, operations, materials, arrangements, and the like are contemplated. For example, the formation of a first feature on or above a second feature in the following description includes embodiments in which the first and second features are formed in direct contact with each other, and also includes embodiments in which an additional feature is formed between the first and second features such that the first and second features are not in direct contact with each other. Additionally, the disclosure repeats reference numbers and / or letters in various examples. This repetition is for the purposes of brevity and clarity and does not in itself dictate a relationship between the various embodiments and / or configurations described.

[0011] Additionally, spatially relative terms such as "beneath," "below," "lower," "above," and "upper" are used herein for ease of description to describe the relationship of one element or feature to another element(s) or feature(s), as shown in the figures. The spatially relative terms are intended to encompass different orientations of the device during use or operation in addition to the orientation shown in the figures. The device may be otherwise oriented (rotated 90 degrees or at other orientations) and the spatially relative descriptors used herein interpreted accordingly.

[0012] Terms such as “user equipment,” “mobile station,” “mobile,” “mobile device,” “subscriber station,” “subscriber equipment,” “access terminal,” “terminal,” “handset,” and similar terms refer to wireless devices utilized by subscribers or users of wireless communication services to receive or convey data, control, voice, video, sound, games, data streaming, or signaling streaming. The foregoing terms are used interchangeably in this specification and related drawings. Terms such as “access point,” “base station,” “Node B,” “evolved Node B (eNode B),” next generation Node B (gNB), enhanced gNB (en-gNB), Home Node B (HNB), “Home Access Point (HAP),” and the like refer to components or devices of a wireless network that transmit and receive data, control, voice, video, sound, games, data streaming, or signaling streaming from a UE.

[0013] In at least one embodiment, a method for providing a policy orchestration framework supporting an end-to-end (E2E) policy architecture using top-to-bottom policy orchestration includes providing a front-end network having a first plurality of layers supporting network services, providing a back-end network having a second plurality of layers supporting the network services, and providing policy orchestration by providing an end-to-end view between the front-end network and the back-end network and by coordinating end-to-end policy decisions for the first plurality of layers of the front-end network and the second plurality of layers of the back-end network. Intercommunication between the first plurality of layers and the second plurality of layers uses push and pull messages between the first plurality of layers and the second plurality of layers. A policy orchestrator provides metadata for the push and pull messages, including metadata about hierarchical level information, routing component information, and policy management node identifiers. The metadata for policy enforcement includes hierarchical level information identifying the source (Src) level and destination level, routing component information including the source (Src) realm and destination realm, and policy management node identifier information including the source (Src) level policy node and destination policy node. Other metadata includes enforcement nodes, service level requirements, resource status, etc. The metadata for resource evaluation includes hierarchical level information identifying the source (Src) level and destination level, routing component information including the source (Src) realm and destination realm, and policy management node identifier information including the source (Src) level enforcement node and destination attempt node. Other metadata includes policy nodes, service level requirements, resource status, etc.

[0014] Embodiments described herein provide a method that provides one or more advantages. For example, a policy orchestrator according to at least one embodiment provides a top-to-bottom policy architecture for multi-access networks. The policy orchestrator according to at least one embodiment provides a framework for coordination of various policy-specific network entities. The policy orchestrator provides end-to-end visibility of network capabilities and applies policies to specific services. The policy orchestrator according to at least one embodiment enables a network to apply and manage policies for various grades and levels of service for better service delivery and network performance.

[0015] FIG. 1 shows the 3GPP architecture for Policy and Charging Control (PCC) 100.

[0016] FIG. 1 shows different network functions, including a Policy and Charging Rules Function (PCRF) 110 and a Policy and Charging Enforcement Function (PCEF) 112. The PCRF 110 provides a centralized policy decision point that deploys business policies and charging rules to allocate broadband network resources and manage flow-based charging for subscribers and services. The PCRF 110 pushes down the rules to the Policy and Charging Enforcement Function (PCEF) 112. The PCEF 112 provides user traffic processing and QoS at the gateway 114, provides service data flow detection, and applies rules received from the PCRF 110. The PCEF 112 optionally interacts with an Online Charging Function (OCF) 120 and an Offline Charging System (OFCS) 122 to retrieve policy and charging authorization for quota and credit control.

[0017] The OCS 120 is responsible for interacting with the PCEF 112 to perform real-time charging for services. The OCS 120 authorizes a subscriber's session subject to available credit in the account and decrements the account balance as services are consumed. If the subscriber's account balance is depleted, authorization is revoked and ongoing sessions may be terminated. The OFCS 122 collects charging information about network resource usage contemporaneously with its use. The Broadband PCEF (BPCEF) 130 interacts with the PCRF 110 and enables signaling of QoS control decisions.

[0018] The RAN Congestion Awareness Function (RCAF) 140 is an element that provides RAN User Plane Congestion Information (RUCI) to the PCRF 110, enabling the PCRF 110 to take the RAN user plane congestion status into account for policy decisions.

[0019] The Packet Flow Description Function (PFDF) 150 is a repository that stores Packet Flow Descriptions (PFDs), which can be managed, i.e., added, updated, or deleted, by the SCS / AS (which may be a third-party AS) via the Service Capability Exposure Function (SCEF) 160. The Traffic Steering Support Function (TSSF) 170 is a function that receives traffic steering control information from the PCRF 110 and ensures that the associated traffic steering policies are enforced. Traffic steering policies are configured locally in the TSSF 170 and may be used for the uplink, downlink, or uplink and downlink directions. To ensure that the traffic steering policy is enforced, the TSSF 170 performs the deployment-specific actions configured for that traffic steering policy.

[0020] The SCEF 160 securely exposes the services and capabilities offered by the 3GPP network interface. The Application Function (AF) 142 is a functional element that provides session-related information to the PCRF 110. The Traffic Detection Function (TDF) 180 enforces traffic policies in real time, based either on pre-configured rules or on rules dynamically determined by the Policy Control Rules Function (PCRF) 110. The User Data Repository (UDR) 144 stores aggregated user-related subscription data that is accessed by the PCRF.

[0021] The 3GPP architecture for Policy and Charging Control (PCC) 100 uses a horizontal approach to apply network policies: policy decisions are made in the back end of the network and sent to the front end for enforcement, with each node applying the policy according to its best effort and availability of resources.

[0022] FIG. 2 illustrates a horizontal approach to policy decisions 200 according to the 3GPP architecture.

[0023] In Figure 2, the gateway forwards policies to the front end of the network using a horizontal approach where application functions 210 provide requirements to policy control functions 220. Policy control functions 220 decide what type of policies to apply to the network. The policy parameters are sent to policy enforcement gateway 230. Policy enforcement gateway 230 follows specific procedures to provide the determined policy decision parameters to the front end of the network, regardless of whether it knows it has the resources to apply those policies.

[0024] The policy decision is made in a centralized way and applied within the very back-end of the network, and the decision is sent from the back-end to the front-end with respect to a particular scalar indicator at the time the decision is made, and the policy is applied at different levels of the network based on that scalar indicator, so that different levels of the network from the back-end to the front-end apply the policy based on how the resource level is being used at that time.

[0025] This horizontal approach does not provide complete end-to-end visibility of network resources. For example, decisions are made at the back end, and those quality decisions are provided to different levels of the network from the back end to the front end in some scalar indicator, and based on that scalar indicator, decisions are made at nodes in the network at different levels on how to apply policy decisions based on existing resources. Therefore, there is no complete end-to-end visibility of the network to make policy decisions for levels of the network.

[0026] FIG. 3 illustrates a top-to-bottom approach to policy orchestration 300, according to at least one embodiment.

[0027] In Figure 3, policy orchestrator 310 uses a hierarchical policy management architecture to deliver multiple levels of resources and services. Policy orchestrator 310 provides a framework for coordinating policy decisions at different functional levels. Policy orchestrator 310 provides a comprehensive and adaptive policy framework that provides top-to-bottom and bottom-to-top visibility of the network to configure and deliver application-centric networks and their respective services using a complete end-to-end view.

[0028] In accordance with at least one embodiment, a top-to-bottom approach to policy orchestration 300 is illustrated with three distinct layers: a policy orchestration layer 320, a policy control and management layer 330, and a policy enforcement layer 340. The policy orchestrator 310 coordinates policies top-to-bottom and end-to-end between the front-end and back-end. The front-end network is referred to as the Radio Access Network (RAN) 350. The back-end network is referred to as the core network 360. The RAN 350 provides the policy control and management layer 330 via a RAN Intelligent Controller (RIC) 332 and the policy enforcement layer 340 via a Radio Resource Management (RRM) 342. The core network 360 provides the policy control and management layer 330 via a policy control function (PCF) 334 and the policy enforcement layer 340 via a policy and charging enforcement function (PCEF) 344.

[0029] The RIC 332 performs resource management and coordination for the RAN 350. The RIC 332 manages and intelligently controls network node resources. The PCF 334 on the core network 360 performs resource management and coordination, manages and intelligently controls network node resources.

[0030] In the policy enforcement layer 340 on the RAN 350, the RRM 334 enforces the policy decisions specified in the policy control and management layer 330. The PCEF 344 on the core network 360 enforces the policy decisions specified in the policy control and management layer 330 of the core network 360.

[0031] The policy orchestrator 310 enhances visibility of resource capabilities in the RAN 350. Because the front-end provided by the RAN 350 and the back-end provided by the core network 360 are two separate entities, policies applied in the core network 360 are independent of policies applied in the RAN 350. The policy orchestrator 310, according to at least one embodiment, provides coordination between the policy control and management layer 330 and the policy enforcement layer 340 of the RAN 350 and between the policy control and management layer 330 and the policy enforcement layer 340 of the core network 360, such that policy decisions made are based on end-to-end visibility of resources in the network. The policy orchestrator 310 coordinates policies in the RAN 350 and the core network 360 top-to-bottom and end-to-end using push / pull messages 370 and 372, respectively.

[0032] FIG. 4 is a policy reference architecture 400 that provides a hierarchical view of architectural levels, according to at least one embodiment.

[0033] As shown in Figure 4, the vertical cross section of the system is layered at four different levels from a policy orchestration perspective: The policy orchestrator provides visibility into the network through application-level use cases 410, the network service end-to-end level 420, the network node or network function level 430, and the system / platform level 440.

[0034] Visibility into applications running on the network is provided. At the use case or application level 410, a policy orchestrator according to at least one embodiment provides visibility into the use case level 412, network slicing 414, applications 416, etc. For example, a particular access network requires connectivity to fiber to the home and Wi-Fi to the home.

[0035] At the network service end-to-end level 420, a policy orchestrator according to at least one embodiment provides visibility into network services 422, end-to-end bearers 424, etc. At the network node or network function level 430, a policy orchestrator according to at least one embodiment provides visibility into nodes 432, service differentiation 434, etc. For example, it provides visibility into different network nodes, such as the specific gateways or routers involved.

[0036] At the system / platform level 440, a policy orchestrator according to at least one embodiment provides visibility into the platform 442, infrastructure 444, resources 446, etc. For example, visibility into a computing platform is a particular router. The policy orchestrator applies policies at the level of the functions running to support applications.

[0037] FIG. 5 is a system-level diagram of a policy orchestrator employed in a multi-access edge computing (MEC) platform 500, according to at least one embodiment.

[0038] 5, MEC platform 500 provides a standardized, open environment for efficient and seamless integration of applications from vendors, service providers, and third parties across a multi-vendor computing platform at the edge of a mobile network. MEC platform 500 uses an MEC framework that includes three levels: a network level 510, an MEC host level 530, and an MEC system level 570. The location of policy orchestrator 572 within MEC system level management 574 at MEC system level 570 is shown in relation to its communication with policy control and management 532 within MEC host level management 534 and policy enforcement 540 within MEC platform 542.

[0039] The policy orchestrator 572 is provided by an MEC system level management entity 574. The MEC system level management entity 574 interfaces with external devices 576 and third-party applications 578. Thus, the policy orchestrator 572 is implemented at the MEC system level 570, where the policy orchestrator 572 provides a policy framework, analyzes applications, and implements appropriate services. The policy control and management 532 is implemented at the MEC host level 530 in the MEC host level management 534. The policy enforcement 540 is also implemented on the MEC platform 542 of the MEC host 544 at the MEC host level 530.

[0040] The policy orchestrator 572 assumes that the network is application-centric rather than connection-centric, as is the case in current networks. To support application-centric policies, the policy orchestrator 572 provides service-specific requirements from an end-to-end perspective of the network. Network resources are coordinated by the policy orchestrator 572 to support specific services for the specific requirements of the application. Policies are applied or implemented within existing platforms currently used in current networks. In the case of cloud platforms, for example, a concept called multi-access edge computing (MEC) is involved, and at the network level 510, network functions are applied to network elements such as routers, gateways, and firewalls. The network level 510 can include a 3GPP network 512, a local network 514, an external network 516, and the like.

[0041] The policy orchestrator 572 interacts with the policy control and management 532 functionality at the MEC host level 530, which interacts with the MEC platform 542, where the policy enforcement 540 functionality is provided. The policy enforcement 540 is implemented on the MEC platform 542 as part of the MEC host 544. MEC applications 550, such as MEC applications 552, 554, 556, and 558, are implemented on the MEC host 544 to implement network functions. A virtualization infrastructure 560, e.g., NFVI, is also implemented in the MEC host 544.

[0042] At a basic level, the policy orchestrator 572 provides network functions, as well as node / network-level resources and services for network functions, including physical network functions (PNFs), virtual network functions (VNFs), and cloud-native functions (CNFs). PNFs refer to hardware that provides specific networking functions. Virtual network functions (VNFs) are software applications that deliver network functions. VNFs are deployed as virtual machines (VMs) on proprietary hardware to provide digital transformation from legacy network appliance physical network functions (PNFs). VNFs are built on a virtualization infrastructure 560, such as NFVI, which includes a virtual infrastructure manager (VIM) for allocating resources such as compute, storage, and networking. The framework for managing the virtualization infrastructure 560 and provisioning new NFs occurs in the management, automation, and network orchestration (MANO) element defined by NFV. Cloud-native functions (CNF) use containers instead of VMs. Containers allow users to package software such as applications, functions, or microservices along with the files used to run the software while sharing access to the operating system and other server resources. CNFs facilitate the movement of the components they contain between environments (e.g., development, test, production) and between clouds while retaining their full functionality.

[0043] At the highest level, the policy orchestrator 572 can control use cases, applications, network slicing, and the like. The policy orchestrator 572 can be tailored to autonomous and isolated networks. The policy orchestrator 572 can also support dynamic network slicing, including internal slicing. The deployment and implementation of the policy orchestrator 572 can be configured to enhance the policy framework with top-to-bottom, end-to-end visibility of the network. For example, different levels of enforcement and policy decisions can be defined to provide increased visibility into resource and service requirements. The policy orchestrator 572 provides metadata about the intercommunications of various layers of policy nodes, supporting direct, transparent, and redirected communication between different nodes top-to-bottom and vice versa. The policy orchestrator 572 also provides standardized templates for communicating policy-specific representations at various levels (e.g., top-to-bottom) that are distributed end-to-end throughout the network.

[0044] FIG. 6 is a detailed system level diagram of a multi-access edge computing (MEC) system 600 according to at least one embodiment.

[0045] 6, at the MEC system level 610, a policy orchestrator 612 interacts with an operations support system 614 and a multi-access edge orchestrator 616. The policy orchestrator 612 also interacts with policy control and management 680 and policy enforcement 672 within the MEC platform 670.

[0046] The multi-access edge orchestrator 616 provides support for the MEC platform manager 690 and is not related to the policy orchestrator 612. The policy orchestrator 612 also interacts with policy control and management 680, which interacts with the platform manager 670 and also directly with policy enforcement 672 at the MEC host 660.

[0047] Device applications 620 are applications within devices (e.g., UEs, internet-connected laptops) that have the ability to interact with the MEC system 600 via a user application lifecycle management proxy. A Customer Facing Service (CFS) portal 622 allows third-party customers (e.g., commercial enterprises) to select and order a set of MEC applications that meet predetermined specifications and receive service level information from provisioned applications. A User Application Lifecycle Management (LCM) proxy 630 allows device applications to request the onboarding, instantiation, and termination of user applications, if supported.

[0048] At the MEC host level 640, MEC applications 642, 644, 646 run as virtual machines (VMs) on a virtualization infrastructure 650 provided by an MEC host 660 and interact with an MEC platform 670 to consume and provide MEC services. The virtualization infrastructure 650 includes a data plane 652, which enforces forwarding rules received by the MEC platform 670 and routes traffic between applications, services, and the network.

[0049] The MEC platform 670 supports MEC service authentication 674, service registry 675, traffic rules 676, and DNS configuration and conflict resolution 678. MEC applications 642, 644, 646 also interact with the MEC platform 670 to perform specific support procedures related to the application lifecycle, such as indicating availability and preparing for user state relocation. MEC applications 642, 644, 646 contain a specific number of rules and associated requirements, such as resources used, maximum latency, services, etc. These requirements are validated by the MEC system-level management 680, which assigns default values ​​to any missing requirements.

[0050] The multi-access edge orchestrator 616 maintains a global view of the MEC system 600 based on deployed MEC hosts 660, available resources, available MEC services, and topology. Other MEC hosts 662 with other MEC platforms 664 communicate with the MEC platform 670. The multi-access edge orchestrator 616 supports application package onboarding, including checking package integrity and authenticity, validating application rules and requirements and adjusting them to comply with operator policies, maintaining records of onboarded packages, and preparing virtualization infrastructure managers to process applications. The multi-access edge orchestrator 616 can select appropriate MEC hosts 660, 662 for application instantiation based on constraints such as latency, available resources, and available services, trigger application instantiation and termination, and trigger application relocation. The MEC host 660 can also interact with other MEC hosts 662 with their own MEC platforms 664.

[0051] The MEC platform manager 690 performs MEC application lifecycle management, including notifying the multi-access edge orchestrator of relevant application-related events, provides MEC platform element management functions 692 to the MEC platform 670, and provides MEC application rules and requirements management 694. The MEC application lifecycle management 696 is responsible for instantiating, terminating, and redeploying MEC applications 642, 644, and 646, as well as providing instructions regarding certain application-related events to the multi-access edge orchestrator 616. The MEC platform manager 690 also receives virtualization resource fault reports and performance measurements from the virtualization infrastructure manager 682 for further processing. The virtualization infrastructure manager 682 is used to allocate, manage, and publish virtualization (compute, storage, and networking) resources in the virtualization infrastructure and to prepare the virtualization infrastructure to run software images. Preparation includes configuring the infrastructure and receiving and storing software images. The virtualization infrastructure manager 682 collects and reports performance and fault information regarding virtualized resources.

[0052] The policy orchestrator 612 provides a policy framework, analyzes applications, and implements appropriate services. The policy orchestrator 612 interacts with the policy control and management 680 function, which interacts with policy enforcement 672 in the MEC platform 678. The policy orchestrator 612 provides service-specific requirements from an end-to-end perspective of the network. Network resources are coordinated by the policy orchestrator 612 to support specific services for the specific requirements of applications. Policies are applied or implemented within existing platforms currently used in current networks. The policy orchestrator 612 provides network functions, as well as node / network-level resources and services for network functions. The policy orchestrator 612 can control use cases, applications, network slicing, etc. The policy orchestrator 612 can be tailored to autonomous and isolated networks. The policy orchestrator 612 can also support dynamic network slicing, including internal slicing. The deployment and implementation of the policy orchestrator 612 may be configured to enhance the policy framework with top-to-bottom, end-to-end visibility of the network. For example, different levels of enforcement and policy decisions can be defined to provide increased visibility into resource and service requirements. The policy orchestrator 612 provides metadata about the intercommunications of various layers of policy nodes, supporting direct, transparent, and redirected communication between different nodes top-to-bottom and vice versa. The policy orchestrator 612 also provides standardized templates for communicating policy-specific representations at various levels (e.g., top-to-bottom) distributed end-to-end throughout the network.

[0053] FIG. 7 is a diagram of messages 700 supported by a policy orchestrator, according to at least one embodiment.

[0054] In Figure 7, two sets of messages are supported by policy orchestrator 750: push messages 710 and pull messages 730. Policy management layers 760 include layer 1 762, layer 2 764, layer 3 766, and layer 4 768. Policy orchestrator 750 communicates between different levels for policy push and understanding of resource and service levels. The dynamic framework provided by policy orchestrator 760 provides flexibility for network policy architecture and effective enforcement.

[0055] Push message 710 is a message that provides service requirements or specific details that are pushed from one entity to another depending on which entity the entity communication occurs to.

[0056] A pull message 730 is a query that a particular entity can make with a different entity to obtain specific information. Queries for specific policies regarding underlying resources and service requirements may be generated bottom-to-top and top-to-bottom. Information can be resource-specific, such as information regarding resource availability or policies that apply depending on which entity's message is being communicated to which entity. The policy orchestrator operates at four different levels, as described above with reference to FIG. 4. Entities at different levels have policy control and management functions associated with that level.

[0057] The push message 710 and the pull message 730 use existing protocols. Thus, the push message 710 and the pull message 730 do not involve new methods or communication protocols, but rather contain information conveyed to support policy orchestration by the policy orchestrator 750. Layer 4 768, the top policy control and management layer, is used by applications to configure layers managing applications or defining application services. Applications can push their service requirements in message 711 to Layer 3 766, a network layer corresponding to a PCF in the core network or a RIC in the RAN. Layer 4 768 can also push message 714 to Layer 2 764 or message 716 directly to Layer 1 762, depending on the policy or service requirements. Layer 1 762 is at the platform / system level. Layer 3 766 can push message 712 to Layer 2 and message 715 to Layer 1 762. Layer 2 764 can push messages 713 to Layer 1 762. Thus, Figure 7 shows push messages 710 and pull messages 730 communicating directly between either layer, depending on what kinds of message parameters the layers want to share.

[0058] Similarly, Layer 1 762 can send pull message 731 to Layer 2 764, pull message 734 to Layer 3 766, and pull message 736 to Layer 4 768. Layer 2 764 can send pull message 732 to Layer 3 766 and pull message 735 to Layer 4 768. Layer 3 can send pull message 733 to Layer 4 768.

[0059] The role of the redirector 752 in policy orchestration 750 is to sit at the top, have end-to-end visibility from the primary policy control and management layers, and help redirect those messages, for example, from Layer 4 768 to Layer 2 764. For example, in response to Layer 4 768 wanting to send a specific service requirement and in response to Layer 4 768 having knowledge or information that this can be fulfilled via Layer 2 764, Layer 4 768 sends a message to L2. L4 can also send message 770 to the redirector 752, which, based on end-to-end visibility, redirects message 770 to Layer 764 as message 774. The redirector is implemented by the policy orchestrator. The redirector 750 can also use message 772 at Layer 3 766 and message 776 at Layer 1 762. Thus, the redirector 750 can receive messages 770, 772, 774, and 776 from layer 4 768, layer 3 766, layer 2 764, and layer 1 762, respectively. The redirector 750 can send messages 770, 772, 774, and 776 to layer 4 768, layer 3 766, layer 2 764, and layer 1 762, respectively.

[0060] FIG. 8 illustrates an interaction 800 of pull and push messages according to at least one embodiment.

[0061] 8 shows two levels: Level N 810 and Level M 830. Compared to Level N 810, a higher level is represented as Level M 830, where M is greater than N. Level N 810 can pull policy-specific decisions for enforcement at the enforcement level from Level M 830 using pull messages 840. Level M 830 can pull from resource management and service level requirements of Level N 810 using pull messages 842.

[0062] Similarly, Level N 810 can push resource management and service level requirements to Level M 830 using push messages 850. Level M 830 can push policy level decisions to Level N 810 using push messages 852. Thus, pull messages 860 and push messages 870 can exist between Level 1, Level 2, Level 3, and Level 4. Additionally, there may be more or fewer layers, such as 3 or 5.

[0063] As described above, pull messages 860 are queries, and push messages 870 are used to provide specific parameters of specific requirements to be enforced. For example, in the case of push message 860 to push a policy level decision, level M 830 is pushing a specific policy level decision for level N 810 from a higher layer to a lower layer, e.g., push message 842. Similarly, to push resource level and service level requirement information, push message 840 is sent from level N 810 to level M 830, e.g., from a lower layer to a higher layer.

[0064] Similarly, a pull message 850 may be sent from Level N 810 to Layer M 830, for example, to pull policy-specific decisions from a lower layer to a higher layer.

[0065] Pull messages 852 may be sent from Level M 830 to Level N 810 to pass resource management and service level requirements, for example, from higher layers to lower layers.

[0066] FIG. 9 illustrates metadata for pull and push messages 900 according to at least one embodiment.

[0067] 9 shows an example of the hierarchical layers of a pull message 910 and a push message 960. Those skilled in the art will appreciate that the format and structure of the elements are implementation specific.

[0068] For a push message 910 used for policy enforcement, metadata is shown for a hierarchical level 920, a routing component 930, and a policy management node identifier 940. For the hierarchical level 920 of the push message 910, the metadata specifies a source (Src) level 922 and a destination level 924. For the routing component 930 of the push message 910, the metadata includes a source (Src) realm 932 and a destination realm 934. For the policy management node identifier 940 of the push message 910, the metadata provides a source (Src) level policy node 942 and a destination policy node 944. Other metadata for the push message includes an enforcement node 950, service level requirements 952, resource status 954, etc.

[0069] With respect to the hierarchical level 920 of the pull message 960 for resource evaluation, the metadata specifies a source (Src) level 926 and a destination level 928. With respect to the routing component 930 of the pull message 960, the metadata includes a source (Src) realm 936 and a destination realm 938. With respect to the policy management node identifier 940 of the pull message 960, the metadata provides a source (Src) level enforcement node 946 and a destination enforcement node 948. Other metadata of the pull message 960 includes a policy node 970, a service level requirement 972, a resource status 974, etc. Different cloud platforms may run different network functions, so different policies may be provided for different cloud platforms. The service level requirements 952, 972, and the resource status 954, 974 include policy-specific parameters that are transmitted. The policy-specific parameters are implementation-specific.

[0070] FIG. 10 is a flowchart 1000 of a method for providing a policy orchestration framework for supporting an end-to-end (E2E) policy architecture using top-to-bottom policy orchestration, according to at least one embodiment.

[0071] In FIG. 10, the method starts at S1002, and at S1010, a front-end network having a first plurality of layers supporting a network service is provided. The front-end network is a radio access network (RAN) having a RAN intelligent controller (RIC) supporting a policy control and management layer and a radio resource manager (RRM) supporting a policy enforcement layer. Referring to FIG. 3, a policy orchestrator 310 coordinates policies top-to-bottom and end-to-end between the front-end and back-end. The front-end network is referred to as the radio access network (RAN) 350. The back-end network is referred to as the core network 360. The RAN 350 provides the policy control and management layer 330 via the RAN intelligent controller (RIC) 332 and the policy enforcement layer 340 via the radio resource manager (RRM) 342. The RIC 332 performs resource management and coordination for the RAN 350. The RIC 332 manages and intelligently controls network node resources. At the policy enforcement layer 340 above the RAN 350, the RRM 334 enforces the policy decisions specified in the policy control and management layer 330. Because the front end provided by the RAN 350 and the back end provided by the core network 360 are two independent entities, the policies applied in the core network 360 are independent from the policies applied in the RAN 350.

[0072] At S1014, a backend network having a second plurality of layers supporting network services is provided, the backend network being a core network having a policy control function (PCF) supporting the policy control and management layer and a policy and charging enforcement function (PCEF) supporting the policy enforcement layer. Referring to FIG. 3, the policy orchestrator 310 coordinates policies top-to-bottom and end-to-end between the front end and the backend. The backend network is referred to as the core network 360. The core network 360 provides the policy control and management layer 330 via the policy control function (PCF) 334 and the policy enforcement layer 340 via the policy and charging enforcement function (PCEF) 344. The PCF 334 on the core network 360 performs resource management and coordination, manages network node resources, and controls network node resources. The PCEF 344 on the core network 360 enforces policy decisions specified by the policy control and management layer 330 of the core network 360. The policies applied in the core network 360 are independent from the policies applied in the RAN 350, since the front end provided by the RAN 350 and the back end provided by the core network 360 are two independent entities.

[0073] At S1018, policy orchestration provides an end-to-end view between the front end and back end by providing visibility at the system / platform level, visibility of network functions at the node level, visibility at the network service end-to-end level, and visibility at the application level. Referring to FIG. 4, a vertical cross-section of the system is layered at four different levels from a policy orchestration perspective. The policy orchestrator provides visibility into the network through application-level use cases 410, the network service end-to-end level 420, the network node or network function level 430, and the system / platform level 440. Visibility into applications running on the network is provided. At the use case or application level 410, the policy orchestrator, according to at least one embodiment, provides visibility into the use case level 412, network slicing 414, applications 416, etc. For example, a particular access network requires connectivity to fiber-to-the-home and Wi-Fi-to-the-home. At the network service end-to-end level 420, a policy orchestrator according to at least one embodiment provides visibility into network services 422, end-to-end bearers 424, etc. At the network node or network function level 430, a policy orchestrator according to at least one embodiment provides visibility into nodes 432, service differentiation 434, etc. For example, visibility into different network nodes, such as the specific gateways or routers involved. At the system / platform level 440, a policy orchestrator according to at least one embodiment provides visibility into platforms 442, infrastructure 444, resources 446, etc. For example, visibility into a computing platform is a specific router. The policy orchestrator applies policies at the level of the functions running to support the applications.

[0074] At S1022, the policy orchestrator coordinates end-to-end policy decisions for the first plurality of layers at the front end and the second plurality of layers at the back end by providing intercommunication between the first plurality of layers and the second plurality of layers using push and pull messages between the first plurality of layers and the second plurality of layers. Referring to Figure 3, the policy orchestrator 310, according to at least one embodiment, coordinates between the policy control and management layer 330 and the policy enforcement layer 340 of the RAN 350 and the policy control management layer 330 and the policy enforcement layer 340 of the core network 360 such that policy decisions made are based on end-to-end visibility of resources in the network. The policy orchestrator 310 coordinates policies top-to-bottom and end-to-end within the RAN 350 and the core network 360 using push / pull messages 370 and 372, respectively.

[0075] Then, in S1040, the process ends.

[0076] At least one embodiment of a method for providing a policy orchestration framework that supports an end-to-end (E2E) policy architecture using top-to-bottom policy orchestration includes providing a front-end network having a first plurality of layers that support network services; providing a back-end network having a second plurality of layers that support network services; and providing policy orchestration by providing an end-to-end view between the front-end network and the back-end network and by coordinating end-to-end policy decisions for the first plurality of layers of the front-end network and the second plurality of layers of the back-end network.

[0077] FIG. 11 is a high-level functional block diagram of a processor-based system 1100 according to at least one embodiment.

[0078] In at least one embodiment, the processing circuit 1100 provides a policy orchestration framework for supporting an end-to-end (E2E) policy architecture using top-to-bottom policy orchestration. The processing circuit 1100 implements the policy orchestration framework for supporting an end-to-end (E2E) policy architecture using top-to-bottom policy orchestration using a processor 1102. The processing circuit 1100 also includes a non-transitory computer-readable storage medium 1104 used to implement the policy orchestration framework for supporting an end-to-end (E2E) policy architecture using top-to-bottom policy orchestration. The non-transitory computer-readable storage medium 1104 is encoded with, i.e., stores, among other things, instructions 1106, i.e., computer program code, that are executed by the processor 1102, causing the processor 1102 to perform operations for the policy orchestration framework to support an end-to-end (E2E) policy architecture using top-to-bottom policy orchestration. Execution of instructions 1106 by processor 1102 represents (at least in part) an application that implements at least a portion of the methods described herein (hereinafter, the described processes and / or methods) in accordance with one or more embodiments.

[0079] The processor 1102 is electrically coupled to a non-transitory computer-readable storage medium 1104 via a bus 1108. The processor 1102 is electrically coupled to an input / output (I / O) interface 1110 by the bus 1108. A network interface 1112 is also electrically connected to the processor 1102 via the bus 1108. The network interface 1112 is connected to a network 1114, thereby connecting the processor 1102 and the non-transitory computer-readable storage medium 1104 to external elements via the network 1114. The processor 1102 is configured to execute instructions 1106 encoded in the non-transitory computer-readable storage medium 1104, enabling the processing circuit 1100 to perform at least a portion of a process and / or method. In one or more embodiments, the processor 1102 is a central processing unit (CPU), a multiprocessor, a distributed processing system, an application-specific integrated circuit (ASIC), and / or other suitable processing unit.

[0080] The processing circuit 1100 includes an I / O interface 1110. The I / O interface 1110 is coupled to external circuitry. In one or more embodiments, the I / O interface 1110 includes a keyboard, keypad, mouse, trackball, trackpad, touchscreen, and / or cursor direction keys for communicating information and commands to the processor 1102.

[0081] The processing circuit 1100 also includes a network interface 1112 coupled to the processor 1102. The network interface 1112 enables the processing circuit 1100 to communicate with a network 1114 to which one or more other computer systems are connected. The network interface 1112 may include a wireless network interface, such as Bluetooth, Wi-Fi, Worldwide Interoperability for Microwave Access (WiMAX), General Packet Radio Service (GPRS), or Wideband Code Division Multiple Access (WCDMA), or a wired network interface, such as Ethernet, Universal Serial Bus (USB), Institute of Electrical and Electronics Engineers (IEEE) 864, etc.

[0082] The processing circuit 1100 is configured to receive information via an I / O interface 1110. The information received via the I / O interface 1110 includes one or more of instructions, data, design rules, a library of cells, and / or other parameters for processing by the processor 1102. The information is transferred to the processor 1102 via the bus 1108. The processing circuit 1100 is configured to receive information related to a user interface (UI) via the I / O interface 1110. The information is stored in the non-transitory computer-readable storage medium 1104 as a UI 1122.

[0083] In one or more embodiments, one or more non-transitory computer-readable storage media 1104 storing instructions 1106 (in compressed or uncompressed format) that can be used to program a computer, processor, or other electronic device to perform the processes or methods described herein. The one or more non-transitory computer-readable storage media 1104 include one or more of an electronic storage medium, a magnetic storage medium, an optical storage medium, a quantum storage medium, etc.

[0084] For example, the non-transitory computer-readable storage medium 1104 may include, but is not limited to, a hard drive, a floppy diskette, an optical disk, a read-only memory (ROM), a random-access memory (RAM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), a flash memory, a magnetic or optical card, a solid-state memory device, or any other type of physical medium suitable for storing electronic instructions. In one or more embodiments that use an optical disk, the one or more non-transitory computer-readable storage media 1104 include a compact disk read-only memory (CD-ROM), a compact disk read / write (CD-R / W), and / or a digital video disk (DVD).

[0085] In one or more embodiments, the non-transitory computer-readable storage medium 1104 stores instructions 1106 configured to cause the processor 1102 to execute at least a portion of a process and / or a method for a policy orchestration framework that supports an end-to-end (E2E) policy architecture using top-to-bottom policy orchestration. In one or more embodiments, the non-transitory computer-readable storage medium 1104 also stores information, such as algorithms, that facilitate execution of at least a portion of the process and / or a method for a policy orchestration framework that supports an end-to-end (E2E) policy architecture using top-to-bottom policy orchestration.

[0086] Thus, in at least one embodiment, the processor 1102 executes instructions 1106 stored on one or more non-transitory computer-readable storage media 1104 to implement a user interface 1120 that presents policies 1122 and policy decisions 1124. The processor 1102 implements a policy orchestrator 1130. The policy orchestrator 1130 provides a top-to-bottom, end-to-end view 1131 of the network to orchestrate policies. The policy orchestrator 1130 provides end-to-end policy decision coordination 1132 between the radio access network layer and the core network layer so that policy decisions made are based on end-to-end visibility of resources in the network. The policy orchestrator 1130 provides metadata about intercommunications between various layers of policy nodes using push and pull messages 1133, which are used for direct, transparent, and redirected communication between different nodes top-to-bottom and vice versa. The processor 1102 implements a policy orchestrator 1130 to provide different policies to different cloud platforms because different network functions can run on different cloud platforms. The policy orchestrator 1130 can determine policy-specific decisions 1134 and resource management and service level requirement information 1135 that are coordinated end-to-end between layers of the network. The policy orchestrator 1130 implemented by the processor 1102 provides metadata for push and pull messages, including metadata of hierarchical level information, routing component information, and policy management node identifiers. The metadata 1140 for policy enforcement includes hierarchical level information specifying the source (Src) level and destination level, routing component information including the source (Src) realm and destination realm, policy management node identifier information including the source (Src) level policy node, and the destination policy node.Other metadata include enforcement nodes, service level requirements, resource status, etc. The metadata for resource evaluation 1142 includes hierarchical level information identifying the source (Src) level and destination level, routing component information including the source (Src) realm and destination realm, and policy management node identifier information including the source (Src) level enforcement node and the destination enforcement node. Other metadata include policy nodes, service level requirements, resource status, etc. Processor 1102 presents a user interface 1152 on display 1150, including policies 1154 and policy decisions 1156.

[0087] Embodiments described herein provide a method that provides one or more advantages. For example, a policy orchestrator according to at least one embodiment provides a top-to-bottom policy architecture for multi-access networks. The policy orchestrator according to at least one embodiment provides a framework for coordination of various policy-specific network entities. The policy orchestrator provides end-to-end visibility of network capabilities and applies policies to specific services. The policy orchestrator according to at least one embodiment enables a network to apply and manage policies for various grades and levels of service for better service delivery and network performance.

[0088] One aspect of the present specification is directed to a method [1] for providing a policy orchestration framework supporting an end-to-end (E2E) policy architecture using top-to-bottom policy orchestration, the method including: providing a front-end network having a first plurality of layers supporting a network service; providing a back-end network having a second plurality of layers supporting the network service; and providing policy orchestration by providing an end-to-end view between the front-end network and the back-end network and by coordinating end-to-end policy decisions for the first plurality of layers of the front-end network and the second plurality of layers of the back-end network based on the end-to-end view.

[0089] The method described in [1], wherein providing an end-to-end view between a front-end network and a back-end network includes providing visibility at the system / platform level, visibility of network functions at the node level, visibility at the end-to-end level of network services, and visibility at the application level.

[0090] The method of any one of [1] to [2], wherein coordinating policies between a first plurality of layers of a front-end network and a second plurality of layers of a back-end network includes providing intercommunication between the first plurality of layers and the second plurality of layers.

[0091] The method of any one of [1] to [3], wherein providing intercommunication between a first plurality of layers and a second plurality of layers includes providing push messages and pull messages between the first plurality of layers and the second plurality of layers.

[0092] The method of any one of [1] to [4], wherein providing push messages and pull messages between the first plurality of layers and the second plurality of layers includes one of providing pull messages communicated from a lower level to a higher level to obtain policy-specific decisions at an enforcement level, providing pull messages communicated from a higher level to a lower level to obtain resource level and service level requirement information, providing push messages communicated from a lower level to a higher level to provide resource level and service level requirement information, or providing push messages communicated from a higher level to a lower level to provide policy-specific decisions.

[0093] The method of any one of [1] to [5], wherein providing policy orchestration includes providing policy orchestration at a multi-access level management entity that provides cloud computing capabilities at the edge of a network.

[0094] The method according to any one of [1] to [6], wherein providing a front-end network having a first plurality of layers supporting network services includes providing a radio access network (RAN) having a RAN intelligent controller (RIC) supporting a policy control and management layer and a radio resource manager (RRM) supporting a policy enforcement layer, and providing a back-end network having a second plurality of layers supporting network services includes providing a core network having a policy control function (PCF) supporting the policy control and management layer and a policy and charging enforcement function (PCEF) supporting the policy enforcement layer.

[0095] One aspect of the present specification is directed to a policy orchestrator [8] including a memory storing computer-readable instructions and a processor coupled to the memory, the processor configured to execute the computer-readable instructions to perform operations to provide an end-to-end view between a network front-end having a first plurality of layers and a network back-end having a second plurality of layers, and to coordinate end-to-end policy decisions for the first plurality of layers of the network front-end and the second plurality of layers of the network back-end based on the end-to-end view.

[0096] The policy orchestrator of [8], wherein the end-to-end view between a front end of a network having a first plurality of layers and a back end of a network having a second plurality of layers includes a system / platform view, a node-level network function view, a network service end-to-end view, and an application-level view.

[0097] The policy orchestrator described in [8] to [9], wherein the processor is further configured to coordinate policies between the first plurality of layers at the front end of the network and the second plurality of layers at the back end of the network by providing intercommunication between the first plurality of layers and the second plurality of layers.

[0098] A policy orchestrator as described in [8] to

[10] , wherein the intercommunication between the first plurality of layers and the second plurality of layers includes push messages and pull messages communicated between the first plurality of layers and the second plurality of layers.

[0099] The policy orchestrator according to any one of [8] to

[11] , wherein the push messages and pull messages include one of: pull messages communicated from a lower level to a higher level to obtain policy-specific decisions at the enforcement level; pull messages communicated from a higher level to a lower level to obtain resource level and service level requirement information; push messages communicated from a lower level to a higher level to provide resource level and service level requirement information; and push messages communicated from a higher level to a lower level to provide policy-specific decisions.

[0100] The policy orchestrator of any one of [8] to

[12] , wherein the processor is further configured to coordinate end-to-end policy decisions for a first plurality of layers at the front end of the network and a second plurality of layers at the back end of the network by providing policy orchestration at a multi-access level management entity that provides cloud computing capabilities at the edge of the network.

[0101] A policy orchestrator as described in [8] to

[13] , wherein the front end of the network having a first plurality of layers includes a radio access network (RAN) having a RAN intelligent controller (RIC) supporting a policy control and management layer, and a radio resource manager (RRM) supporting a policy enforcement layer, and the back end network having a second plurality of layers includes a core network having a policy control function (PCF) supporting the policy control and management layer, and a policy and charging enforcement function (PCEF) supporting the policy enforcement layer.

[0102] One aspect of the present specification is a non-transitory computer-readable medium described in

[15] having computer-readable instructions stored therein that, when executed by a processor, cause the processor to perform operations including: providing a front-end network having a first plurality of layers supporting a network service; providing a back-end network having a second plurality of layers supporting the network service; and providing policy orchestration by providing an end-to-end view between the front-end network and the back-end network and by coordinating end-to-end policy decisions for the first plurality of layers of the front-end network and the second plurality of layers of the back-end network based on the end-to-end view.

[0103]

[15] The non-transitory computer-readable medium of

[15] , wherein providing an end-to-end view between a front-end network and a back-end network includes providing visibility at the system / platform level, visibility of network functions at the node level, visibility at the end-to-end level of network services, and visibility at the application level.

[0104]

[15] to

[16] . The non-transitory computer-readable medium of

[15] to

[16] , wherein coordinating policies between a first plurality of layers of a front-end network and a second plurality of layers of a back-end network includes providing push messages and pull messages between the first plurality of layers and the second plurality of layers.

[0105] The non-transitory computer-readable medium of any one of

[15] to

[17] , wherein providing push messages and pull messages between the first plurality of layers and the second plurality of layers includes one of providing pull messages communicated from a lower level to a higher level to obtain policy-specific decisions at an enforcement level, providing pull messages communicated from a higher level to a lower level to obtain resource level and service level requirement information, providing push messages communicated from a lower level to a higher level to provide resource level and service level requirement information, or providing push messages communicated from a higher level to a lower level to provide policy-specific decisions.

[0106] The non-transitory computer-readable medium of any one of

[15] to

[18] , wherein providing policy orchestration includes providing policy orchestration at a multi-access level management entity that provides cloud computing capabilities at the edge of a network.

[0107]

[15] to

[19] . A non-transitory computer-readable medium according to any one of claims 1 to 19, wherein providing a front-end network having a first plurality of layers supporting network services includes providing a radio access network (RAN) having a RAN intelligent controller (RIC) supporting a policy control and management layer and a radio resource manager (RRM) supporting a policy enforcement layer, and providing a back-end network having a second plurality of layers supporting network services includes providing a core network having a policy control function (PCF) supporting the policy control and management layer and a policy and charging enforcement function (PCEF) supporting the policy enforcement layer.

[0108] Separate instances of these programs may be running on or distributed on any number of separate computer systems. Thus, although particular steps are described as being performed by particular devices, software programs, processes, or entities, this is not necessarily the case. Various alternative implementations will be appreciated by those skilled in the art.

[0109] Furthermore, those skilled in the art will readily recognize that the above-described techniques can be utilized in a variety of devices, environments, and situations. Although the embodiments have been described in language specific to structural features or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claims.

Claims

1. 1. A method for providing a policy orchestration framework for supporting an end-to-end (E2E) policy architecture using top-to-bottom policy orchestration, comprising: providing a front-end network having a first plurality of layers supporting a network service; providing a back-end network having a second plurality of layers supporting the network service; providing policy orchestration by providing an end-to-end view between the front-end network and the back-end network, and by coordinating end-to-end policy decisions for the first plurality of layers of the front-end network and the second plurality of layers of the back-end network based on the end-to-end view.

2. 2. The method of claim 1, wherein providing the end-to-end view between the front-end network and the back-end network includes providing visibility at a system / platform level, visibility of network functions at a node level, end-to-end visibility of network services, and visibility at an application level.

3. 2. The method of claim 1, wherein coordinating the policy decisions between the first plurality of layers of the front-end network and the second plurality of layers of the back-end network includes providing intercommunication between the first plurality of layers and the second plurality of layers.

4. 4. The method of claim 3, wherein providing intercommunication between the first and second layers comprises providing push and pull messages between the first and second layers.

5. 5. The method of claim 4, wherein providing the push and pull messages between the first plurality of layers and the second plurality of layers comprises one of: providing pull messages communicated from a lower level to a higher level to obtain policy-specific decisions at an enforcement level; providing pull messages communicated from the higher level to the lower level to obtain resource level and service level requirement information; providing push messages communicated from the lower level to the higher level to provide the resource level and service level requirement information; or providing push messages communicated from the higher level to the lower level to provide the policy-specific decisions.

6. The method of claim 1 , wherein providing the policy orchestration comprises providing the policy orchestration at a multi-access level management entity that provides cloud computing capabilities at the edge of a network.

7. 2. The method of claim 1, wherein providing the front-end network having the first plurality of layers supporting the network service comprises providing a radio access network (RAN) having a RAN intelligent controller (RIC) supporting a policy control and management layer and a radio resource manager (RRM) supporting a policy enforcement layer, and wherein providing the back-end network having the second plurality of layers supporting the network service comprises providing a core network having a policy control function (PCF) supporting the policy control and management layer and a policy and charging enforcement function (PCEF) supporting the policy enforcement layer.

8. 1. A policy orchestrator, comprising: a memory for storing computer-readable instructions; and a processor coupled to the memory; The processor, for providing an end-to-end view between a front end of a network having a first plurality of layers and a back end of a network having a second plurality of layers, and a policy orchestrator configured to execute computer-readable instructions to perform orchestration to coordinate end-to-end policy decisions for the first plurality of layers in a front end of the network and the second plurality of layers in a back end of the network based on the end-to-end view.

9. 9. The policy orchestrator of claim 8, wherein the end-to-end view between the front end of the network having the first plurality of layers and the back end of the network having the second plurality of layers includes a system / platform view, a node-level network function view, a network service end-to-end view, and an application-level view.

10. 9. The policy orchestrator of claim 8, wherein the processor is further configured to coordinate the policy decisions between the first plurality of layers of the front end of the network and the second plurality of layers of the back end of the network by providing intercommunication between the first plurality of layers and the second plurality of layers.

11. 11. The policy orchestrator of claim 10, wherein the intercommunication between the first plurality of layers and the second plurality of layers includes push messages and pull messages communicated between the first plurality of layers and the second plurality of layers.

12. 12. The policy orchestrator of claim 11, wherein the push and pull messages include one of: a pull message communicated from a lower level to a higher level to obtain policy-specific decisions at an enforcement level; a pull message communicated from the higher level to the lower level to obtain resource level and service level requirement information; a push message communicated from the lower level to the higher level to provide the resource level and service level requirement information; or a push message communicated from the higher level to the lower level to provide the policy-specific decisions.

13. 10. The policy orchestrator of claim 8, wherein the processor is further configured to coordinate end-to-end policy decisions for the first plurality of layers at the front end of the network and the second plurality of layers at the back end of the network by providing policy orchestration at a multi-access level management entity that provides cloud computing capabilities at the edge of the network.

14. 9. The policy orchestrator of claim 8, wherein the front end of the network having the first plurality of layers includes a radio access network (RAN) having a RAN intelligent controller (RIC) that supports a policy control and management layer, and a radio resource manager (RRM) that supports a policy enforcement layer, and the back end of the network having the second plurality of layers includes a core network having a policy control function (PCF) that supports a policy control and management layer, and a policy and charging enforcement function (PCEF) that supports a policy enforcement layer.

15. A non-transitory computer-readable medium having computer-readable instructions stored therein that, when executed by a processor, providing a front-end network having a first plurality of layers supporting a network service; providing a back-end network having a second plurality of layers supporting the network service; and providing policy orchestration by providing an end-to-end view between a front-end network and a back-end network, and by coordinating end-to-end policy decisions for the first plurality of layers of the front-end network and the second plurality of layers of the back-end network based on the end-to-end view.

16. 16. The non-transitory computer-readable medium of claim 15, wherein providing an end-to-end view between the front-end network and the back-end network includes providing visibility at a system / platform level, visibility of network functions at a node level, visibility at an end-to-end level of network services, and visibility at an application level.

17. 16. The non-transitory computer-readable medium of claim 15, wherein coordinating the policy decisions between the first plurality of layers of the front-end network and the second plurality of layers of the back-end network includes providing push and pull messages between the first plurality of layers and the second plurality of layers.

18. 20. The non-transitory computer-readable medium of claim 17, wherein providing push and pull messages between the first plurality of layers and the second plurality of layers comprises one of: providing pull messages communicated from a lower level to a higher level to obtain policy-specific decisions at an enforcement level; providing pull messages communicated from the higher level to the lower level to obtain resource level and service level requirement information; providing push messages communicated from the lower level to the higher level to provide the resource level and service level requirement information; or providing push messages communicated from the higher level to the lower level to provide the policy-specific decisions.

19. 16. The non-transitory computer-readable medium of claim 15, wherein providing the policy orchestration includes providing the policy orchestration at a multi-access level management entity that provides cloud computing capabilities at an edge of a network.

20. 16. The non-transitory computer-readable medium of claim 15, wherein providing the front-end network having the first plurality of layers supporting the network service comprises providing a radio access network (RAN) having a RAN intelligent controller (RIC) supporting a policy control and management layer and a radio resource manager (RRM) supporting a policy enforcement layer, and providing the back-end network having the second plurality of layers supporting the network service comprises providing a core network having a policy control function (PCF) supporting a policy control and management layer and a policy and charging enforcement function (PCEF) supporting the policy enforcement layer.

Images