Search

US-20260129006-A1 - SYSTEMS AND METHODS FOR NETWORK-AS-A-PLATFORM

US20260129006A1US 20260129006 A1US20260129006 A1US 20260129006A1US-20260129006-A1

Abstract

A network-as-a-platform (NaaP) ecosystem includes a network exposure layer (NEL). The NEL includes a plurality of federated application programming interfaces (APIs) having at least a first federated API and a second federated API different from the first federated API. The NaaP ecosystem further includes a first network in operable communication with the NaaP ecosystem through the first federated API of the NEL, and a second network, different from the first network, in operable communication with the NaaP ecosystem through the second federated API of the NEL. The NEL enables the second network access to at least one capability of the first network.

Inventors

  • Mark Bridges
  • Paul Fonte
  • Belal Hamzeh
  • Sanjay Patel

Assignees

  • CABLE TELEVISION LABORATORIES, INC.

Dates

Publication Date
20260507
Application Date
20251229

Claims (20)

  1. 1 . A network-as-a-platform (NaaP) ecosystem, comprising: a network exposure layer (NEL) comprising a plurality of federated application programming interfaces (APIs) including at least a first federated API and a second federated API different from the first federated API; a first network in operable communication with the NaaP ecosystem through the first federated API of the NEL; and a second network, different from the first network, in operable communication with the NaaP ecosystem through the second federated API of the NEL, wherein the NEL enables the second network access to at least one capability of the first network.
  2. 2 . The ecosystem of claim 1 , wherein the first network includes at least one of an access network, a mobile network, a passive optical network (PON), a coherent PON (CPON), an Ethernet PON (EPON), a gigabit PON (GPON), a 3GPP-based network, a 5G network, a data over cable service interface specification (DOCSIS) network, a low earth orbit (LEO) network, and a very LEO (VLEO) network.
  3. 3 . The ecosystem of claim 1 , wherein the plurality of federated APIs includes at least one of a core network function API, an operations API, an intent-based API, an edge application mobility API, and a device management API.
  4. 4 . The ecosystem of claim 1 , further comprising a virtual service layer logically disposed between (a) the NEL, and (b) the first and second networks.
  5. 5 . The ecosystem of claim 4 , wherein the virtual service layer includes at least one of a device controller, a network telemetry and topology server, a configuration and profile management server, a network service orchestrator (NSO), a subscriber and policy database 120 , and an authentication, authorization, and accounting (AAA) server.
  6. 6 . The ecosystem of claim 4 , further comprising a management and control layer logically disposed between (a) the virtual service layer, and (b) the first and second networks.
  7. 7 . The ecosystem of claim 6 , wherein the management and control layer is configured for software defined networking (SDN).
  8. 8 . The ecosystem of claim 1 , further comprising a multi-access edge compute (MEC) site configured to deploy an external application to run on at least one of the first and second network.
  9. 9 . The ecosystem of claim 8 , wherein the MEC site is further configured to select the first network to run the external application based on a network characteristic envelope included with the external application.
  10. 10 . The ecosystem of claim 9 , wherein the network characteristic envelope includes at least one desired performance metric for the external application to run on the first network.
  11. 11 . The ecosystem of claim 10 , wherein an external communication device in operable communication with the second network is enabled to access the external application utilizing the at least one desired performance metric of the first network.
  12. 12 . The ecosystem of claim 10 , wherein the at least one desired performance metric of the first network specifies at least one of a desired bandwidth, maximum latency, jitter, speed, ultra low latency (ULL), device management, remote capability, Wi-Fi services, and packet loss.
  13. 13 . The ecosystem of claim 9 , wherein the external application originates from the second network.
  14. 14 . The ecosystem of claim 9 , wherein the MEC site is further configured to discover at least one different MEC site to provide optimal performance of the external application based on the network characteristic envelope.
  15. 15 . The ecosystem of claim 8 , further comprising a converged core disposed between (a) the MEC site, and (b) the first and second networks.
  16. 16 . The ecosystem of claim 8 , wherein the NEL is further configured to register the external application through a global platform developer (GDP).
  17. 17 . A central controller for a network-as-a-platform (NaaP)-based electronic communication ecosystem, comprising: a network exposure layer (NEL) comprising a plurality of federated application programming interfaces (APIs) including at least a first federated API and a second federated API different from the first federated API; a processor; and a memory in communication with the processor and the NEL, and configured to store computer-executable instructions therein, which, when executed by the processor, cause the processor to: subscribe a first network to the NEL through the first federated API; enable a second network, different from and separately operated from the first network, to subscribe to the NEL through the second federated API; and deploy an application originating from the second network to run on the first network based on at least one performance characteristic of the first network visible to the second network through the NEL.
  18. 18 . The central controller of claim 17 , wherein the memory is further configured to store a catalog of services and/or resources of the first network available to the second network.
  19. 19 . The central controller of claim 18 , wherein the instructions further cause the processor to enable the second network to view at least some of the services and/or resources available from the first network.
  20. 20 . The central controller of claim 19 , wherein the instructions further cause the processor to prevent the second network from viewing or accessing at least one of the services and/or resources available from the first network.

Description

RELATED APPLICATIONS This application is a continuation of U.S. patent application Ser. No. 18/378,584, filed Oct. 10, 2023, which application claims the benefit of and priority to U.S. Provisional Patent Application Ser. No. 63/396,885, filed Aug. 10, 2022, and to U.S. Provisional Application No. 63/440,203, filed Jan. 20, 2023. The disclosures of all of the above-referenced applications are incorporated herein by reference in their entireties. BACKGROUND Recent developments in Software Defined Networking (SDN) and Dynamic SDN (DSDN) have provided network level functionality and security protections for a number of different types of devices, particularly with respect to connected Internet of Things (IoT) devices, as well as other systems and appartuses of both wired and or wirelessly interconnected devices. For some devices, DSDN techniques have been recently provided to dynamically implement virtual private network (VPN) tunneling capabilities, which add both strong security protections for connecting devices and networks, but also enable improved functionality for micronetworking implementations. Relevant VPN tunneling and micronet functionality is described in greater detail in co-pending U.S. application Ser. No. 18/123,814, filed Mar. 20, 2023, the subject matter thereof which is incorporated by reference herein in its entirety. At present, conventional networking systems utilize a number of different application programming interfaces (APIs) for the respective networks, where such known APIs function according to the respective standards body/bodies (e.g., TeleManagement Forum (TMF), Third Generation Partnership Project (3GPP), Broadband Forum (BBF), etc.) defining the respective APIs. Accordingly, there is a desire in the industry for network and program application convergence to better enable easy communication between these various disparate networks. Additionally, there is a further desire in the industry to enable the delivery of differentiated business-class services (e.g., corporate-level networks) for remote connectivity, such as in the case of work-from-home (WFH) scenarios. At present, many employees now utilize connective business equipment (corporate computers, smartphones, IoT accessories) outside of the confines of the office environment that typically includes significantly higher network security than is available to the average home network environment. Furthermore, where employees connect their corporate devices remotely, significant interaction is usually required by the user, or their information technology (IT) support staft, to set up the device and/or applications on the device. Therefore, there is a particular need to enable secure, automatic device/application setup without further user interaction. These particular challenges and industry needs are addressed and solved according to the following embodiments. SUMMARY In an embodiment, a network-as-a-platform (NaaP) ecosystem includes a network exposure layer (NEL). The NEL includes a plurality of federated application programming interfaces (APIs) having at least a first federated API and a second federated API different from the first federated API. The NaaP ecosystem further includes a first network in operable communication with the NaaP ecosystem through the first federated API of the NEL, and a second network, different from the first network, in operable communication with the NaaP ecosystem through the second federated API of the NEL. The NEL enables the second network access to at least one capability of the first network. In an embodiment, a central controller for a network-as-a-platform (NaaP)-based electronic communication ecosystem includes a network exposure layer (NEL). The NEL includes a plurality of federated application programming interfaces (APIs) including at least a first federated API and a second federated API different from the first federated API. The central controller further includes a processor and a memory in communication with the processor and the NEL. The memory is configured to store computer-executable instructions therein, which, when executed by the processor, cause the processor to subscribe a first network to the NEL through the first federated API, enable a second network, different from and separately operated from the first network, to subscribe to the NEL through the second federated API, and deploy an application originating from the second network to run on the first network based on at least one performance characteristic of the first network visible to the second network through the NEL. BRIEF DESCRIPTION These and other features, aspects, and advantages of the present disclosure will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein: FIG. 1 is a schematic illustration of an exemplary network-as-a-platform logical architecture, in an