SYSTEM AND METHOD FOR PROVIDING DYNAMIC RADIO ACCESS NETWORK ORCHESTRATION

[0001] This application claims the benefit of priority under 35 U.S.C. §119(e) to U.S. Provisional Application Ser. No. 62/074,921, entitled “SYSTEM AND METHOD FOR PROVIDING DYNAMIC RADIO ACCESS NETWORK ORCHESTRATION” filed Nov. 4, 2014, which is hereby incorporated by reference in its entirety.

[0002] This disclosure relates in general to the field of communications and, more particularly, to a system and method for providing dynamic Radio Access Network (RAN) orchestration in a network environment.

[0003] Networking architectures have grown increasingly complex in communication environments. Mobile communication networks have grown substantially in subscriber base as end users become increasingly connected to mobile wireless environments. As the number of mobile subscribers increases, efficient management of communication resources becomes more critical. In some instances, network service providers desire to manage RAN functionality across a communication system. However, there are significant challenges in managing RAN functionality across a communication system, particularly with regard to timing constraints between RAN components and transport network components of the communication system.

[0015] A method is provided in one example embodiment and may include monitoring, by a radio access network (RAN) orchestration function, impairments between a plurality of candidate locations interconnected by a transport network, wherein one or more network elements capable of performing one or more operations associated with a RAN are located at the plurality of candidate locations; determining a decomposition of one or more operations associated with the RAN into a plurality of sets of virtualized network functions (VNFs) to execute the operations based, at least in part, on the monitored impairments; determining a distribution of the plurality of sets of VNFs among the one or more network elements associated with the RAN for one or more optimal locations of the plurality of candidate locations based, at least in part, on the monitored impairments; and instantiating the plurality of sets of VNFs at each of the one or more optimal locations. In some cases, network elements associated with the RAN include one or more of: one or more Radio Frequency (RF) termination points; and one or more data centers.

[0016] In some cases, the method can include configuring a plurality of orchestration policies for the RAN orchestration function, wherein each orchestration policy identifies a particular decomposition of one or more operations associated with the RAN into particular sets of VNFs based, at least in part, on particular impairments that can be present between the plurality of candidate locations interconnected by the transport network. In some instances, determining the distribution of the plurality of sets of particular VNFs for the one or more optimal locations can include identifying, one or more optimal locations at which to distribute one or more sets of VNFs for executing operations that are associated with one or more of: Layer 1 (L1) RAN control operations; Layer 2 (L2) RAN control operations; and Layer 3 (L3) RAN control operations. In some instances, identifying the one or more optimal locations at which to distribute the one or more sets of VNFs can include determining network element capabilities for the network elements capable of performing the one or more operations associated with the RAN located at the plurality of candidate locations.

[0017] In still some cases, the method can include monitoring user equipment (UE) demand associated with one or more of the plurality of candidate locations. In some instances, determining the decomposition of the one or more operations associated with the RAN can be based additionally on changes in UE demand at one or more of the plurality of candidate locations. In some instances, determining the distribution of the plurality of sets of VNFs can be based additionally on changes in UE demand at one or more of the plurality of locations.

[0018] In still some cases, the method can include generating RAN feedback information including one or more of: information associated with a particular decomposition and a particular distribution; and communicating the RAN feedback information to a transport management function associated with the transport network.

[0019] A system is provided in one example embodiment and may include a Radio Access Network (RAN) orchestration system comprising: at least one memory element; at least one processor; and a RAN orchestration function adapted when executed by the at least one processor to: monitor impairments between a plurality of candidate locations interconnected by a transport network, wherein one or more network elements capable of performing one or more operations associated with a RAN are located at the plurality of candidate locations; determine a decomposition of one or more operations associated with the RAN into a plurality of sets of virtualized network functions (VNFs) to execute the operations based, at least in part, on the monitored impairments; determine a distribution of the plurality of sets of VNFs among the one or more network elements associated with the RAN for one or more optimal locations of the plurality of candidate locations based, at least in part, on the monitored impairments; and instantiate the plurality of sets of VNFs at each of the one or more optimal locations.

[0020] In some cases, the RAN orchestration system can further include a virtualized infrastructure manager (VIM) adapted when executed by the at least one processor to manage resources for a Network Function Virtualization Infrastructure (NFVI) for each of the plurality of sets of VNFs. In still some cases, the RAN orchestration system can further include at least one VNF manager adapted when executed by the at least one processor to manage instantiation of the plurality of sets of VNFs at each of the one or more optimal locations.

[0021] As referred to herein in this Specification, the terms ‘virtual machine’, ‘virtualized network function’ and ‘virtualized network functionality’ can encompass an emulation of a computer system and/or computing platform operating based on the computer architecture and functions of a real or hypothetical computer, with particular embodiments involving specialized hardware, software, or a combination of both. In various embodiments, a virtualized network function (VNF), a virtual machine (VM), virtualized functionality and/or any virtualized network controller, module, aggregator, combinations thereof or the like as described herein may execute via a hypervisor-based virtualization or a container-based virtualization of a server (e.g., blade server, rack server, stand-alone server) using the server's hardware (e.g., processor and memory element) and/or operating system for a given virtualized network environment.

[0022] In some cases, VNF(s) can be configured to perform one or more specialized operations within a network environment and one or more instances of the configured VNF(s) can be instantiated in order to execute the one or more specialized operations. In some instances, VNF(s) can include one of more virtualized network function components (VNFCs). A VNFC can be an internal component of a VNF, which can provide a VNF provider a defined subset of that VNF's functionality. As referred to herein in this Specification, the term ‘decomposition’ and variations thereof can be used to indicate a logical separation of various VNFs, each of which can perform certain specialized operations, among one or more virtualized network controller(s), module(s), aggregator(s), combinations thereof or any other network element that may be associated with any given virtualized network environment. A given decomposition can be realized, in an operational sense, by instantiating VNFs associated with the decomposition to execute the specialized operations as configured for the VNFs.

[0023] Turning to FIG. 1, FIG. 1 is a simplified block diagram illustrating a communication system 10 to facilitate providing dynamic RAN orchestration according to one embodiment of the present disclosure. This particular configuration may be tied to the 3rd Generation Partnership Project (3GPP) Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial radio access network (E-UTRAN) architecture, which can interface with a Long Term Evolution (LTE) Evolved Packet System (EPS) core. Alternatively, the depicted architecture may be applicable to other environments equally.

[0024] The example architecture of FIG. 1 may include or more user equipment (UE) 12a-12c, a Radio Access Network (RAN) 80 (solid line cloud), which may interface with a RAN orchestration system (ROS) 14, one or more RAN controller(s) 16, one or more Radio Frequency (RF) termination point(s) 18, a transport network 20 (dash-dot line cloud), which may interface with a transport management function 22, and a mobile core network 24. Also shown in FIG. 1 is an internet 100, which may be associated with any packet data network (PDN) in various embodiments. RAN orchestration system 14 may include a RAN orchestration function 30, which may interface with one or more virtualized network function (VNF) Manager(s) 32 and a virtualized infrastructure manager (VIM) 34.

[0025] Note, although only one RF termination point(s) 18 is shown in FIG. 1, it should be understood that multiple RF termination points 18 can be distributed throughout RAN 80 for communication system 10. Additionally, although only one RAN controller(s) 16 is shown in FIG. 1, it should be understood that multiple RAN controllers 16 can be distributed among different network elements associated with RAN 80 at different locations throughout RAN 80 interconnected via transport network 20. As described in further detail herein, other network elements may be present within communication system 100 according to various embodiments of the present disclosure. For various embodiments described herein, the ‘(s)’ nomenclature is used to indicate ‘one or more’.

[0026] Each RAN controller(s) 16 can include a set of one or more VNF(s) 40, which may interface with VNF Manager(s) 32, and may also include a Network Function Virtualization Infrastructure (NFVI) 50 associated with the set of VNF(s) 40, which may interface with VIM 34 and VNF(s) 40. In various embodiments, the set of VNF(s) 40 can be instantiated at one or more location(s) of interconnected network elements of RAN 80 including RF termination point(s) 18 (e.g., RAN controller(s) 16 could be configured at the location(s) of RF termination point(s) 18) or any other location(s) of any other interconnected network elements that can be associated with RAN 80 including, but not limited to, a centralized data center such as, for example, an enterprise data center or a service provider data center, either of which can be realized in a cloud-based architecture. Each RF termination point(s) 18 may include a set of one or more VNF(s) 60, which may interface with VNF Manager(s) 32, may also include an NFVI 70 associated with VNF(s) 60, which may interface with VIM 34 and VNF(s) 60, and also includes a radio head 19, which may interface with the set of one or more VNF(s) 60 and NFVI 70. Note a set of VNF(s) can include one VNF.

[0027] RAN orchestration system 14, via RAN orchestration function 30, may interface with transport management function 22 in order to exchange communications between RAN 80 and transport network 20. The interface (dash-dot line) interconnecting RAN orchestration function 30 and transport management function 22 can be provided via transport network 20. In various embodiments, transport management function 22 may include functionality for monitoring one or more Service Level Agreement(s) (SLA(s)) and, when applicable, for enforcing command and/or control of the transport network 20.

[0028] In general, RAN 80 may provide a communications interface between UE 12a-12c and mobile core network 24 and/or internet 100 for one or more 3GPP and/or non-3GPP Internet protocol (IP) access networks. In various embodiments, 3GPP access networks can include Global System for Mobile Communications (GSM) Enhanced Data Rates for GSM (EDGE) radio access network (GERAN), a Universal Mobile Telecommunications System (UMTS) Terrestrial radio access network (UTRAN), generally referred to as 3G, and/or a LTE access network such as evolved UTRAN (E-UTRAN), generally referred to as 4G or LTE/LTE-Advanced (LTE-A). In various embodiments, non-3GPP IP access networks can include wireless local access networks (WLANs) such as WiFi, Worldwide Interoperability for Microwave Access (WiMAX), Bluetooth™ or the like.

[0029] RF termination point(s) 18 can offer any suitable over-the-air radio access connectivity to one or more UE (e.g., UE 12a-12c) using any appropriate protocol or technique via radio head 19. In various embodiments, radio head 19 can include circuitry, hardware, software, firmware, combinations thereof or the like to provide one or more radio transmitters and receivers to facilitate over-the-air radio access connectivity. As referred to herein in this Specification, over-the-air radio access connectivity may be generally referred to as a ‘link’. Note that an ‘RF termination point’ (e.g., RF termination point(s) 18) can also be referred to interchangeably in this Specification as a ‘cell’, ‘radio access point’ or ‘base station’. In various embodiments, RF termination point(s) 18 can be include any subset of base station functionalities, such as for example, Evolved Node B (eNodeB) functionalities, Home eNodeB (HeNB) functionalities, Node B (NodeB) functionalities, Radio Network Controller (RNC) functionalities, Home NodeB (H NB) functionalities, base transceiver station (BTS) functionalities, WiFi access point functionalities, Bluetooth™ access point functionalities, WiMAX access point functionalities, combinations thereof or the like.

[0030] The architecture of communication system 10 is equally applicable to small cell architectures and macro cell architectures that can be deployed within RAN 80. Small cells (e.g., HeNBs for 4G/LTE, HNBs for 3G) operate in a similar manner to macro cells (e.g., eNodeBs for 4G/LTE, NodeBs for 3G) but typically at a lower transmission power, thereby creating smaller coverage areas in which to serve UE. Small cell networks (e.g., grids or clusters of small cells) are typically deployed in enterprise or residential environments where coverage of macro cells is limited (e.g., by walls, roofs, etc.).

[0031] In various embodiments, mobile core network 24 may include one or more network elements such as, for example, one or more Serving General Packet Radio Service (GPRS) Support Nodes (SGSNs) and one or more Gateway GPRS support nodes (GGSNs), one or more Packet Data Network (PDN) gateways (PGWs), one or more Mobility Management Entities (MMES), one or more serving gateways (SGWs), one or more Policy and Charging Rules Functions (PCRFs), one or more Authentication, Authorization and Accounting (AAA) elements, a Home Subscriber Server/Home Location Register (HSS/HLR), etc. to provide connectivity for UE 12a-12c to one or more external PDNs, such as internet 100, to implement QoS on packet flows, to provide enhanced services to UE 12a-12c, stateful firewalls, Traffic Performance Optimization (TPO), etc. Mobile core network 24 may also include components to provide access for non-3GPP IP access networks. In various embodiments these components can include but not limited to one or ePDGs, one or more SaMOG access gateways (AGWs), combinations thereof or the like. Note the term ‘SaMOG’ as may refer S2a Mobility based on general packet radio service (GPRS) tunneling protocol (GTP), which may define interworking between a WLAN and 3GPP access systems, such as LTE. These elements are not shown in order to illustrate other features of communication system 10.

[0032] Transport network 20 may include all the infrastructure (e.g., associated network elements and communication links) to provide at least one differentiated, secure, reliable and manageable communication channel to provide: 1) interconnections, shown in FIG. 1 as fronthaul interface(s) (dash-dot lines), between RAN 80 network elements (e.g., RAN controller(s) 16, RF termination point(s) 18, etc.) for various RAN decompositions, which can be realized across different geographic locations within communication system 10; 2) general interconnections among other network elements distributed throughout or interconnected with RAN 80 (e.g., between RAN orchestration system 14 and transport management function 22, RAN controller(s) 16, RF termination point(s) 18 or any other network element may be present); 3) interconnections between RAN 80 network elements and network elements of mobile core network 24 (e.g., MME, SGW, ePDG, HNB-GW, HeNB-GW, etc., which can also be deployed, instantiated, etc. among different geographic locations), shown in FIG. 1 as a backhaul interface(s) (dash-dot line) between RAN controller(s) 16 and mobile core network 24 (e.g., there could be multiple RAN controllers 16, each having one or more backhaul interfaces to mobile core network 24), and/or 4) other network services such as, for example, RAN synchronization over heterogeneous transport technologies. In various embodiments, interconnections can include interfaces and/or points of connection that can be wired, wireless, physical and/or virtual among physical and/or virtual network elements interconnected and/or accessible by transport network 20.

[0033] The term ‘fronthaul’ is used herein in this Specification to describe interfaces provided via transport network 20 that interconnect network elements of any virtualization architecture for RAN 80, which may include different decompositions of sets of VNFs for RAN 80. The term ‘backhaul’ may be used herein to describe interface(s) provided via transport network 20 to interconnect network elements of any RAN 80 architecture (virtualized and non-virtualized) and network elements of mobile core network 24.

[0034] In some embodiments, transport network 20, via transport management function 22, can include real-time mechanisms to measure various transport network parameters, or more generally, performance or performance indicators, in order to characterize the transport network and to dynamically adjust the transport flows (e.g., user data traffic, control traffic) as commanded by the transport management function 22. As referred to herein in this specification, operations associated with measuring transport network performance or performance indicators among various locations of transport network 20 can be referred to as transport network 20 ‘characterization’. In some embodiments, fronthaul characterizations can be performed to characterize portions of the transport network 20 interconnecting network elements of RAN 80. In various embodiments, transport network parameters that can be measured for transport network 20 can include bidirectional path characteristics such as, for example, throughput, delay, jitter (e.g., variance of delay) loss, etc. Throughput, delay, jitter, loss or any other transport network parameters that can be measured for transport network 20 characterizations (e.g., fronthaul characterizations) be can be referred to herein collectively as ‘impairments’.

[0035] Before detailing some of the operational aspects of FIG. 1, it is important to understand common characteristics of RAN virtualization and cloudification. The following foundation is offered earnestly for teaching purposes only and, therefore should not be construed in any way to limit the broad teachings of the present disclosure. RAN virtualization and cloudification is a hot topic and is introducing the concept of fronthaul networks into virtualized RAN architectures.

[0036] Fronthaul characterizations can play an important role in determining how RAN functionality can be virtualized among different possible decompositions. Typically, RAN functionality is virtualized for deployments in which ‘ideal’ fronthaul networks can be deployed. By ‘ideal’ it is meant that ideal fronthaul bandwidth and latency requirements can be met for a deployment. In the future, however, there may be new RAN decompositions that can operate over non-ideal fronthaul networks. For example, standards may define a plurality of decompositions that have associated requirements in terms of fronthaul characteristics. Additionally, the characteristics of a given transport network may be such that a fronthaul realization cannot be supported and instead a traditional distributed-RAN/backhaul approach may need to be used. Further, the characteristics of the transport network may change, e.g., due to failure scenarios and other impairments. This may then result in a transport network that was previously characterized as capable of supporting an ‘ideal fronthaul’ to then be characterized as capable of supporting ‘non-ideal fronthaul’ or even an ‘impaired backhaul’ network.

[0037] Dynamic re-characterizations (e.g., cyclic characterizations, characterizations triggered by some network event, etc.) of a given transport network can result in decompositions of RAN functionality to be adapted according to the re-characterizations. This dynamic nature of RAN decomposition presents an opportunity to manage the RAN distribution based not only transport network performance, but also the demand presented by UE in the communication system.

[0038] In accordance with one embodiment, communication system 10 may provide a system and method to facilitate determining, via RAN orchestration system 14 and transport management function 22, decompositions or ‘flavors’ of decompositions of sets of virtualized network functions that can be distributed across network elements of RAN 80 interconnected among transport network 20 to perform one or more operations associated with RAN 80 and also determining locations at which the sets of virtualized network functions for the network elements of RAN 80 can be instantiated in order to optimize RAN 80 operation according to various fronthaul interface characterizations and/or UE demand within RAN 80. During operation, communication system 10 can provide dynamic, optimized realizations for RAN 80 by dynamically determining decompositions of operations associated with RAN 80 into sets of VN Fs for distribution among various network elements of RAN 80 based on transport network 20 characterizations and/or UE demand; determining optimal locations for instantiating the sets of VNFs; and instantiating the sets of VNFs at the optimal locations.

[0039] Communication system 10 may integrate transport level monitoring, via transport management function 22, in order to continuously and repeatedly provide characterizations of transport network 20 impairments. During operation, transport management function 22 may generate transport network 20 characterizations indicating various impairments that may be present among different locations of RF termination point(s) 18 at which VNF(s) 60 can be instantiated and different locations of other network elements associated with RAN 80 at which the set of VNF(s) 40 can be instantiated for one or more RAN controller(s) 16 and may communicate the characterizations to RAN orchestration function 30. In various embodiments, generating transport network 20 characterizations can include, but not be limited to, generating one or more table(s) indicating transport network 20 impairments for fronthaul interfaces among different locations interconnecting each of one or more RF termination point(s) 18 and other network elements associated with RAN 80 at which the set of VNF(s) 40 can be instantiated.

[0040] Thus, in various embodiments, table(s) used for characterizations can relate transport network 20 impairments with location(s) of RF termination point(s) 18 and other network elements of RAN 80 interconnected among transport network 20. In various embodiments, locations of network elements associated with RAN 80 can be identified using Global Positioning System (GPS) information, latitude and longitude information, grid or cluster information (e.g., local and/or global identifiers configured by a network operator and/or service provider) describing locations or geographic areas of macro cell networks, small cell networks, enterprise networks, etc., combinations thereof or the like. In some embodiments, location information for network elements associated with RAN 80 (e.g., RF termination point(s), data centers, servers, load balancers, etc.) can be configured for RAN orchestration function 30 and transport management function 22, which may allow these functions to easily identify locations of network elements associated with RAN 80. In still some embodiments, VNF(s) 32 and VIM 34 can be configured with location information, similar to RAN orchestration function 30, in order to identify resources for abstraction into NFVI (e.g., NFVI 50, 70) for various decompositions of VNFs.

[0041] A multitude of possible RAN decompositions (e.g., decomposition of operations associated with a given RAN into sets of VNF(s)) can be configured for RAN orchestration function 30 by a network operator and/or service provider. In some embodiments, on or more orchestration policies can be configured for RAN orchestration function 30 which can identify different possible decompositions of different sets of VNF(s) 40 that can be instantiated for one or more RAN controller(s) 16 and different sets of VNF(s) 60 that can be instantiated for one or more RF termination point(s) 18 in relation to different impairments that may be present between different locations of network elements of RAN 80. For example, during operation RAN orchestration function 30 can receive a characterization of impairments for transport network 20 generated by transport management function 22 and can compare the characterization of impairments to one or more configured orchestration policies to determine a particular decomposition of VNFs (e.g., a particular set of VNF(s) 40 and a particular set of VNF(s) 60) for RAN 80 that can be instantiated for one or more RAN controller(s) 16 and for one or more RF termination point(s) 18 in order to execute various operations associated with RAN 80.

[0042] In various embodiments, orchestration policies can be configured to include impairment criteria related to different impairments (e.g., throughput, delay (more generally, latency), jitter, loss, etc.) that can be present between different locations among transport network 20 and corresponding VNF decompositions associated with the different impairments. In various embodiments, ideal one-way latency/jitter may be sub-250 microseconds (usec); non-ideal one-way latency/jitter may be approximately 30 milliseconds (msec); sub-ideal one-way latency/jitter may be approximately 6 msec; and near-ideal one-way latency/jitter may be approximately 1 msec.

[0043] Upon determining a particular decomposition of VNFs for RAN 80, RAN orchestration function 30 can identify one or more locations of network elements associated with RAN 80 at which to instantiate the decomposition of VNFs. In particular, RAN orchestration function can identify one or more optimal location(s) at which to instantiate the set of VNF(s) 40 for one or more RAN controller(s) 16 from multiple candidate locations of network elements associated with RAN 80. Location(s) at which to instantiate the set of VNF(s) 60 may be tied to the actual physical location(s) at which RF termination point(s) 18 are deployed within communication system 10, as may be configured by a network operator or service provider.

[0044] The example decomposition of the set of VNF(s) 40 for RAN controller(s) 16 and the set of VNF(s) 60 for RF termination point(s) 18, as shown in FIG. 1 can be referred herein to as a ‘two-tiered’ decomposition architecture. In various embodiments, different ‘tiered’ decomposition architectures can be realized for different RAN 80 virtualizations.

[0045] In some embodiments, orchestration policies can be configured for RAN orchestration function 30 to provide for additional decompositions of the set of VNF(s) 40 for RAN controller(s) 16 into one or more set of VNF(s) for one or more RAN controller portion(s) and one or more other set of VNF(s) for one or more radio aggregator portion(s). Different optimal locations can be identified at which to instantiate the set of VNF(s) for the RAN controller portion(s) and at which to instantiate the set of VNF(s) for the radio aggregator portion(s); thereby providing for a ‘three-tiered’ decomposition architecture for realizing a decomposition of sets of VNF(s) among the RAN controller portion(s), the radio aggregator portion(s) and the RF termination point(s) 18 to perform various operations associated with RAN 80.

[0046] In various embodiments, the set of VNF(s) for each RAN controller portion(s) in various three-tiered RAN decompositions can be associated with one or more higher level operations such as, for example, Radio Resource Control (RRC) functionality, application level functionality, protocol signaling and/or Packet Data Convergence Protocol (PDCP) functionality. In various embodiments, the set of VNF(s) for each radio aggregator portion(s) can be associated with lower link level operations such as, for example, Media Access Control (MAC) functionality and/or Radio Link Control (RLC) functionality to support traffic (e.g., user data traffic and control traffic) for one or more RF termination point(s) 18.

[0047] In some embodiments, orchestration policies can be configured for RAN orchestration function 30 in which the set of VNF(s) for the RAN controller portion(s) and the radio aggregator portion(s) can be further decomposed into a first tier set of VNF(s) for first tier radio aggregator portion(s) that may be associated with PDCP functionality, and a second tier set of VNF(s) for second tier radio aggregator portion(s) that may be associated with RLC/MAC functionality. Different optimal locations can be identified at which to instantiate the set of VNF(s) for the RAN controller portion(s), at which to instantiate the first tier set VNF(s) for the first tier radio aggregator portion(s) and at which to instantiate the second tier set VNF(s) for the second tier radio aggregator portion(s); thereby providing for a ‘four-tiered’ decomposition architecture for realizing a decomposition of sets of VNF(s) among the RAN controller portion(s), the first tier radio aggregator portion(s), the second tier radio aggregator portion(s) and the RF termination point(s) 18 to perform various operations associated with RAN 80.

[0048] Thus, embodiments of communication system 10 can facilitate any level of decomposition of VNFs that may be associated with any operations that can be executed for RAN 80. Regardless of whether two, three, four or any other multi-tiered decompositions are configured for various orchestration policies, RAN orchestration function 30 may provision and instantiate all virtualized RAN functionality (e.g., VNFs) at various locations interconnected throughout transport network 20, to effectively realize a distributed RAN architecture for communication system 10.

[0049] For the remainder of the discussion of FIG. 1, reference is made to the two-tiered decomposition architecture as shown in FIG. 1. However, it should be understood that the remaining discussion of FIG. 1 can equally be applied to any other multi-tiered decomposition architecture that can be realized for different RAN 80 virtualizations.

[0050] In some embodiments, orchestration policies, in addition to identifying different decomposition combinations that can be realized for different transport network 20 impairments can also be configured to include distribution criteria that can be used to identify optimal locations at which one or more instances of the set of VNF(s) 40 for one or more RAN controller(s) 16 can be distributed among network elements of RAN 80. In some embodiments, the distribution criteria can include ranges of network impairments (e.g., throughput, delay, jitter, loss, etc.) which can trigger distribution of one or more instance(s) of the set of VNF(s) 40 at one or more location(s). For example, in some cases, one given decomposition of a particular set of VNF(s) 40 may require ideal or near-ideal latency/jitter conditions, which can result in one or more first location(s) (e.g., meeting the ideal or near-ideal criteria) being identified as optimal at which to instantiate the particular set of VNF(s) 40. However, in other cases, another given decomposition of another particular set of VNF(s) 40 may allow sub-ideal latency/jitter conditions, which can result in one or more second locations (e.g., meeting the sub-ideal criteria) being identified as optimal; in still some cases, the one or more second locations could include the first locations (e.g., if characterization of the first locations indicates ideal or near-ideal conditions, then the first locations could be included in the identified optimal locations meeting the sub-ideal criteria) and other additional locations meeting the sub-ideal criteria.

[0051] In still some embodiments, orchestration policies can also be configured to include network element capability criteria, which can additionally be used (e.g., in addition to any distribution criteria that may be configured) to identify optimal location(s) at which to instantiate the set of VNF(s) 40 associated with RAN controller(s) 16. To further illustrate the concept of ‘network element capability’, consider an example RAN functionality breakdown with major processing capabilities spread amongst: Layer 3 (L3) cell and UE control and signaling (e.g., S1/X2 signaling, IP and/or Radio Resource Control (RRC) signaling); Layer 2 (L2) UE data packet processing (e.g., Packet Data Convergence Protocol (PDCP), Media Access Control (MAC), Radio Link Control (RLC)) and subframe real-time physical layer (PHY) control; Layer 1 (L1)/PHY signal processing and channel coding; Digital Front End (DFE) digital signal manipulation for RF optimization; and RF digital to analog (D/A) and analog to digital (A/D) signal conversion.

[0052] Different network elements associated with RAN 80 may have different or limited functional capabilities (e.g., software and/or hardware configurations) and/or may have different or limited processing capabilities (e.g., ability to perform necessary functions at a required throughput rate, within a required time frame, for a required number of users, etc.) that may be needed to support certain decompositions of sets of VNFs. Thus, in some embodiments, orchestration policies can be configured to include network element capability criteria, which can be used to identify and distribute sets of VNF(s) at one or more optimal locations of network elements associated with RAN 80. In some embodiments, capabilities of various network elements associated with RAN 80 can be configured by a network operator and/or service provider for RAN orchestration function 30, which it may use to cross-reference different network element capabilities that can be included in orchestration policies in order determine which network elements among RAN 80 at which certain VNF decompositions can be instantiated.

[0053] Not all characterizations received by RAN orchestration function 30 may result in a new decomposition of sets of VNF(s) to be realized for RAN 80. In some embodiments, transport network 20 characterizations received by RAN orchestration function 30 may trigger a redistribution of the set of VNF(s) 40 among one or more locations for certain orchestration policies that can be configured for RAN orchestration function 30. Thus, RAN orchestration function 30 may provide for the ability to dynamically update the decompositions and/or the distributions of VNFs among network elements of RAN 80 for a variety

[0054] In still some embodiments, orchestration policies can be configured for RAN orchestration function 30 to consider UE demand (e.g., demand presented by UE 12a-12c) at one or more locations of network elements of RAN 80 in determining decompositions and/or distributions of sets of VNFs among network elements of RAN 80. In various embodiments, one or more network elements of RAN 80 (e.g., RF termination point(s) 18, RAN controller(s) 16 and/or RAN orchestration system 14) may monitor the demand presented by UE 12a-12c within RAN 80. In various embodiments, monitoring can include reporting UE demand to RAN orchestration function 30, which can be used to update the decomposition and/or sets of VN Fs among different network elements of RAN 80.

[0055] In various embodiments, UE demand can be associated with, capacity information (e.g., sum of instantaneous bandwidth from UEs) between various locations, UE location information, UE density information (e.g., sum of number of UEs) at various locations and/or UE service type demand information (e.g., voice, data, video, IP multimedia, etc. signaling events) of various UE (e.g., UE 12a-12c) within RAN 80. In some embodiments, UE measurement reports can be used to determine UE demand. In various embodiments, UE measurement reports for a given UE (e.g., UE 12a) can provide signal strength information for a given RF termination point serving the UE as well as signal strength information for one or more neighboring RF termination points that may be in the vicinity of the serving RF termination point. In some embodiments, UE measurement reports from multiple UEs can be used to determine path loss information, UE throughput rate, etc., which can provide an indication of UE demand at various locations among RAN 80.

[0056] In various embodiments, knowledge of characterization(s) among various locations of network elements of RAN 80 interconnected throughout transport network 20, network element capabilities and/or UE demand among the various locations can be used by RAN orchestration function 30 to trigger different decompositions and/or redistributions of sets of VNFs according to different orchestration policies. Thus, RAN orchestration function 30 may provide for the ability to draw from a range of inputs in various embodiments in order to dynamically realize different VNF decompositions and/or distributions including, but not limited to: distributed RAN (D-RAN) decompositions; MAC-PHY decompositions for MAC-PHY, subframe fronthaul and/or Common Public Radio Interface (CPRI) fronthaul decompositions, PDCP decompositions to provide separation between D-RAN and MAC-PHY elements [which would make UE signaling and control virtualized and keep the UE data plane (up to the lower part of PDCP) distributed], split PDCP decompositions (e.g., upper PDCP and lower PDCP), PDCP/RLC decompositions, RLC/MAC decompositions, split MAC (e.g., upper MAC and lower MAC), MAC/PHY decompositions, soft bit decompositions, subframe data decompositions, subframe symbol decompositions, combinations thereof or the like as may be configured through one or more orchestration policies that can be configured for RAN orchestration function 30.

[0057] In various embodiments, different sets of VNFs can be instantiated (e.g., PHY VNFs, MAC VNFs, RLC VNFs, PDCP VNFs, combinations thereof, or any other VNFs) to execute various operations associated with RAN 80 for a multitude of decompositions and/or distributions.

[0058] In various embodiments, MAC VNFs may be further decomposed into ‘upper MAC’ VNFs and ‘lower MAC’ VNFs; PHY VNFs may be further decomposed into ‘upper PHY’ VNFs and ‘lower PHY’ VNFs; and/or PDCP VNFs may be further decomposed into ‘upper PDCP’ VNFs and ‘lower PDCP’ VNFs.

[0059] In various embodiments, upper MAC VNFs can provide one or more operations associated with, but not limited to, one or MAC scheduling functions operating at a first scheduler rate and lower MAC VNFs can provide one or more operations associated with, but not limited to, one or more MAC scheduling functions operating at a second scheduler rate, in which the second scheduler rate may be faster than the first scheduler rate in order to meet latency requirements imposed for over-the-air communications between a given RF termination point and a given UE. In some embodiments, the upper MAC VNFs can provide operations associated with block-in-time scheduling decisions (e.g., blocks of scheduling decisions) that can be communicated at a lower rate to the lower MAC VNFs, which can work through the block-in-time scheduling decisions at a faster rate. Alternatively, in some embodiments, a general MAC VNF decomposition can be provided, which may perform MAC scheduling decision operations.

[0060] In various embodiments, upper PHY VNFs can provide one or more operations associated with, but not limited to, user processing functions, which can include Forward Error Correction (FEC) and Quadrature Amplitude Modulation (QAM) and antenna mapping for hard/soft bit fronthaul operations. In various embodiments, lower PHY VNFs can provide one or more operations associated with, but not limited to, cell processing functions, which can include resource mapping functions for subframe symbol fronthaul operations, Inverse Fast Fourier Transform (IFFT) and cyclic prefix (CP) functions, and/or parallel/serial (P/S) CPRI encoding for full CPRI or compressed CPRI fronthaul operations. Alternatively, in some embodiments, a general PHY VNF decomposition can be provided, which may perform one or more of these operations.

[0061] For example, within the RAN functions, interfaces between MAC and PHY layers may operate at a 1 msec subframe rate scheduling cycle to configure and operate the lower layers. Within the PHY processing chain there are UE level channel coding and modulation operations that are provided together with cell level resource allocation and signal processing operations. For downlink (DL) subframe fronthaul operations, the lower layer interface from the PHY provides an in-phase/quadrature (I/Q) data stream representing an RF waveform in digital form between QAM and multi-antenna mapping operations (denoted as ‘QAM+multi-antenna mapping’). The I/Q data stream is carried in the CPRI interface over a high speed digital link. Thus, in various embodiments, various operations associated with PHY layer processing can be decomposed into different sets of one or more VNF(s) for handling uplink (UL) and downlink (DL) traffic flows.

[0062] In various embodiments, upper PDCP VNFs can provide one or more operations associated with, but not limited to, UE signaling and control operations and lower PDCP VNFs can provide one or more operations associated with, but not limited to, providing UE data plane operations. Alternatively, in some embodiments, a general PDCP VNF decomposition can be provided with may perform one or more of these operations.

[0063] In various embodiments, RLC VNFs can provide one or more operations associated with, but not limited to, receiving RLC service data units (SDUs) from a previous layer (e.g., a PDCP layer for downlink data) and applying addressing and/or control operations to the SDUs to output RLC packet data units (PDUs) to a subsequent layer (e.g., a MAC layer for downlink data).

[0064] In some embodiments, the dynamic, optimized realizations that can be provided by RAN orchestration function 30 may also involve moving the location of non-base station functions away from RF termination point(s) 18 to some other location interconnected among transport network 20. In various embodiments, this can include, moving from a central datacenter location to a ‘super base station’ location. Note a ‘super base station’ may provide capabilities to support functionality for multiple base stations distributed within transport network 20; the terms ‘super base station’ and ‘base station hotel’ may be used interchangeably herein in this Specification. In some embodiments, non-base station functions can include functions associated with a Self-Organizing Network (SON) management system, which can include functionality to monitor and manage RAN 80 resources among different clusters of RF termination point(s) 18 for a homogenous deployment (e.g., for a certain small cell deployment) and/or among different deployments (e.g., among different small cell, macro cell, WLAN, etc. deployments) in a heterogeneous network (HetNet).

[0065] In various embodiments, RAN orchestration system 14 can be a localized unit, a specialized unit or part of a virtualized compute platform that can operate in a data center or cloud server center or any other network element that may be associated with RAN 80. Thus, various aspects of RAN orchestration system 14 may be virtualized into a cloud-based architecture to facilitate dynamic, optimized RAN 80 realizations for communication system 10.

[0066] Thus, as described for various embodiments discussed herein, RAN orchestration function 30 may draw from a range of inputs (e.g., characterizations, UE demand, orchestration policies, etc.) to provide optimized decompositions and distributions of virtualized network functionality for RAN 80 across different locations interconnected via transport network 20. With this wider view of RAN orchestration, the RAN itself can be physically dimensioned dynamically to ‘follow’ end user demand in both location and service characteristics.

[0067] Additionally, in some embodiments, RAN orchestration function 30 may generate RAN feedback information to communicate to transport management function 22 regarding the decomposition and/or distribution of sets of VNFs for RAN 80. In some embodiments, transport management function 22 may include reconfiguration functionality, which may respond to certain RAN feedback information received from RAN orchestration function 30 by reconfiguring network elements of transport network 20 to accommodate different service level agreements (SLAB) (e.g., providing differentiated bandwidth and/or jitter performance). In some embodiments, transport management function 22 can include functionality to use the RAN feedback information to adjust characterizations of transport network 20 and/or may further communicate the RAN feedback information to one or more network elements within transport network 20 or in communication with transport network 20 in order to distribute or redistribute network element capabilities for transport network 20 to adjust for any updates made to RAN 80 decompositions and/or distributions.

[0068] In still some embodiments, RAN orchestration function 30 may also be configured to provide admission control capabilities. In one or more embodiments, RAN orchestration function 30 may enforce and/or command the distribution (or re-distribution) of the actual radio resources offered to any of UE 12a-12c (e.g., increasing or reducing the resources) to maintain an optimized RAN 80 decomposition and/or an optimized use of transport network 20 resources.

[0069] In various embodiments, radio resources can include, but not be limited to, number of calls, accepted radio access bearer (RAB) types, etc. For example, given a reported bandwidth characteristic, the transport resources can be used to support a first average user bandwidth ‘X’ for UE 12a-12c for a first decomposition ‘A’ or a second average user bandwidth ‘Y’ for UE 12a-12c for a second decomposition ‘B’. If transport network 20 resources become constrained, for example, as average user bandwidth grows, this can then lead to an automatic re-distribution of RAN 80 resources. In various embodiments, distribution or re-distribution of RAN resource can include, but not be limited to, bringing online one or more new RF termination point(s) 18. Such RF termination point(s), which can be dynamically pushed offline or brought online, could be considered dormant capacity (in the physical sense), which could be enabled as a result of one or more actions and/or policies configured for RAN orchestration function 30.

[0070] By commanding the distribution (or redistribution) of resources for RAN 80 to maintain an optimized decomposition and/or optimized use of transport network 20 resources, RAN orchestration function 30 may also allow mobile network operators (MNOs) to control the investment cycle for network expansion. Consider, for example, a case in which an increase in UE traffic in the network may push the network to congestion and potentially to a mandatory expansion. Rather than being pushed to expansion, however, RAN orchestration function 30, by providing the ability to control the traffic accepted on one or more at one or more RF termination points to optimally use the available/installed resources on the transport network 20, may provide a ‘tool’ that MNOs can use to determine if and when to invest in network expansion.

[0071] In various embodiments, UE 12a-12c can be associated with users, employees, clients, customers, etc. wishing to initiate a flow in communication system 10 via some network. The terms ‘user equipment’, ‘mobile node’, ‘end user’, ‘user’, and ‘subscriber’ are inclusive of devices used to initiate a communication, such as a computer, a personal digital assistant (PDA), a laptop or electronic notebook, a cellular telephone, an i-Phone™, iPad™, a Google Droid™ phone, an IP phone, or any other device, component, element, or object capable of initiating voice, audio, video, media, or data exchanges within communication system 10. UE 12a-12c may also be inclusive of a suitable interface to a human user such as a microphone, a display, a keyboard, or other terminal equipment.

[0072] UE 12a-12c may also be any device that seeks to initiate a communication on behalf of another entity or element such as a program, a database, or any other component, device, element, or object capable of initiating an exchange within communication system 10. Data, as used herein in this document, refers to any type of numeric, voice, video, media, or script data, or any type of source or object code, or any other suitable information in any appropriate format that may be communicated from one point to another. In certain embodiments, UE 12a-12c may have a bundled subscription for network access and application services (e.g., voice, data), etc. Once the access session is established, the user can register for application services as well, without additional authentication requirements. There can be two different user data repositories (e.g., AAA databases, whitelist databases, etc.): one for the access user profile and one for the application user profile. IP addresses can be assigned using dynamic host configuration protocol (DHCP), remote authentication dial in user service (RADIUS), Stateless Address Auto-configuration, default bearer activation procedures, etc., or any suitable variation thereof. In various embodiments, UE 12a-12c can include one or transmitters and/or receivers (e.g., transceivers) and one or more antenna(s) to facilitate over-the-air communications with one or more RF termination point(s) 18 that may be deployed within RAN 80.

[0073] In various embodiments, VNF manager(s) 32 may include functionality to provide for management operations for sets of VNF(s) 40, 60. In various embodiments, such management operations can include, but not be limited to, instantiation, updating, scaling and/or termination of sets of VNF(s) 40, 60. In various embodiments, one particular VNF manager can serve each set(s) of VNF(s) 40 and another particular VNF manager can serve each set(s) of VNF(s) 60 or a given VNF manager can be serve multiple VNFs.

[0074] In various embodiments, VIM 34 may include functionality to provide for resource management operations of the compute storage network for NFVI 50 and NFVI 70. In various embodiments, resource management operations can include, but not be limited to, allocating and maintaining an inventory of software, computing, storage and/or network resources, which may be dedicated to NFVI 50 and NFVI manag70. In some embodiments, software resources can include hypervisors, which can be implemented as virtual machines (VMs) in a suitable server or other computing platform. In some embodiments, software resources can include containers, which can be implemented within an operating system or kernel in a suitable server or other computing platform.

[0075] In some embodiments, resource management operations can further include the allocation of virtualization enablers, such as for example, allocating VMs onto hypervisors or allocating containers within operating systems or kernels, compute resources, storage and/or network elements which may provide for network connectivity. In still some embodiments, resource management operations can further include managing resources to hypervisor-based or container-based virtualizations and/or resource reclamation. In still some embodiments, resource management operations can include providing for visibility into and/or management of NFVI 50, NFVI 70, root cause analysis of performance issues/problems with NFVI 50, NFVI 70, collection of fault information and/or collection of information for capacity planning, monitoring and/or optimization of one or more dynamic RAN 80 realizations. In one or more embodiments, RAN orchestration system 14 may include multiple VIMs 34.

[0076] In various embodiments, sets of VNF(s) 40 and sets of VNF(s) 60, respectively, may be implemented as virtualized software implementations (e.g., instantiations) of various RAN functionality, which may be capable of operating via NFVI 50 and NFVI 70, respectively. In various embodiments, NFVI 50 and NFVI 70 can each include hardware and/or software resources, a virtualization layer and virtualized resources. NFVI 50 and NFVI 70 may be used to couple respective set of VNF(s) 40 and respective set of VNF(s) 60 to underlying hardware resources providing for execution of the sets of VNFs. In various embodiments, hardware resources can include, but not be limited to network, computing and/or storage resources. Connectivity to hardware resources can be provided via the virtualization layer, which can be implemented as one or more hypervisors or containers. In various embodiments, the virtualization layer may be used to abstract the hardware and/or software resources into virtualized resources (e.g., virtual network, virtual computing and/or virtual storage resources), which can be provided to ensure execution of instantiated sets of VNFs. A discussion of different potential RAN decompositions that can be realized for various two-tiered architectures is now described.

[0077] Turning to FIGS. 2A-2C, FIGS. 2A-2C are simplified block diagrams 200A-200C illustrating example details associated with various example RAN decompositions which can be realized in accordance with various potential embodiments of communication system 10. In particular, the example RAN decompositions illustrated in FIGS. 2A-2C can be associated with example two-tiered decomposition architectures, which may support different decompositions of sets of VNFs that can be instantiated between one or more RAN controller(s) and one or more RF termination point(s) interconnected via a given transport network (e.g., transport network 20). The example RAN decompositions shown in FIGS. 2A-2C are provided for illustrative purposes only to provide context to example embodiments described herein in the present disclosure and are not meant to limit the broad scope of the embodiments described herein. It should be understood that any RAN decompositions corresponding to any network element capability, transport network characterization and/or UE demand are certainly encompassed by alternative embodiments of the present disclosure as described herein and/or otherwise encompassed by any communication system that may provide for dynamic RAN orchestration.

[0078] FIG. 2A illustrates an example RAN decomposition for an example two-tiered architecture in which an example RAN controller 16A includes a set of VNFs 40A and an example RF termination point 18A includes a set of VNF 60A and a radio head 19A. Radio head 19A may be provided in RF termination point 18A to facilitate over-the-air communications with a given UE (e.g., any of UE 12a-12c). In various embodiments, the example RAN decomposition shown in FIG. 2A can be provided for transport network characterizations indicating good performance (e.g., ideal or near-ideal latency/jitter) among certain locations of transport network 20. For the example RAN decomposition shown in FIG. 2A, the set of VNFs 40A may include a PDCP VNF to provide PDCP functionality, an RLC VNF to provide RLC functionality, a MAC VNF to provide MAC functionality, an RRC VNF to provide RRC functionality and an upper PHY VNF to provide upper PHY functionality for RAN controller 16A and VNF 60A may include a lower PHY VNF to provide lower PHY functionality for RF termination point 18A.

[0079] FIG. 2B illustrates another example RAN decomposition for another two-tiered architecture in which an example RAN controller 16B includes a set of VNFs 40B and an example RF termination point 18B includes a set of VNFs 60B and a radio head 19B. Radio head 19B may be provided in RF termination point 18B to facilitate over-the-air communications with a given UE (e.g., any of UE 12a-12c). In various embodiments, the example RAN decomposition shown in FIG. 2B can be provided for transport network characterizations indicating mediocre performance (e.g., less than near-ideal, sub-ideal or variations thereof latency/jitter) among certain locations of transport network 20. For the example RAN decomposition shown in FIG. 2B, the set of VNFs 40B may include a PDCP VNF to provide PDCP functionality, an RLC VNF to provide RLC functionality, a MAC VNF to provide MAC functionality and an RRC VNF to provide RRC functionality for RAN controller 16B and the set of VNFs 60B may include an upper PHY VNF to provide upper PHY functionality and a lower PHY VNF to provide lower PHY functionality for RF termination point 18B.

[0080] FIG. 2C illustrates yet another example RAN decomposition for another two-tiered architecture in which an example RAN controller 16C includes a set of VNFs 40C and an example RF termination point 18C includes a set of VNFs 60C and a radio head 19C. Radio head 19C may be provided in RF termination point 18C to facilitate over-the-air communications with a given UE (e.g., any of UE 12a-12c). In various embodiments, the example RAN decomposition shown in FIG. 2C can be provided for transport network characterizations indicating poor performance (e.g., non-ideal or variations thereof latency/jitter) among certain locations of transport network 20. For the example RAN decomposition shown in FIG. 2C, the set of VNFs 40C may include a PDCP VNF to provide PDCP functionality, an RLC VNF to provide RLC functionality, an upper MAC VNF to provide upper MAC functionality and an RRC VNF to provide RRC functionality for RAN controller 16C and the set of VNFs 60C may include a lower MAC VNF to provide lower MAC functionality, an upper PHY VNF to provide upper PHY functionality and a lower PHY VNF to provide lower PHY functionality for RF termination point 18C.

[0081] Turning to FIG. 3, FIG. 3 is a simplified block diagram 300 illustrating yet other example details associated with other example RAN decompositions that can be realized in accordance with one potential embodiment of communication system 10. In various embodiments, the example RAN decompositions shown in FIG. 3 can be associated with a multi-tiered RAN decomposition for different sets of VNFs, which can be distributed among various network elements associated with RAN 80 for downlink (DL) UE traffic flows.

[0082] FIG. 3 illustrates a first VNF decomposition 302 including a set of PDCP, RLC and MAC VNFs, which can support MAC-PHY fronthaul operations; a second VNF decomposition 304 including a set of FEC VNF, which can support soft bit fronthaul operations; a third VNF decomposition 306 including a set of QAM and multi-antenna mapping VNFs (denoted as ‘QAM+antenna mapping’), which can support subframe data fronthaul operations; a fourth VNF decomposition 308 including a set of resource mapping VNF, which may support subframe symbol fronthaul operations; a fifth VNF decomposition 310 including a set of IFFT and cyclic prefix VNFs; and a sixth VNF decomposition 312 including a set of P/S CPRI encoding VNF, which may support either full CPRI fronthaul or compressed CPRI fronthaul operations, which can be provided via possible additional VNF decompositions.

[0083] In various embodiments sets of VNFs associated with PDCP, RLC, MAC, FEC, QAM and antenna mapping functionalities may be associated with user processing (e.g., RAN controller) capabilities. In various embodiments, sets of VNFs associated with resource mapping, IFFT, cyclic prefix and P/S CPRI encoding functionalities may be associated with cell (e.g., RF termination point) processing capabilities.

[0084] Turning to FIG. 4, FIG. 4 is a simplified block diagram illustrating example details associated with one potential embodiment of communication system 10. In particular, FIG. 4 illustrates various elements, frameworks, resources, etc. that can be present within a virtualized RAN architecture. The example details discussed for FIG. 4 are discussed with reference to a two-tiered decomposition architecture, however, it should be understood that the example details discussed for FIG. 4 can be extended to encompass any multi-tiered RAN decomposition architectures as discussed herein.

[0085] FIG. 4 includes RAN 80, RAN orchestration system 14, a given RAN controller 16, a given RF termination point 18, and transport network 20, which may interface with transport management function 22. Also shown in FIG. 4 are UE 12a-12c within RAN 80. RAN orchestration system 14 includes RAN orchestration function 30, VNF manager(s) 32, VIM 34, one or more processor(s) 81 and one or more memory element(s) 82. In various embodiments, one or more processor(s) 81 can be hardware processor(s). Transport management function 22 may include one or more processor(s) 91 and one or more memory element(s) 92. In various embodiments, one or more processor(s) 91 can be hardware processor(s).

[0086] RAN controller 16 can include a VNF framework 42 for a set of one or more VNF 40.1-40.N instantiations and can include NFVI 50. As shown in FIG. 4, each VNF 40.1-40.N instantiation, respectively, can interface with a respective element management system (EMS) 44.1-44.N, which may perform various management functions for each corresponding VNF 40.1-40.N instantiations as directed by VNF manager(s) 32. In some embodiments, each VNF 40.1-40.N instantiation can include a corresponding set of one or more VNF component(s) (VNFC(s)) (not shown). NFVI 50 may provide interconnectivity and infrastructure for interfacing each VNF 40.1-40.N instantiation with virtual resources 56, which may be abstracted from hardware resources 51 via a virtualization layer 55. In various embodiments, virtual resources 56 can include virtual computing 57, virtual storage 58 and virtual network 59 resources. In various embodiments, hardware resources 51 may include computing hardware 52, storage hardware 53 and network hardware 54. Virtualization layer 55 can be used to abstract hardware resources 51 into virtual resources 56 to provide NFVI 50 for the VNF framework 42 for one or more VNF(s) 40.1-40.N and EMS 44.1-44.N, respectively. RAN controller 16 may also include one or more processor(s) 83 and one or more memory element(s) 84. In various embodiments, one or more processors(s) 83 may be hardware processor(s).

[0087] RF termination point 18 can include a VNF framework 62 for a set of one or more VNF 60.1-60.M instantiations and NFVI 70. As shown in FIG. 4, each VNF 60.1-60.M instantiation, respectively each of which can interface with a respective EMS 64.1-64.M, which may perform various management functions for each corresponding VNF 60.1-60.M instantiation as directed by VNF manager(s) 32. In some embodiments, each VNF 60.1-60.M instantiation can include a corresponding set of one or more VNF component(s) (VNFC(s)) (not shown). NFVI 70 may provide interconnectivity and infrastructure for interfacing each VNF 60.1-60.M instantiation with virtual resources 76, which may be abstracted from hardware resources 71 via a virtualization layer 75. In various embodiments, virtual resources 76 can include which may include virtual computing 77, virtual storage 78 and virtual network 79 resources. In various embodiments, hardware resources 71 may include computing hardware 72, storage hardware 73 and network hardware 74. Virtualization layer 75 can be used to abstract hardware resources 71 into virtual resources 76 to provide NFVI 70 for the VNF framework 62 for one or more VNF(s) 60.1-60.M and EMS 64.1-64.M, respectively. RF termination point 18 may also include one or more processor(s) 85 and one or more memory element(s) 86 and includes radio head 19. In various embodiments, one or more processor(s) 85 may be hardware processors.

[0088] Turning to FIGS. 5A-5B, FIGS. 5A-5B are simplified block diagrams 500A-500B illustrating example details associated with example multi-tiered RAN decomposition architectures that can be associated with various potential embodiments of communication system 10.

[0089] Referring to FIG. 5A, FIG. 5A is a simplified block diagram 500A illustrating an example three-tiered RAN decomposition that can be associated with one potential embodiment of communication system 10 in which VNFs for RAN 80 can be further decomposed into sets of VNFs for one or more RAN controller(s) 502, one or more radio aggregator(s) 504 and one or more RF termination point(s) 18. Each of RAN controller(s) 502, radio aggregator(s) 504 and RF termination point(s) 18 can interface with RAN orchestration system 14, which can include RAN orchestration function 30, VNF manager(s) 32 and VIM 34. RAN controller(s) 502 can include a set of one or more VNF(s) 510, which may interface with VNF manager(s) 32 and a NFVI 520, which may further interface with VIM 34 of RAN orchestration system 14 via transport network 20. Radio aggregator(s) 504 can include a set of one or more VNF(s) 530, which may interface with VNF manager(s) 32 and a NFVI 540, which may further interface with VIM 34 of RAN orchestration system 14 via transport network 20. RF termination point(s) 18 including a set of VNF(s) 60 and NFVI 70 can also interface with RAN orchestration system 14 in a manner as described herein. RAN orchestration function 30 can also interface with transport management function 22, as shown in FIG. 1, though this is not illustrated in FIG. 5A in order to illustrate other features of the example three-tiered RAN decomposition.

[0090] Essentially, the example three-tiered RAN decomposition shown in FIG. 5A can provide for a further decomposition of the set of VNF(s) 40 for RAN controller(s) 16, as shown in FIG. 1, into the set of VNF(s) 510 for RAN controller(s) 502 and the set of VNF(s) 530 for radio aggregator(s) 504. In various embodiments, the set of VNF(s) 510 for RAN controller(s) 502 can be associated with one or more higher level operations such as, for example, RRC functionality, application level functionality, S1/X2 signaling and/or protocol signaling and can also be associated with PDCP functionality. In various embodiments, the set of VNF(s) 530 for radio aggregator(s) 504 can be associated with lower link level operations such as, for example, MAC functionality and RLC functionality to support traffic (e.g., user data traffic and control traffic) for one or more RF termination point(s) 18.

[0091] In various embodiments, optimal locations among network transport 20 can be identified at which to instantiate the sets of VNF(s) 510 and 530. In various embodiments, the optimal locations can be the same or different depending on impairments among certain locations of the transport network 20, network equipment capabilities, policies, etc. For example, in some cases, an optimal location for instantiating the set of VNF(s) 530 for a given radio aggregator 504 may be near a given RF termination point 18 or sub-cluster of RF termination points 18 whose traffic it is supporting, while an optimal location for instantiating the set of VNF(s) 510 for a given RAN controller 502 may be based on a larger collection of RF termination points 18 or multiple clusters of RF termination points 18 and corresponding radio aggregators 504 serving traffic for the RF termination points (e.g., located in an approximate center of a cluster of RF termination points). In other cases, for example, different network elements at a same approximate location (e.g., there can be multiple network elements present at a same approximate location) can be identified at which to instantiate the sets of VNF(s) 510 and VNF(s) 530 and their corresponding NFVI.

[0092] Referring to FIG. 5B, FIG. 5B is a simplified block diagram 500B illustrating an example four-tiered RAN decomposition that can be associated with one potential embodiment of communication system 10 in which VNFs for RAN 80 can be further decomposed into sets of VNFs for one or more RAN controller(s) 512, one or more first tier radio aggregator(s) 506, one or more second tier radio aggregator(s) 508 and one or more RF termination point(s) 18. RAN controller(s) 512 can include a set of one or more VNF(s) 514, which may interface with VNF manager(s) 32 and a NFVI 524, which may further interface with VIM 34 of RAN orchestration system 14 via transport network 20. First tier radio aggregator(s) 506 can include a first tier set of one or more VNF(s) 550, which may interface with VNF manager(s) 32 and a NFVI 560, which may further interface with VIM 34 of RAN orchestration system 14 via transport network 20. Second tier radio aggregator(s) 508 can include a second tier set of one or more VNF(s) 570, which may interface with VNF manager(s) 32 and a NFVI 580, which may further interface with VIM 34 of RAN orchestration system 14 via transport network 20.

[0093] In various embodiments, the set of VNF(s) 514 for RAN controller(s) 512 can be associated with one or more higher level operations such as, for example, RRC functionality, application level functionality, S1/X2 signaling and/or protocol signaling. In various embodiments, the first tier set of VNF(s) 550 for first tier radio aggregator(s) 506 can be associated with PDCP functionality and the second tier set of VNF(s) 570 for second tier radio aggregator(s) 508 can be associated with RLC/MAC functionality. Optimal locations among network transport 20 can be identified at which to instantiate sets of VNF(s) 514, 550 and 570, and their corresponding NFVI which can be the same or different for various decompositions, depending on, for example, impairments among certain locations of the transport network 20, network equipment capabilities, policies, etc.

[0094] Thus, in various embodiments, operations for determining an optimized realization for RAN 80 can include, among others: gathering information (e.g., transport network 20 characterizations and/or UE demand information) between various locations of network elements of RAN 80 interconnected among transport network 20; determining a decomposition of operations associated with RAN 80 into particular sets of VNF(s) that can be distributed among one or more locations of network elements of RAN 80 (e.g., RF termination point(18), candidate locations of data centers, servers, etc.) based on one or more orchestration policies and the gathered information; identifying optimal locations at which to instantiate the particular sets of VNF(s) based on one or more orchestration policies and the gathered information (e.g., for particular sets of VNF(s) other than those that are to be instantiated at RF termination point(s) 18); and instantiating the sets VNF(s).

[0095] Turning to FIG. 6A, FIG. 6A is a simplified block diagram 600 illustrating example details that can be associated with one potential embodiment of communication system 10. In particular, FIG. 6A illustrates various candidate locations (LOC 1-LOC 6) at which a particular set of VNF(s) 40 for one or more RAN controller(s) 16 for a particular RAN decomposition can be instantiated among transport network 20 and another location (LOC 7) at which a given RF termination point 18 is deployed. FIG. 6A includes RAN orchestration system 14 including RAN orchestration function 30 and transport network 20, which may interface with transport management function 22. Candidate locations LOC 1-6 can be associated with network elements of RAN 80 interconnected among transport network such as, for example, other RF termination points, data centers, servers, controllers or any other infrastructure that may be provided for RAN 80. RAN 80 is not shown in FIG. 6A in order to illustrate other features of communication system 10. For FIG. 6A, candidate locations LOC 1-6 of network elements and LOC 7 for RF termination point 18, each situated on the perimeter of the dash-dot lined circle representing transport network 20, as well as RAN orchestration system 14 and transport management function 22 are assumed to be interconnected via transport network 20.

[0096] During operation, transport management function 22, through one or more transport network 20 characterizations, may generate one or more table(s) 610 indicating transport network 20 impairments between each location LOC 1-7. Transport network 20 impairments indicated in table(s) 610 (and any other information such as UE demand, etc. that may be gathered by RAN orchestration function) can be used by RAN orchestration function 30 to determine an optimized decomposition of functionality for RAN 80 into the particular set of VNF(s) 40 for one or more RAN controller(s) 16 and a particular set of VNF(s) 60 for RF termination point 18 and to identify optimal location(s) at which to instantiate (e.g., distribute) one or more of the set of VNF(s) 40 for one or more RAN controller(s) 16 from candidate locations LOC 1-6 based on one or more orchestration policies that may be configured for RAN orchestration function 30.

[0097] In one example case, optimal location(s) could be identified based on location(s) of network elements nearest to RF termination point 18. For example, in FIG. 6A, either network elements at candidate locations LOC 1 or LOC 6 could be identified as optimal location(s) at which to instantiate a set of VNF(s) 40 for a RAN controller 16 as they may be nearest to LOC 7 of RF termination point 18. In another example case, optimal location(s) could be identified based on latency/jitter between network elements at candidate locations LOC 1-6 and RF termination point 18. For example, LOC 4 might be determined to have the lowest latency/jitter for transport network interconnections with RF termination point 18, in which case a set of VNF(s) 40 for a RAN controller 16 could be instantiated among network elements located at candidate location LOC 4. It should be understood that one or more optimal location(s) for instantiation of one or more set(s) of VNF(s) 40 for RAN controller(s) 16 can be identified based on any criteria, location information, characterization information, UE demand, etc. for one or more orchestration policies that may be configured for RAN orchestration function 30.

[0098] Turning to FIG. 6B, FIG. 6B illustrates example details that may be associated with FIG. 6A in accordance with one embodiment of communication system 10. FIG. 6B illustrates an example table 610.1 including a table of impairments 612 that can be generated for a characterization of impairments that may be present between each location LOC 1-7. For example table 610.1, a bidirectional symmetry is assumed for impairments between each location (e.g., impairments for traffic flowing from LOC 1 toward LOC 2 [I_1,2] is the same as impairments for traffic flowing from LOC 2 towards LOC 1 [I_2,1] such that I_1,2=I_2,1), which can reduce the number of characterizations generated for example table 610.1 as are illustrated by the ‘*’ indications. Note also no characterizations may be made between a particular location and itself, also illustrated by the ‘*’ indications. However, the assumption could be removed in which case example table 610.1 could be generated to include different characterizations for different directions of traffic (e.g., uplink versus downlink) flowing between LOC 1-7.

[0099] Transport management function 22 may, in some embodiments, monitor impairments for transport network 20 in relation to SLAs configured for interconnected locations of network elements associated with RAN 80 without needing knowledge of what types of network elements (e.g., RF termination points, data centers, etc.) may be associated with each interconnected location. Transport management function may be configured with one or more SLAs in order to measure and monitor certain impairments between various locations.

[0100] In some embodiments, each impairment 612 can be generated as an indexed list of impairments, as illustrated by example impairment I_N,M. Example impairment I_N,M includes a set of indexed impairments 614 (e.g., {I.1_N,M, I.2_N,M, I.3_N,M, . . . I.X_N,M}). Each indexed impairment 614 may be associated with a particular impairment (e.g., throughput, delay, jitter, loss, etc.) for any number of impairments that a network operator and/or service provider desires to characterize. In other embodiments, rather than include an indexed list of impairments between each location, particular tables can be generated to describe particular impairments (e.g., a throughput table, a latency/jitter table, a loss table, etc.). Thus, any number of tables can be generated to describe impairments among locations of a given transport network in accordance with various embodiments as described herein.

[0101] Turning to FIG. 7, FIG. 7 is a simplified block diagram 700 illustrating example details that can be associated with one potential embodiment of communication system 10. In particular, FIG. 7 provides example details associated with scaling RAN decompositions among multiple candidate locations (LOC 1-LOC 3) at which a particular set of VNF(s) 40 can be instantiated for one or more RAN controller(s) 16 for a particular RAN decomposition and locations (LOC 4-8) at which each of an RF termination point 18.1-18.5, respectively, is deployed.

[0102] FIG. 7 includes RAN orchestration system 14 including RAN orchestration function 30 and transport network 20, which may interface with transport management function 22. Candidate locations LOC 1-3 can be associated with any network elements of RAN 80 interconnected among transport network 20 such as, for example, other RF termination points, data centers, servers, controllers, or any other infrastructure that may be provided for RAN 80. RAN 80 is not shown in FIG. 7 in order to illustrate other features of communication system 10. For FIG. 7, candidate locations LOC 1-2 and LOC 4-8 for RF termination points 18.1-18.5, respectively, each situated on the perimeter of the dash-dot lined circle representing transport network 20, and candidate location LOC 3 within the dash-dot circle representing transport network 20, as well as RAN orchestration system 14 and transport management function 22 are all assumed to be interconnected via transport network 20.

[0103] During operation, transport management function 22, through one or more transport network 20 characterizations, may generate one or more table(s) 710 indicating transport network 20 impairments between each location LOC 1-8.

[0104] In various embodiments, transport network impairments indicated table(s) 710 (and any other information such as UE demand, etc. that may be gathered by RAN orchestration function) can be used by RAN orchestration function 30 to determine an optimized decomposition of network functionality for RAN 80 into the particular set of VNF(s) 40 for one or more RAN controller(s) 16 and a particular set of VNF(s) 60 for each RF termination point 18.1-18.5 and to identify optimal location(s) at which to instantiate one or more of the particular set(s) of VNF(s) 40 for one or more RAN controller(s) 16 from candidate locations LOC 1-3 based on one or more orchestration policies that may be configured for RAN orchestration function 30.

[0105] Consider one example case in which a characterization of transport network 20 impairments indicates ideal or near-ideal latency/jitter for candidate location LOC 3. As candidate location LOC 3 may be at an approximate geographic center among LOC 4-8 for RF termination points 18.1-18.5 and may have ideal or near-ideal latency/jitter between each RF termination point 18.1-18.5, LOC 3 might be identified as an optimal location for instantiating one particular set VNF(s) 40 for one RAN controller 16 to manage RF termination points 18.1-18.5.

[0106] However, consider another example case in which characterization of transport network 20 impairments included in table(s) 710 indicates non-ideal performance for candidate location LOC 3 and ideal, near-ideal or sub-ideal (or some variation thereof better than non-ideal performance) for candidate locations LOC 1 and LOC 2. In one optimized RAN 80 realization, for example, RAN orchestration function 30 may identify candidate location LOC 2 as an optimal location at which to instantiate a first instance of the particular set of VNF(s) 40 for a first RAN controller 16 to manage RF termination points 18.3 and 18.4 (e.g., based on candidate location LOC 2 being located in a geographical proximity nearest to RF termination points 18.3 and 18.4 and having better than non-ideal latency/jitter between the RF termination points). RAN orchestration function 30 may further, for example, identify candidate location LOC 1 as an optimal location at which to instantiate a second instance of the particular set of VNF(s) 40 for a second RAN controller 16 to manage RF termination points 18.1, 18.2 and 18.5 (e.g., based on candidate location LOC 2 being located in a geographical proximity nearest to RF termination points 18.1, 18.2 and 18.5 and having better than non-ideal latency jitter between the RF termination points). Thus, multiple instantiations of particular sets of VNF(s) 40 for multiple RAN controllers 16 can be distributed throughout RAN 80.

[0107] However, consider yet another example case in which network element capabilities for network elements located at candidate locations LOC 3 and LOC 2 indicates that network elements at these candidate locations are incapable of supporting various RAN controller 16 functionality for the particular set of VNF(s) 40. Thus, in one optimized RAN 80 realization, RAN orchestration function 30 may identify candidate location LOC 1 as an optimal location at which to instantiate the particular set of VNF(s) 40 for RAN controller 16 to manage all of RF termination points 18.1-185.

[0108] Consider yet another example in which UE demand at RF termination point 18.4 is substantially higher than UE demand for any other RF termination point. Thus, in one optimized RAN 80 realization, RAN orchestration function may identify candidate location LOC 2 as an optimal location at which to instantiate the particular set of VNF(s) 40 for RAN controller 16.

[0109] Accordingly, as illustrated in the above example cases any distribution of any particular set of VNF(s) 40 for any number of RAN controller(s) 16 can be realized for any decomposition of RAN 80 for various characterizations, network element capabilities, UE demand, combinations thereof or the like as discussed for various embodiments described herein. As discussed herein, communication system 10 may also facilitate different decompositions of VNFs for RAN 80, which can be realized through two-tiered or three-tiered decomposition architectures for different network characterizations, network element capabilities, UE demand, etc. In various embodiments, distributions of particular sets of VN Fs for three-tiered RAN decompositions can also vary depending on network characterizations, network element capabilities, UE demand, etc. for one or more orchestration policies that may be configured for RAN orchestration function 30, as discussed below for FIGS. 8-9.

[0110] Turning to FIG. 8, FIG. 8 is a simplified block diagram 800 illustrating example details that can be associated with one potential embodiment of communication system 10. In particular, FIG. 8 illustrates various candidate locations LOC 1-3 at which a particular set of VNF(s) 510 can be instantiated for one or more RAN controller(s) 502 and/or at which a particular set of VNF(s) 530 can be instantiated for one or more radio aggregator(s) 504 among network elements of RAN 80 interconnected by transport network 20 for a particular RAN 80 decomposition. RAN 80 is not shown in FIG. 8 in order to illustrate other features of communication system 10.

[0111] FIG. 8 includes RAN orchestration system 14 including RAN orchestration function 30 and transport network 20, which may interface with transport management function 22, and locations LOC 4-7 at which each of a number of RF termination point 18.1-18.4, respectively, is deployed. Candidate locations LOC 1-3 can be associated with any network elements of RAN 80 interconnected among transport network 20 such as, for example, other RF termination points, data centers, controllers, or any other infrastructure provided for RAN 80. For FIG. 8, candidate locations LOC 1-2 and LOC 4-7 for RF termination points 18.1-18.4, respectively, each situated on the perimeter of the dash-dot lined circle representing transport network 20, candidate location LOC 3 within the dash-dot circle represent transport network 20, as well as RAN orchestration system 14 and transport management function 22 are assumed to be interconnected via transport network 20.

[0112] During operation, transport management function 22, through one or more transport network 20 characterizations, may generate one or more table(s) 810 indicating transport network impairments between each location LOC 1-7 interconnected among transport network 20.

[0113] Transport network impairments indicated in table(s) 810 (and any other information such as UE demand, etc. that may be gathered by RAN orchestration function 30) can be used by RAN orchestration function 30 to determine an optimized decomposition of network functionality for RAN 80 into a particular set of VNF(s) 510 for one or more RAN controller(s) 502, a particular set of VNF(s) 530 for one or more radio aggregator(s) 504 and a particular set of VNF(s) 60 for each RF termination point 18.1-18.4 and to identify optimal location(s) at which to instantiate one or more of the particular set of VNF(s) 510 for one or more RAN controller(s) 502 and one or more of the particular set of VNF(s) 530 for one or more radio aggregator(s) 504 from candidate locations LOC 1-3 based on one or more orchestration policies that may be configured for RAN orchestration function 30.

[0114] Consider one example case in which, based on a given characterization of transport network 20 impairments included in table(s) 810 and/or UE demand, RAN orchestration function 30 identifies candidate location LOC 3 as an optimal location at which to instantiate the particular set of VNF(s) 510 for one RAN controller 502 to perform higher level (e.g., RRC, protocol signaling, etc.) operations for RF termination points 18.1-18.4; identifies candidate location LOC 2 as an optimal location at which to instantiate a first instance of the particular set of VNF(s) 530 for a first radio aggregator 504 to perform lower level (e.g., PDCP, RLC, MAC) operations for RF termination points 18.2 and 18.3; and identifies candidate location LOC 1 as an optimal location at which to instantiate a second instance of the particular set of VNF(s) 530 for a second radio aggregator 504 to perform lower level operations for RF termination points 18.1 and 18.4.

[0115] Accordingly, for one or more embodiments as discussed herein, one or more optimal location(s) for instantiation of a particular set of VNF(s) 510 for one or more RAN controller(s) 502 and/or for instantiation of a particular set of VNF(s) 530 for one or more radio aggregator(s) 504 can be identified based on any criteria (e.g., network element capabilities), characterization information, UE demand, etc. for one or more orchestration policies that may be configured for RAN orchestration function 30.

[0116] Turning to FIG. 9, FIG. 9 is a simplified block diagram 900 illustrating example details that can be associated with one potential embodiment of communication system 10. In particular, FIG. 9 illustrates various candidate locations LOC 1-9 at which a particular set of VNF(s) 514 for one or more RAN controller(s) 512; at which a particular first tier set of VNF(s) 550 for one or more first tier radio aggregator(s) 506; and/or at which a particular second tier set of VNF(s) 570 for one or more second tier radio aggregator(s) 508 can be instantiated among transport network 20 for a particular RAN decomposition. Candidate locations LOC 1-9 are represented in FIG. 9 as generic network elements in order to illustrate various complexities that can be realized for various decompositions that can be facilitated by communication system 10. RAN 80 is not shown in FIG. 9 in order to illustrate other features of communication system 10.

[0117] FIG. 9 includes RAN orchestration system 14 including RAN orchestration function 30 and transport network 20, which may interface with transport management function 22, and locations LOC 10-19 at which each of a number of RF termination points 18.1-18.10, respectively, is deployed. RF termination points 18.1-18.10 are illustrated as generic towers with associated generic network elements. Candidate locations LOC 1-9 can be associated with any network elements of RAN 80 interconnected among transport network 20 such as, for example, other RF termination points, data centers, servers, controllers, or any other infrastructure that may be provided for RAN 80.

[0118] For FIG. 9, candidate locations LOC 1, LOC 2, LOC 4, LOC 6, LOC 7 and LOC 10-19 for RF termination points 18.1-18.10, respectively, each situated on the perimeter of the dash-dot lined circle representing transport network 20, candidate locations LOC 3, LOC 8 and LOC 9 within the dash-dot lined circle representing transport network 20, as well as RAN orchestration system 14 and transport management function 22 are assumed to be interconnected via transport network 20. In one example case for FIG. 9, RF termination points 18.1 and 18.6-18.10 may be assumed to be associated with a first cluster of RF termination points interconnected among transport network 20 for a first given geographic area and RF termination points 18.2-18.5 may be assumed to be associated with a second cluster of RF termination points interconnected among transport network 20 for a second geographic area.

[0119] During operation, transport management function 22, through one or more transport network 20 characterizations, may generate one or more table(s) 910 indicating transport network impairments between each location LOC 1-19 interconnected among transport network 20.

[0120] Transport network impairments indicated in table(s) 910 (and any other information such as UE demand, etc. that may be gathered by RAN orchestration function 30) can be used by RAN orchestration function 30 to determine an optimized decomposition of network functionality for RAN 80 into the particular set of VNF(s) 514 for one or more RAN controller(s) 512, the particular first tier set of VNF(s) 550 for one or more first tier radio aggregator(s) 506, the particular second tier set of VNF(s) 570 for one or more second tier radio aggregator(s) 508 and a particular set of VNF(s) 60 for each RF termination point 18.1-18.10 and to identify an optimal location(s) at which to instantiate the particular set of VNF(s) 514 for RAN controller(s) 512, the particular first tier set of VNF(s) 550 for one or more first tier radio aggregator(s) 506 and the particular second tier set of VNF(s) 570 for one or more second tier radio aggregator(s) 508 from candidate locations LOC 1-9 based on one or more orchestration policies that may be configured for RAN orchestration function 30.

[0121] Consider one example case in which, based on a given characterization of transport network 20 impairments included in table(s) 910 and/or UE demand, RAN orchestration function 30 identifies candidate location LOC 9 as an optimal location (e.g., based on being at an approximate geographic center among LOC 10-19 for RF termination points 18.1-18.10) at which to instantiate the particular set of VNF(s) 514 for one RAN controller 512 to perform higher level (e.g., RRC, S1/X2 signaling, protocol signaling, etc.) operations for RF termination points 18.1-18.10. RAN orchestration function 30 can further identify candidate location LOC 8 as an optimal location at which to instantiate a first instance of the particular first tier set of VNF(s) 550 for one first tier radio aggregator 506 to perform PDCP operations for the first cluster of RF termination points 18.1 and 18.6-18.10 and can identify candidate location LOC 3 as an optimal location at which to instantiate a second instance of the particular first tier set of VNF(s) 550 for another first tier radio aggregator 506 to perform PDCP operations for the second cluster of RF termination points 18.2-18.5.

[0122] In one example, RAN orchestration function 30 may further identify each of candidate locations LOC 1, LOC 6 and LOC 7 as optimal locations at which to instantiate respective instances of the particular second tier set of VNF(s) 570 for three second tier radio aggregators 508 or, in another example, may identify any subset of these locations as optimal locations at which to instantiate the particular second tier set of VNF(s) 570 for one or two second tier radio aggregator(s) 508. For example, RAN orchestration function 30 may identify candidate location LOC 7 as an optimal location at which to instantiate one instance of the particular second tier set of VNF(s) 570 for a single, second tier radio aggregator 508 to serve RF termination points 18.1 and 18.6-18.10 for the first cluster.

[0123] In another example, RAN orchestration function 30 could identify candidate location LOC 1 as an optimal location at which to instantiate one instance of the particular second tier set of VNF(s) 570 for a single, second tier radio aggregator 508 to serve RF termination points 18.1 and 18.10 (e.g., RF termination points 18.1 and 18.10 could have increased UE demand compared to other RF termination points in the first cluster) and could identify candidate location LOC 66 as an optimal location at which to instantiate another instance of the particular second tier set of VNF(s) 570 for another second tier radio aggregator 508 to serve RF termination points 18.6-18.9 (e.g., which may have lower UE demand). Similarly, RAN orchestration function 30 can distribute the particular second set of VNF(s) 570 across one or more candidate locations LOC 2, LOC 4 and LOC 5 for the second cluster of RF termination points 18.2-18.5 based on UE demand in addition to or separate from transport network 20 characterizations.

[0124] Thus, as illustrated in the various examples described for FIGS. 6A-6B and 7-9, communication system 10, via RAN orchestration function 30 can facilitate the dynamic realization of different RAN decompositions for a multitude of orchestration policies, transport network characterizations and/or UE demand.

[0125] Turning to FIG. 10, FIG. 10 is a simplified block diagram illustrating example details associated with various operations that can be performed to facilitate dynamic RAN orchestration in accordance with one potential embodiment of communication system 10. FIG. 10 includes RAN 80, RAN Orchestration System 14, transport network 20 and transport management function 22. RAN Orchestration System 14 includes RAN orchestration function 30, VNF manager(s) 32 and VIM 34.

[0126] In at least one embodiment, communication system 10, as shown at 1002, may continually monitor transport network 20 impairments (e.g., through characterizations of transport network 20 generated via transport management function 22 and communicated to RAN orchestration function 30) and/or may continually monitor UE demand within RAN 80.

[0127] At any time, as shown at 1004, transport management function 22 may generate characterizations of impairments present between various locations of network elements of RAN 80 (e.g., locations of one or more RF termination points and locations of other network elements) interconnected via transport network 20 and may communicate the impairments to RAN orchestration function 30. At 1006, RAN orchestration function 30 may determine a decomposition of RAN 80 operations into sets of VNF(s), for example, sets of VNF(s) 40, 60, 510, 514, 530, 550, 570 or any other sets of VNF(s) for any other decompositions that may be configured for RAN orchestration function 30 for one or more orchestration policies based on the characterization of impairments received from transport management function 22 and/or UE demand. Further at 1006, RAN orchestration function may identify a distribution of the determined sets of VNF(s) among one or more candidate location(s) throughout RAN 80 (e.g., for one or more candidate location(s) for sets of VNF(s) not associated with RF termination points) based on the characterization of impairments received from transport management function 22 and/or UE demand in relation to one or more orchestration policies.

[0128] At 1008A, RAN orchestration function may command VIM 34 to allocate virtualization enablers, resources, etc. that can be dedicated to NFVI for the sets of VNF(s) instantiated at various locations (e.g., at one or more identified candidate location(s) and at locations of RF termination point(s) 18). The allocation can be performed at can be performed by VIM 34 at 1010. At 1008B, RAN orchestration function may command VNF manager(s) 32 to instantiate the sets of VNF(s) at various locations (e.g., identified candidate locations and location(s) of RF termination point(s) 18). At 1012, VNF manager(s) 32 may instantiate the sets of VNF(s).

[0129] Communication system 10 may be continuing to monitor transport network 20 impairments (e.g., through characterizations of transport network 20 generated via transport management function 22 and communicated to RAN orchestration function 30) and/or UE demand among various locations within RAN 80 at 1002. In some embodiments, as shown at 1014, RAN orchestration function 30 may provide RAN feedback information to transport management function 22, which may include decomposition information associated with the sets of VNFs currently instantiated for a given decomposition, location information associated with the distribution of the sets of VNF(s) at various locations throughout RAN 80 and/or other information associated with operation of RAN 80.

[0130] Turning to FIG. 11, FIG. 11 is a simplified flow diagram illustrating example operations 1100 that can be associated with providing dynamic RAN orchestration in accordance with one potential embodiment of communication system 10.

[0131] At any time, transport management function 22 may generate a characterization of impairments between one or more locations of network elements associated with RAN 80 (e.g., a fronthaul characterization) interconnected via transport network 20. Thus, in some embodiments, operations can begin at 1102A in which RAN orchestration function may receive a characterization of impairments identifying impairments between locations of network elements associated with RAN 80 that are interconnected via transport network 20. In various embodiments, network elements associated with RAN 80 can include one or more RF termination point(s) (e.g., RF termination point(s) 18) one or more data centers, servers, controllers, combinations thereof or the like that can be interconnected via transport network 20 to facilitate operations associated with RAN 80. In some embodiments, the characterization of impairments can be one or more table(s) identifying impairments (e.g., throughput, latency/jitter, loss, etc.) between the one or more locations.

[0132] In some embodiments, as shown at 1102B, RAN orchestration function 30 can determine a change in UE demand (e.g., demand associated with one or more UE 12a-12c) among one or more locations within the RAN, which can trigger subsequent operations to determine a decomposition and/or distribution of set(s) of VNF(s) among various locations of the RAN. In various embodiments, a change in UE demand can be determined by monitoring UE connectivity at one or more RF termination point locations, monitoring UE traffic flows across one or more network elements, monitoring UE sessions across one or more network elements, combinations thereof or the like. In various embodiments operations 1102A and 1102B can be performed in parallel.

[0133] At 1104, the operations can include RAN orchestration function 30 determining a decomposition of one or more operations associated with RAN 80 into sets of one or more VNF(s) to execute the one or more operations. In some embodiments, the determining can include comparing a characterization of impairments received at 1102A to one or more orchestration policies configured for RAN orchestration function 30 in order to determine particular sets of VNF(s) for a particular decomposition. In still some embodiments, the determining can include comparing a characterization of impairments received at 1102 in combination with a change in UE demand to one or more orchestration policies in order to determine particular sets of VNF(s) for a particular decomposition. In still some embodiments, the determining can include comparing the changes in UE demand to one or more orchestration policies in order to determine particular sets of VNF(s) for a particular decomposition.

[0134] In some embodiments, the determining can include determining a decomposition into a first set of one or more VNF(s) associated with first operations to be executed for one or more RAN controllers (e.g., RAN controller(s) 16) and a second set of VNFs associated with operations to be executed for the at least one RF termination point (e.g., a given RF termination point 18).

[0135] In still some embodiments, the determining can include determining a decomposition into a first set of VNFs associated with first operations to be executed for one or more RAN controller(s) 502, a second set of VNFs associated with second operations to be executed for one or more radio aggregators (e.g., radio aggregator(s) 504 and a third set of VN Fs associated with operations to be executed for the at least one RF termination point (e.g., a given RF termination point 18). In still some embodiments, the determining can include determining a decomposition into a set of VNF(s) 514 associated with first higher level operations to be executed for one or more RAN controller(s) 512, a first tier set of VNF(s) associated with one or more first tier operations (e.g., PDCP operations) to be executed for one or more first tier radio aggregator(s) (e.g., first tier radio aggregator(s) 506) and a second tier set of VNF(s) associated with one or more second tier operations (e.g., RLC/MAC operations) to be executed for one or more second tier radio aggregator(s) (e.g., second tier radio aggregator(s) 508).

[0136] At 1106, the operations can include identifying one or more optimal location(s) at which to instantiate (e.g., distribute) one or more particular set(s) of VNF(s) that are associated with particular operations that are to be executed among one or more candidate location(s) of network elements other than at the location(s) of one or more RF termination point(s) based on the characterization of impairments and/or UE demand in relation to one or more orchestration policies configured for RAN orchestration function 30. In some embodiments, the identifying can be based on the characterization of impairments received in 1102A and/or the determination of a change in UE demand determined at 1102B compared to orchestration policies configured with distribution criteria indicating impairment conditions required for certain distributions among various locations. In still some embodiments, the identifying can be based on network element capabilities for network elements located at various locations, which can be configured for certain orchestration policies.

[0137] At 1108, the operations can include instantiating the one or more particular set(s) of VNF(s) and corresponding NFVI at the one or more identified optimal location(s) of network elements associated with the RAN. At 1110, the operations can include instantiating one or more other set(s) of VNF(s) and corresponding NFVI at the locations of each of one or more RF termination points within the RAN and the operations may end. In some embodiments, as shown at 1112, RAN orchestration function 30 can generate RAN feedback information to communicate to transport management function 22.

[0138] Regarding the internal structure of communication system 10, appropriate software and/or hardware, physical and/or virtualized is being provisioned in RAN orchestration system 14, including RAN orchestration function 30, VNF manager(s) 32 and VIM 34; transport management function 22; one or more RAN controller(s) 16 and one or more RF termination point(s) 18 [as shown in FIGS. 1 and 4]; one or more RAN controller(s) 502 and one or more radio aggregator(s) 504 [as shown in FIG. 5A]; one or more RAN controller(s) 512, one or more first tier radio aggregator(s) 506 and one or more second tier radio aggregator(s) 508 [as shown in FIG. 5B] to facilitate dynamic RAN orchestrations for various virtualized RAN 80 architectures in a network environment (e.g., for networks such as those illustrated in FIGS. 1, 4, 5A-5B, 6A and 7-9). Note that in certain examples, certain storages can be consolidated with memory elements (or vice versa), or the storage can overlap/exist in any other suitable manner.

[0139] In one example implementation, RAN orchestration system 14, including RAN orchestration function 30, VNF manager(s) 32 and VIM 34; transport management function 22; one or more RAN controller(s) 16 and one or more RF termination point(s) 18 [e.g., as shown in FIGS. 1 and 4]; one or more RAN controller(s) 502 and one or more radio aggregator(s) 504 [as shown in FIG. 5A] and one or more RAN controller(s) 512, one or more first tier radio aggregator(s) 506 and one or more second tier radio aggregator(s) 508 [as shown in FIG. 5B] are network elements, which are meant to encompass network appliances, servers, routers, switches, gateways, bridges, loadbalancers, firewalls, processors, modules, or any other suitable device, component, element, or object operable to exchange information that facilitates or otherwise helps coordinate dynamic RAN orchestration operations, as outlined herein. In other embodiments, these operations and/or features may be provided external to these elements, or included in some other network device to achieve this intended functionality. Alternatively, one or more of these elements can include software (or reciprocating software) that can coordinate in order to achieve the operations and/or features, as outlined herein. In still other embodiments, one or more of these devices may include any suitable algorithms, hardware, software, components, modules, interfaces, or objects that facilitate the operations thereof. This may be inclusive of appropriate algorithms and communication protocols that allow for the effective exchange of data or information.

[0140] Each of RAN orchestration system 14, including RAN orchestration function 30, VNF manager(s) 32 and VIM 34; transport management function 22; one or more RAN controller(s) 16 and one or more RF termination point(s) 18 [as shown in FIGS. 1 and 4]; one or more RAN controller(s) 502 and one or more radio aggregator(s) 504 [as shown in FIG. 5A]; one or more RAN controller(s) 512; one or more first tier radio aggregator(s) 506 and one or more second tier radio aggregator(s) 508 [as shown in FIG. 5B] can include one or more memory elements [e.g., as shown in FIG. 4] for storing information to be used in achieving the dynamic RAN orchestration operations, as outlined herein. Additionally, each of these devices may include one or more processors, including hardware processors, multi-core processors, etc. that can execute software or algorithms to perform dynamic RAN orchestration activities as discussed in this Specification. These devices may further keep information in any suitable memory element [e.g., random access memory (RAM), read only memory (ROM), an erasable programmable read only memory (EPROM), application specific integrated circuit (ASIC), etc.], software, hardware, or in any other suitable component, device, element, or object where appropriate and based on particular needs. Any of the memory items discussed herein should be construed as being encompassed within the broad term ‘memory element’.

[0141] Information being tracked or sent to RAN orchestration system 14, including RAN orchestration function 30, VNF manager(s) 32 and VIM 34; transport management function 22; one or more RAN controller(s) 16 and one or more RF termination point(s) 18 [as shown in FIGS. 1 and 4]; one or more RAN controller(s) 502 and one or more radio aggregator(s) 504 [as shown in FIG. 5A] and/or one or more RAN controller(s) 512, one or more first tier radio aggregator(s) 506 and one or more second tier radio aggregator(s) 508 [as shown in FIG. 5B] could be provided in any database, register, control list, cache, or storage structure: all of which can be referenced at any suitable timeframe. Any such storage options may be included within the broad term ‘memory element’ as used herein. Similarly, any of the potential processing elements, modules, and machines described herein should be construed as being encompassed within the broad term ‘processor’. Each of the network elements and user equipment (e.g., mobile nodes) can also include suitable interfaces for receiving, transmitting, and/or otherwise communicating data or information in a network environment.

[0142] Note that in certain example implementations, the dynamic RAN orchestration operations as outlined herein may be implemented by logic encoded in one or more tangible media, which may be inclusive of non-transitory media (e.g., embedded logic provided in an ASIC, in digital signal processing (DSP) instructions, software [potentially inclusive of object code and source code] to be executed by a processor, or other similar machine, etc.). In some of these instances, memory elements [e.g., as shown in FIG. 4] can store data used for the operations described herein. This includes the memory elements being able to store software, logic, code, or processor instructions that are executed to carry out the activities described herein. A processor can execute any type of instructions associated with the data to achieve the operations detailed herein. In one example, the processors [e.g., as shown in FIG. 4] could transform an element or an article (e.g., data) from one state or thing to another state or thing. In another example, the activities outlined herein may be implemented with fixed logic or programmable logic (e.g., software/computer instructions executed by a processor) and the elements identified herein could be some type of a programmable processor, programmable digital logic (e.g., a field programmable gate array (FPGA), a digital signal processor (DSP), an EPROM, EEPROM) or an ASIC that includes digital logic, software, code, electronic instructions, or any suitable combination thereof.

[0143] Note that in this Specification, references to various features (e.g., elements, structures, modules, functions, frameworks, resources, components, steps, operations, characteristics, etc.) included in ‘one embodiment’, ‘example embodiment’, ‘an embodiment’, ‘another embodiment’, ‘certain embodiments’, ‘some embodiments’, ‘various embodiments’, ‘other embodiments’, ‘alternative embodiment’, and the like are intended to mean that any such features are included in one or more embodiments of the present disclosure, but may or may not necessarily be combined in the same embodiments. Note also that a module, function or engine as referred to herein this Specification, can be inclusive of an executable file comprising instructions that can be understood and processed on a computer, and may further include library modules, functions or engines loaded during execution, object files, system files, hardware logic, software logic, or any other executable modules, functions or engines.

[0144] It is also important to note that the operations and steps described with reference to the preceding FIGURES illustrate only some of the possible scenarios that may be executed by, or within, the system. Some of these operations may be deleted or removed where appropriate, or these steps may be modified or changed considerably without departing from the scope of the discussed concepts. In addition, the timing of these operations may be altered considerably and still achieve the results taught in this disclosure. The preceding operational flows have been offered for purposes of example and discussion. Substantial flexibility is provided by the system in that any suitable arrangements, chronologies, configurations, and timing mechanisms may be provided without departing from the teachings of the discussed concepts.

[0145] Note that with the examples provided above, as well as numerous other examples provided herein, interaction may be described in terms of one, two, three, or four network elements. However, this has been done for purposes of clarity and example only. In certain cases, it may be easier to describe one or more of the functionalities by only referencing a limited number of network elements. It should be appreciated that communication system 10 (and its teachings) are readily scalable and can accommodate a large number of components, as well as more complicated/sophisticated arrangements and configurations. Accordingly, the examples provided should not limit the scope or inhibit the broad teachings of communication system 10 as potentially applied to a myriad of other architectures.

[0146] Although the present disclosure has been described in detail with reference to particular arrangements and configurations, these example configurations and arrangements may be changed significantly without departing from the scope of the present disclosure. For example, although the present disclosure has been described with reference to particular communication exchanges involving certain network access and protocols, communication system 10 may be applicable to other exchanges or routing protocols. Moreover, although communication system 10 has been illustrated with reference to particular elements and operations that facilitate operations described herein, these elements, and operations may be replaced by any suitable architecture or process that achieves the intended functionality of communication system 10.

[0147] Numerous other changes, substitutions, variations, alterations, and modifications may be ascertained to one skilled in the art and it is intended that the present disclosure encompass all such changes, substitutions, variations, alterations, and modifications as falling within the scope of the appended claims. In order to assist the United States Patent and Trademark Office (USPTO) and, additionally, any readers of any patent issued on this application in interpreting the claims appended hereto, Applicant wishes to note that the Applicant: (a) does not intend any of the appended claims to invoke paragraph six (6) of 35 U.S.C. section 112 as it exists on the date of the filing hereof unless the words “means for” or “step for” are specifically used in the particular claims; and (b) does not intend, by any statement in the specification, to limit this disclosure in any way that is not otherwise reflected in the appended claims.