Patent ID: 12212361

DETAILED DESCRIPTION OF EMBODIMENTS

FANS is a technique defined and standardized by the Broadband Forum (BBF) that allows the access network to be virtualized so that it would be shared by multiple service providers. There are several gaps in the technical standards as to how modern SDN/NFV principles can be applied to transport slices and management of the slice resources within the access network architectures. These sliced transport access networks could be useful building blocks for enabling advanced 5G wireless and broadband services across the various industry verticals (e.g., eMBB, URLLC, MIoT, CV2X, or others).

Industry has witnessed a passive optical network (PON) technology transformation over the last two decades, from Gigabit PON (G-PON) technology to most recently the XGS-PON (10 Gigabit Symmetrical PON) technology. XGS-PON technology has attracted attention to drive the demands of enterprise, residential, and wholesale premium broadband services. XGS-PON provides a building block of the mobile xHaul (x means front, mid, or back haul) network architecture as it provides the fastest means of transporting massive amounts of 5G user data, that belongs to a specific slice, from the next generation disaggregated radio access networks simultaneously operating across low, mid, and high spectrum bands. Although other types of PON such as NG-PON2 exist today, they are not as cost-effective as XGS-PON and in turn drive the total cost of ownership for a service provider.

In an SD-CPON architecture, each optics port within the OLT could be configured as a combo (G-PON and/or XGS-PON) port, which then determines the amount of bi-directional data that this port can carry. Such a port could be split across multiple users/homes/enterprises via an all-optical distribution network depending on the coverage (range), density and end-user capacity requirements set by the operator. Each port could be a single slice, or a group of ports combined to form a slice with unique identities with port-to-slice mapping that needs to be maintained in the slice controller. Such transport network slice level mapping could be exposed via an open standards application programming interface (API) to cross-domain slicing orchestrators to ensure there is E2E integrity in the overall slicing mapping, optimal allocation and utilization of resources, slice functionality, performance, and delivery of a superior end-user experience.

The SD-CPON OLT could be deployed in a distributed or centralized model based on the operator-specific requirements. In a distributed model, the containerized software with its slicing control and management microservices can be co-resident with the hardware whereas in a centralized model the software could be deployed in any cloud environment with suitable adapters providing connectivity to the remote physical OLT hardware. Lack of effective coordination and cooperation strategies between mobility and transport slicing solutions would pose a major risk to infrastructure as well as service providers in designing and developing next-generation broadband access network architectures. Such designs can easily become complex in terms of interworking; prohibitively expensive in terms of their installations, operations, and management; and not conducive to their seamless evolution. Hence, there is a need for an intelligent means of defining, mapping, monitoring, and controlling the selection of slices within the SD-CPON transport network so that this can enable cooperative E2E slicing as well as dynamic pairing across the cross-domain radio access and core networks resulting in an enhanced shared network infrastructure for service providers that can deliver desired performance.

The XGS-PON standard features a 10 Gbps symmetrical data delivery option that enables service providers to skip the non-symmetrical versions of PON technologies such as the G-PON/XG-PON. This technology operates over a downstream wavelength of 1,577 nm and an upstream wavelength of 1,270 nm, which allows compatibility to operate over the same optical distribution network with legacy G-PON that uses a wavelength of 1,490 nm in downstream and 1,310 nm in upstream.

The SD-CPON platform enables the OLT to operate on XGS-PON/G-PON/XGS-PON+G-PON technologies on a single PON port and distribute the workloads to the network termination endpoints. Such an architecture gives flexibility to the service providers via software intelligence layer to adapt to the next-generation of PON technologies as well as serve a variety of customers, e.g., residential, enterprise and wholesale, with varying applications, services, and quality of service (QoS).

With advances in 5G technologies including software defined and disaggregated radio access and core networking functions embracing cloud native deployments, the ultra high-speed mobility workloads need to be transported effectively with minimal transport delays. The availability of multiple spectrum bands with enormous channel bandwidths drives the need for XGS-PON solutions to carry the multi-Gbps data streams between the radio access and core functions hosted in cloud data centers.

In order to provide enhanced 5G mobile broadband services deployed across a large geographic area, multiple cell sites have to be deployed to cover outdoor and indoor environments. These cell sites may have varying levels of transport requirements based on spectrum allocations in that area. The SD-CPON platforms are an ideal choice for 5G transport as they could be plugged in as xHaul deployment models to drive massive adoption of cost-effective O-RAN solutions. In addition to carrying the 5G workloads, there could be customers in the same area that may require dedicated multi-Gbps symmetrical speeds for premium residential, enterprise, and wholesale services. Deploying parallel transport network solutions to meet the disparate needs of mobility and fixed wireline workloads will be costly and extremely difficult to operate, and will potentially incur losses on their ROI.

With 5G deployments spanning across low, mid, and high frequency bands, there could be a variety of deployment models based on a given market serving area, spectrum availability, density, capacity, and services to be supported. Deep fiber fed SD-CPON technologies are a means of delivering cost-effective transport to residential, enterprise, and wholesale customers with varying traffic/applications/services demands. The disaggregated nature of the SD-CPON solution allows access network slicing concept to be effectively utilized by operators to leverage existing fiber fed technologies (FTTX) architectures, fiber ducts, cabinets, etc. to aggregate and transport massive amounts of mobile broadband data.

FIG.1shows an example of a FANS system100, which enable cost-effective resource utilization when an infrastructure provider (InP) has control of a physical access network that supports virtual unbundling to several VNOs102. With deep FTTX and Software Defined Access, the physical unbundling provides a means for virtual unbundling (also known as slicing) of the resources to enable differentiated or innovative services. FANS system100provides standardized interfaces (per BBF TR-370) that allow network information (diagnostics, faults, performance management) to be exposed by the InP to VNO, enabling automated operations across the InP/VNO domains according to a standards-defined approach. An objective of FANS system100is to enable VNOs102to perform operations with virtual unbundling similar to their operations with physical unbundling. FANS system100allows a VNO to request and/or perform changes in network configuration and control their own virtual network. Network management becomes a shared responsibility with FANS working across InP and VNO domains. The levels of data sharing and their resolution/accuracy may be different, distinguished by both domains.

FIG.2shows a high-level system200for wireless communications. High-level system200includes user equipment and devices202, an NG RAN204, an FTTX transport206, a 5G core (edge location)208, a 5G core (data center)210, media analytics212, and an orchestrator214.

User equipment and devices202represents different types of devices such as customer-premises equipment (CPE), gateway, and smart home IoT gateways. The types of user equipment and devices202are constantly evolving. User equipment, for example, includes smartphones and tablets, capable of communications over 5G and Wi-Fi 6 or 7. IoT devices may include public safety types of devices.

NG RAN204may include an open RAN with integrated Wi-Fi, and may have licensed and unlicensed bands. NG RAN204, therefore, may support a converged infrastructure including 3GPP and non-3GPP wireless communications technologies for the mobility services and also fixed broadband services.

FTTX transport206is a fiber optic transport wired infrastructure that ties NG RAN204and 5G core (edge location)208. FTTX transport206is intended to scale so as to accommodate access networks and multiple bands (low, mid, and high; licensed and unlicensed; and shared bands) on the order of multi-gigabit per second from a single cell site.

5G core (edge location)208includes a user-plane function at the edge location for local processing. In other embodiments, that function is at 5G core (data center)210. 5G core (edge location)208may also include centralized controller functions, signaling planes and authentication, subscription management, policy management, and other functions. The strategy to locate the user plane functions at the edge may depend upon some specific use cases, for example, like mission critical services, public services, and bandwidth-rich intensive conversational services that are sensitive to quality of experience, and video processed locally. Putting this user plane function closer to the cell site avoids transporting that information to a centralized data center somewhere located far off from the cell site, with the added benefit of leveraging FTTX transport206.

5G core (data center)210includes the control plane functions hosted in a centralized location within a data center. This can be in public, private, hybrid cloud, and other types of deployments.

Media analytics212is an engine that can process all the media processing information. This could come from the user plane functions located near the edge as well or in a data center.

Orchestrator214is also shown to support service providers by facilitating management all the different entities shown inFIG.2and provide desired services.

FIG.3shows a 5G O-RAN standalone reference architecture300, which includes O-RUs302, an O-DU304, an O-CU306, and a 5G core308. Between these disaggregated network functions are the transport infrastructure including fronthaul310, midhaul312, and backhaul314. With one DU and one CU, 5G O-RAN standalone reference architecture300may represent a single cell cite with 360-degree coverage (each O-RU302supports a cell of 120-degree coverage).

FIG.4shows a 5G O-RAN network slicing architecture—dedicated DU/CU model400. In large-scale deployments, there may be multiple cells (e.g., nine, in the example ofFIG.4). In the example ofFIG.4, there are also three slices, which each may be subject to certain strict service level agreements. With nine cells and three slices, full mesh connectivity results in 27 fiber connections in the front haul (nine connections to each of three DUs). Likewise, in the midhaul, each DU is connected to the three CUs. In the backhaul, each CU is connected to the 5G core. Efficiently managing the transport network interfaces in a scalable manner to support slicing has been a challenge.

FIG.5shows a 5G O-RAN network slicing reference architecture—shared DU/CU model500. In the example ofFIG.5, there are nine cells that connect to a single DU. Even in a shared model, the number of fiber connections becomes unwieldy with slicing and at scale.

FIG.6shows an xHaul-enabled distributed-RAN600. In the example ofFIG.6, xHaul-enabled distributed-RAN600comprises a network slice602, a RAN slice604, a transport slice606, and a CN slice608.

FIG.7shows an xHaul-enabled cloud-RAN700. In the example ofFIG.7, xHaul-enabled cloud-RAN700comprises a network slice702, an O-RAN slice704, a fronthaul transport slice706, a midhaul transport slice708, a backhaul transport slice710, and a CN slice712. O-RAN slice704covers all the RAN components (the O-RU, O-DU, and O-CU). Backhaul transport slice710then connects the O-RAN into the core network.

FIG.8shows a converged 5G O-RAN+XGS-PON setup800. In the example ofFIG.8, an O-RAN802connects to a 5G core network804through an XGS-PON806.

XGS-PON806acts as a backhaul aggregation architecture to aggregate the fiber connections from O-RAN802. XGS-PON806includes a G-PON optical network terminal (ONT)808; an XGS-PON ONT810, an optical distribution network (ODN)812; a wavelength multiplexer814for optical multiplexing; and an SD-CPON OLT816. SD-CPON OLT816includes an SDBANS controller818.

Because SD-CPON OLT816is disaggregated, its software is decoupled from the CPON-OLT hardware platform. Therefore, the software component of the OLT can be distributed (see, e.g.,FIG.12) or centralized (see, e.g.,FIG.13) based on the deployment model that a service provider may chose, depending on the traffic forecasted in a given geographical region. In some disaggregated models, the software itself can be further subdivided into discrete microservices that are independently scalable.

FIG.9shows an E2E network slicing with optical transport900. In the example ofFIG.9, E2E network slicing with optical transport900includes three different domains. At the left is the access network domain, which is this cellular band slice. In the middle is the transport network domain, which includes the fiber infrastructure that is connecting the RAN to the core network using a transport network slice. And right of that is the core network, which is supported with a core network slice.

FIG.10shows an example of E2E network slicing with slice management functions1000. Similar toFIG.9, the example shows an access network, network slice subnet management function for managing all the access network slices. In the transport network, there is a transport network, slice subnet management function that can manage all of the transport slices. And similarly, there is a core network, network slice subnet management function that manages all the core network slices. On the right-hand side, there are the termination points, which include applications in each of these enterprises. This can be a single service provider or VNOs.

FIG.11shows an E2E cross-domain network slice mapping system1100, which is illustrated using the example of three systems: a communication system1102, a slicing system1104, and a slice mapping system1106.

Communication system1102includes a UE1108, a gNB1110, a first provider edge aggregation router1112, a second provider edge aggregation router1114, a core network1116, and a data network1118. A RAN slice1120carries communications between gNB1110and first provider edge aggregation router1112. A transport slice1122carries communications between first provider edge aggregation router1112and second provider edge aggregation router1114. A core slice1124carries communications between second provider edge aggregation router1114and core network1116.

Slicing system1104includes a user plane1126, a control plane1128, and a management plane1130.

In user plane1126, GTP-U is used for carrying user data within the GPRS core network and between the radio access network and the core network. The user data transported can be packets in any of IPv4, IPv6, or PPP formats. A GTP-U Tunnel endpoint identifier (TEID)1132, is a 32-bit (4-octet) field used to multiplex different connections in the same GTP tunnel. A VPN1134is used for carrying user data in transport slice1122. And a GTP-U TEID1136carries communications in core slice1124.

In control plane1128, Single-Network Slice Selection Assistance Information (S-NSSAI)1138provides for identification of a network slice. NSSAI is a collection of S-NSSAIs.

In management plane1130, a Network Slice Instance (NSI)1140includes a RAN network slice subnet instance (NSSI) ID1142; a TN NSSI ID1144; and a CN NSSI ID1146.

Slice mapping system1106shows how five different service types are each allocated a different slice. Each slice is mapped to its service according to an NSI1140, RAN NSSI ID1142, TN NSSI ID1144, and CN NSSI ID1146. This mapping allows for logically partitioning each of the three slice domains to help pair them. For example, an eMBB slice is paired with X11, X12, and X13. The mapping provides flexibility in terms of horizontal scaling and also in terms of vertical scaling. More services can be added with unique slice instances, and then each one can be associated with a unique slice across the domains, logically.

FIG.12is an example of a distributed OLT model1200showing control/management/data path flow. Distributed OLT model1200includes an STC1202(e.g., traffic testing tool, residential gateway) connected to a set of ONUs1204via a user-network interface (UNI)1206. Set of ONUs1204includes a first ONU1208though a Nth ONU1210that are communicatively coupled to an ODN1212. ODN1212is coupled to OLT1214, which includes a distributed SDBANS-D controller1216having a controller application embedded within the OLT1214hardware platform. OLT1214is coupled to an aggregator1218via a service-network interface, SNI1220. Aggregator1218provides data to a cloud management system (CMS)1222or an element management system (EMS) and an STC1224. A control interface1226is provided to control each of STC1202and STC1224.

ODN1212may be similar to ODN812and include wavelength multiplexer814(FIG.8). For example, instead of carrying 100 fibers from 100 DUs into one CU, ODN1212aggregates the fiber connections (e.g., at a cell site) in the optical domain to provide them to OLT1214that implements a slice controller.

In contrast to a distributed model ofFIG.12showing distributed SDBANS-D controller1216,FIG.13shows an example of a centralized OLT model1300with its control/management/data path flow. In centralized OLT model1300, a centralized SDBANS-C controller1302is cloud native to allow it to aggregate information from multiple OLTs1304. Thus, centralized SDBANS-C controller1302is decoupled from the OLT hardware platforms to allows it to scale it independently and manages multiple OLT platforms. For example, in an M×N mesh combination of DUs to CUs, one OLT may not provide sufficient network capacity. Accordingly, multiple OLTs1304are stacked at the termination point, with centralized SDBANS-C controller1302being able to independently scale, in the software, as capacity demands on the aggregation change.

FIG.14is an annotated table showing three components1400of an SDBANS controller. The SDBANS controller includes an CPON OLT Slice Selection Function (OSSF)1402; OLT Slice Analytics Engine (OSAE)1404; and OLT Slice Performance Engine (OSPE)1406, with example types of performance data1408.

These three blocks operating in unison ensure that the SD-CPON network is optimally utilized when carrying such hybrid workloads delivering superior functionality and service layer experience. The controller can also expose via standards-based APIs to cross-domain slice orchestrators to allow for dynamic pairing of transport slices between next-generation radio access and core networks. Such a pairing model ensures E2E intelligent networking design that is flexible and reconfigurable, adapts to dynamic workloads as traffic demands continue to grow over time, and provides an easy-to-scale strategy for graceful evolution.

Each of these components1400can be implemented as microservices independently from the RAN and core slicing domains and thus provide full flexibility in terms of a FANS model that could be leveraged by multiple VNOs for delivering enhanced broadband services. Each of these components1400also has unique functions that could be implemented as containerized microservices in the control and management layer so that each can be scaled independently.

FIG.15AandFIG.15Bshow an annotated block diagram of an example mapping process1500in the transport network between an SDBANS controller1502and a 16 port OLT1504. Each of the 16 ports is a physical port (e.g., supporting one or 10 Gbps service). Other numbers of ports are also possible.

Mapping process1500allows logical grouping of these ports so different groups can support different slices. For example, four slices (each having four ports), identified by OSID1-OSID4, can be mapped to IoT slices, mobile broadband, or other uses.

FIG.15AandFIG.15Balso show how data from SDBANS controller1502can be exposed to non-PON interfaces through a Rest API1506with a cloud native EMS1508. Accordingly, the data is accessible through EMS1508. In this example, EMS1508includes a transport domain slice orchestrator1510.

FIG.16AandFIG.16Bshow an annotated block diagram of an example mapping process1600in the transport network between distributed SDBANS controllers1602(see, e.g., distributed SDBANS-D controller1216ofFIG.12) and multiple 16-port OLTs1604. In this distributed model, each OLT includes a different controller. A transport domain slice orchestrator1606is also implemented in an EMS.

FIG.17AandFIG.17Bshow an annotated block diagram of an example mapping process1700in the transport network between a centralized SDBANS controller1702(see, e.g., Centralized SDBANS-C controller1302ofFIG.13) and multiple 16-port OLTs1704. In this centralized model, each OLT is mapped by centralized SDBANS controller1702, which can be implemented as part of a cloud system and converged domain orchestrator1706. A transport domain slice orchestrator1708is also implemented in an EMS.

In some embodiments, an example of a converged domain orchestrator is described in U.S. patent application Ser. No. 17/810,593, filed Jul. 1, 2022, and titled “Data Driven Energy Efficiency in Open Radio Access Network (O-RAN) Systems.” For instance, the '593 application describes a converged domain data analytics function (CDDAF) that collects analytics information across the access, transport, and core network domains so as to dynamically configure the network.

FIG.18shows an example of transport network slice information exchange1800. In the example ofFIG.18, transport network slice information exchange1800includes a transport domain slice orchestrator (EMS)1802, an SDBANS controller1804, an OSSF1806, an OSAE1808, and an OSPE1810.

Initially, SDBANS controller1804, OSSF1806, OSAE1808, and OSPE1810exchange periodic messages for status updates. Transport domain slice orchestrator (EMS)1802may control multiple SDBANS controllers for different associated regions (see e.g.,FIG.19), with different TN NSSI IDs mapped to different slices. To initiate transport network slicing, transport domain slice orchestrator (EMS)1802receives an external domain trigger to provide the transport resources sought to deliver certain services (eMBB, URLLC, CV2X, etc.). For instance, the external domain trigger includes information exchanged through the API, initially based on a service request from an end user that is requesting a service to the access domain, and then based on API call from an access domain orchestrator to transport domain slice orchestrator (EMS)1802. In other embodiments, triggers are generated from the core network domain. The API calls themselves may include information such as, for example, the type of service, QoS, latency specifications, dedicated resource capabilities or shared resource, and resource utilization.

In response, transport domain slice orchestrator (EMS)1802generates a trigger to SDBANS controller1804for a transport slice request. As mentioned above, this trigger may be implemented as an API call, and the API call may include information for allocating the slice.

SDBANS controller1804communicates with its OSSF-OSAE-OSPE services to allocate and map a vendor-specific OLT ID SKU (or other high-level hardware identifier such as a node ID) and OSIDs for one or more ports. For instance, SDBANS controller1804selects from a group of OLT vendors for the geographical region associated with the transport slice request, a selected OLT vendor such that the information of the response indicates the selected OLT vendor. In another example, SDBANS controller1804selects from a group of OLT SKUs for the geographical region associated with the transport slice request, a selected OLT SKU such that the information of the response indicates the selected OLT SKU. And in another example, SDBANS controller1804selects from a group of OLT node IDs for the geographical location associated with the transport slice request, a selected OLT node ID such that the information of the response indicates the selected OLT node ID, in which each OLT node ID corresponds to a geographical region and a vendor.

Once an OLT slice allocation is made, that information is provided back to transport domain slice orchestrator (EMS)1802. The OLT slice allocation may include other information such as service type (ST).

Next, in response to services being provided via the OLT slice allocation, SDBANS controller1804generates slice analytics data indicating slice utilization and availability. For instance, generating the slice analytics data optionally entails aggregating packet-level statistics of a certain service type associated with control plane signaling and user data with transport protocols, IP or non-IP data (in case of IoT services), Ethernet packets that belong to Ethernet PDU sessions, number of tunnel identifiers being used between specific interfaces between two end points across multiple domains (access-transport and transport-core), and other types of data aggregation.

In some embodiments, the slice analytics data includes control plane analytics associated with the transport network slice, such as, for example a number of RRC connections, number of session establishment messages, number of registrations, or other types of control plane information. In other embodiments, the slice analytics data comprises user plane traffic analytics data associated with the transport network slice such as, for example, data usage, latency, CPU utilization, or other types of user plan information.

Once the slice analytics data has been generated, SDBANS controller1804provides the slice analytics data to transport domain slice orchestrator (EMS)1802. Transport domain slice orchestrator (EMS)1802can then expose this information to a specific domain orchestrator, a converged domain orchestrator, or other systems.

FIG.19shows an example of a transport network slice map1900, which is maintained at the orchestration level since the orchestrator has visibility over multiple regions corresponding to multiple SDBANS controllers. Depending on the number of serving CPON OLTs in that region, a mapping is defined in an SDBANS controller as follows. SDBANS Controller—Region—whitebox vendor #—OLT ID SKU #—OLT Slice ID #. TN NSSI ID is mapped to SDBANS controller ID which is then internally mapped to Region—Vendor—OLT ID SKU—OLT slice ID. Traffic is then monitored at the SDBANS controller level to ensure SLAs are being met across the TN as well as from an E2E perspective.

To map a transport network slice instance, there are several considerations. The various 5G slice STs (eMBB/URLLC/MIoT/CV2X/Public Safety) for serving a given market/region are identified. For each 5G slice service type, an E2E network slice instance ID is designated. An operator defines strict service level assurance (SLA) criteria for each of these slice service types. RAN, transport, and core network slices need to be cooperative to achieve the E2E slice-specific SLA. The E2E network slice instance ID is associated to the cross-domain slice IDs (RAN, transport, and core NSSI IDs, as shown inFIG.11). Within the transport network domain, a specific mapping of the TN NSSI ID is associated to the CPON OLT slicing technique described in the table ofFIG.19. Transport network is served by XGS-PON solution to carry the data from 5G radio access network to the centralized core hosted in a cloud data center.

In the transport network slice mapping example ofFIG.19, the transport network in a 5G serving area supports five 5G slice service types. The example also shows a three-region transport network deployment model with a dedicated SDBANS controller per region. Each SDBANS regional controller operates in a redundant mode for failover operation. Each regional controller manages its (1) standardized northbound interface is towards a common transport management/orchestration layer; (2) southbound interface via standard API triggers for exchange of the mapping configuration, fault, and performance data; (3) multi-vendor, multi-SKU OLT platform to support multi-service types across multiple virtual network operators; (4) complete inventory of the vendor-specific OLT slices and associated service types such as when multi-vendor CPON OLT whitebox hardware solutions are deployed in that region to minimize CapEx; and (5) operational state of the slices for intelligent traffic steering, switching, and splitting. The CPON OLTs communicate via open standards/ONF-defined interface to the associated SDBANS controller.

FIG.19also shows an example of subservice (e.g., eMBB.1, eMBB.2, etc.) mapping. In this example, subservices may receive an OLT slice allocation to support a QoS (or other performance capability) for that particular subservice.

FIG.20shows a process2000, performed by a transport domain slice orchestrator, of orchestrating transport network slices. In block2002, process2000maps each network slice ST to a unique TN NSSI ID in a set of TN NSSI IDs. In block2004, process2000maps one of the unique TN NSSI IDs in the set of TN NSSI IDs to a geographical region and a SD-CPON OLT. In block2006, process2000selects from a set of SDBANS controllers, a selected SDBANS controller for the geographical region in which a transport slice request has originated. In block2008, process2000triggers the selected SDBANS controller with the transport slice request for causing the selected SDBANS controller to generate an OLT slice allocation to associate an OLT port of an SD-CPON OLT that is controlled by the selected SDBANS controller.

Process2000may also include mapping of the one of the unique TN NSSI IDs to an SDBANS controller ID representing the geographical region, vendor, SKU, OLT slice ID, and ST.

Process2000may also include triggering the selected SDBANS controller in response to an API trigger originated from an access or core domain.

Process2000may also include, receiving, in response to the triggering, the OLT slice allocation.

Process2000may also include, in response to services provided via the OLT slice allocation, receiving slice analytics data indicating slice utilization and availability.

Process2000may also include providing the slice analytics data to a converged domain orchestrator.

Process2000may also include each network slice service type having a subservice type with an associated QoS.

FIG.21is a block diagram illustrating components2100of an SD-CPON or orchestration system, according to some example embodiments. Components2100able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of SDBANS or orchestration tasks discussed herein, such as, for example transport network slice information exchange1800or process2000. Specifically,FIG.21shows a diagrammatic representation of hardware resources2102including one or more processors2104(or processor cores), one or more memory/storage devices2106, and one or more communication resources2108, each of which may be communicatively coupled via a bus2110. For embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor2112may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources2102.

Processors2104(e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) such as a baseband processor, an application specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor2114and a processor2116.

Memory/storage devices2106may include main memory, disk storage, or any suitable combination thereof. Memory/storage devices2106may include, but are not limited to any type of volatile or non-volatile memory such as dynamic random access memory (DRAM), static random-access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, solid-state storage, etc.

Communication resources2108may include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices2118or one or more databases2120via a network2122. For example, communication resources2108may include wired communication components (e.g., for coupling via a Universal Serial Bus (USB)), cellular communication components, NFC components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components.

Instructions2124may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of processors2104to perform any one or more of SABR engine tasks discussed herein. Instructions2124may reside, completely or partially, within at least one of processors2104(e.g., within the processor's cache memory), memory/storage devices2106, or any suitable combination thereof. Furthermore, any portion of instructions2124may be transferred to hardware resources2102from any combination of peripheral devices2118or databases2120. Accordingly, memory of the processors2104, memory/storage devices2106, peripheral devices2118, and databases2120are examples of computer-readable and machine-readable media.

Skilled persons will appreciate that many changes may be made to the details of the above-described embodiments without departing from the underlying principles of the invention. The scope of the present invention should, therefore, be determined only by the following claims and equivalents.