Shared Virtualization of Geographically Distributed PONs

Abstract

A system that supports geographically dispersed remote optical line terminals.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application Serial No. 63 / 398,472, filed August 16, 2022.

[0002] The subject matter of this application relates to geographically distributed OLTs for passive optical networks. [Background technology]

[0003] Passive optical networks (PONs) are often employed as access networks or as part of larger communications networks. Communications networks typically have a high-capacity core section through which data or other information associated with telephone, digital television, and Internet communications is transmitted over significant distances. The core section may have the capability to interact with other networks to complete the transmission of telephone, digital television, and Internet communications. In this manner, the core section in combination with the passive optical network enables communications to and from subscribers (or devices associated with subscribers, customers, businesses, or otherwise).

[0004] The access network of a communications network extends from the core of the network to individual subscribers, such as those associated with a particular residence (e.g., business location). The access network may be wireless access, such as a cellular network, or may be fixed access, such as a passive optical network or a cable network.

[0005] Referring to FIG. 1, a PON 10 uses a set of optical fibers and passive interconnection devices for most or all of the communications throughout the access network. A set of one or more optical network terminals (ONTs) 11 are typically located at subscriber residences (e.g., or business locations). The term "ONT" includes what are also referred to as optical network units (ONUs). Any number of ONTs associated with a single optical splitter 12 may be provided. By way of example, 32 or 64 ONTs are often associated with a single network optical splitter 12. The optical splitters 12 are interconnected with their respective ONTs 11 by respective optical fibers 13 or otherwise by respective fibers in a fiber optic cable. Selected ONTs may be removed and / or added to the access network associated with the optical splitter 12 as needed. Multiple optical splitters 12 arranged in a cascaded configuration may also be provided.

[0006] The optical fiber 13 interconnecting the optical splitter 12 and the ONT 11 acts as an access (or "drop") fiber. The optical splitter 12 is typically located within a street cabinet or other structure in which one or more optical splitters 12 are located, each serving a corresponding set of ONTs. In some cases, an ONT may serve multiple subscribers, such as multiple subscribers in multiple dwelling units (e.g., apartment buildings). In this way, a PON can be viewed as a point to multipoint topology, where a single optical fiber serves multiple endpoints by using passive optical fiber splitters to divide the fiber bandwidth among the endpoints.

[0007] An optical line terminal (OLT) 14 is located at a central office, directly or indirectly interfacing to a core network 15. The interface 16 between the OLT 14 and the core network 15 may be one or more optical fibers, or any other type of communication medium. The OLT 14 forms optical signals for transmission downstream to the ONTs 11 through feeder optical fibers 17, and receives optical signals from the ONTs 11 through the feeder optical fibers 17. The optical splitter 12 is typically a passive device that splits signals received from the OLT 14 to the ONTs 11. Similarly, the optical splitter 12 receives optical signals from the ONTs 11 and provides optical signals to the OLT 14 through the feeder optical fibers 17. In this manner, a PON includes an OLT with multiple ONTs, which reduces the amount of fiber required compared to a point-to-point architecture.

[0008] As can be seen, an optical signal containing all data for ONT 11 is provided over feeder fiber 17. Thus, all data provided for each of the ONTs is provided to all ONTs through optical splitter 12. Each ONT transmits data to its subscribers by selecting the portion of the received optical signal intended for that particular ONT and discarding the remaining data. Typically, data for the ONTs is broadcast over feeder fiber 17 and provided to each of the ONTs.

[0009] Upstream transmissions from the ONTs 11 through their respective optical fibers 13 are typically transmitted in bursts according to a schedule provided to each ONT by the optical line terminal (OLT). In this manner, each of the ONTs 11 transmits upstream optical data at different times. In some embodiments, the upstream and downstream transmissions are transmitted using different wavelengths of light so that they do not interfere with each other. In this manner, a PON may utilize wavelength division multiplexing over a single-mode fiber, using one wavelength for downstream traffic and another wavelength for upstream traffic.

[0010] A schedule from the OLT allocates upstream bandwidth to ONTs. Because the optical distribution network is shared, ONTs' upstream transmissions are likely to collide if they are transmitted at random times. ONTs are typically located at various distances from the OLT and / or optical splitter, resulting in different transmission delays for each ONT. The OLT measures the delay and equalizes it for other ONTs associated with the OLT by setting registers in each ONT. After the delay is accounted for, the OLT transmits a so-called grant to each ONT in the form of a grant map. A grant map is an authorization to use a defined time interval for upstream transmission. The grant map is dynamically recalculated periodically, such as for each frame. The grant map allocates bandwidth to all ONTs so that each ONT receives a timely bandwidth allocation for its service needs. Much data traffic, such as website browsing, tends to be bursty and fluctuates significantly over time. Dynamic bandwidth allocation (DBA) between different ONTs can cause the PON to be oversubscribed for upstream traffic. [Brief explanation of the drawings]

[0011] For a better understanding of the present invention and to show how the same may be carried into effect, reference will now be made, by way of example, to the accompanying drawings in which:

[0012] [Figure 1] FIG. 1 illustrates a network that includes a passive optical network.

[0013] [Figure 2] FIG. 2 illustrates a passive optical network with downstream data traffic.

[0014] [Figure 3] FIG. 3 illustrates a passive optical network with upstream data traffic.

[0015] [Figure 4] FIG. 4 illustrates a remote OLT.

[0016] [Figure 5] FIG. 5 illustrates a remote OLT and a corresponding edge server.

[0017] [Figure 6] FIG. 6 illustrates an exemplary remote OLT.

[0018] [Figure 7] FIG. 7 illustrates a processing system.

[0019] [Figure 8] Figure 8 illustrates processing on a YANG data model using OMCI.

[0020] [Figure 9] FIG. 9 illustrates the process for a PON network.

[0021] [Figure 10] FIG. 10 illustrates a YANG request and a YANG response. DETAILED DESCRIPTION OF THE INVENTION

[0022] Referring to Figure 2, a PON network is based on a point-to-multipoint downstream transmission arrangement. Data from the OLT is transmitted to all interconnected ONTs. The data from the OLT is transmitted in the form of one or more frames, with each frame containing data for one or more ONTs. For example, in GPON, a constant 125 μs frame is used, where each frame contains an allocation map that (among other control information) indicates the allocation ID onto which slots are assigned. Each frame is therefore divided into one or more time slots designated for a corresponding selected one of the ONTs.

[0023] Referring to Figure 3, a PON network is based on a multipoint-to-point upstream transmission arrangement using a time division multiplexing access mechanism. The OLT allocates time slots (BW maps) to each ONT to transmit its upstream transmissions, ensuring collision-free transmission. Data from each ONT is transmitted to its corresponding interconnected OLT. Data from the ONT is transmitted in the form of parts of one or more frames, where each frame contains data for one or more ONTs. For example, GPON uses a reference frame of 125 μs, which is not an absolute value because an allocation round may span multiple upstream frames. GPON uses the Generic Encapsulation Method (GEM), which allows the transport, segmentation, and reassembly of Ethernet frames and legacy traffic (ATM or TDM). Therefore, each frame is divided into one or more time slots designated for a corresponding selected one of the ONTs.

[0024] Referring to FIG. 4, in some installations, it is often desirable to locate an optical line terminal, also commonly referred to as a remote optical line terminal (OLT), at a location remote from the core network. The remote OLT may include one or more feeds from the core network to the remote OLT. The remote OLT may then distribute data to and receive data from multiple ONTs. Each of the ONTs then provides data to and receives data from customer devices. The remote OLT typically has the capacity to provide service to hundreds to thousands of ONTs.

[0025] It is generally considered preferable to provide all computing resources at a single location, the headend, that can provide timely service to customers. The headend therefore includes servers for providing high-speed data services, a network for providing high-speed data services, and management applications for controlling and provisioning the servers and network. In this way, the headend traditionally provides an integrated approach to ensure timely provisioning, control, and provisioning of an effective network.

[0026] It has been determined that a hybrid environment is appropriate for environments including one or more remote OLTs. A hybrid environment includes a "cloud" where infrastructure and resources are deployed at a location, such as a head end, to virtualize various aspects of the OLT. A "cloud" is provided by a cloud service provider interconnected to the remote OLT via a network connection, such as the Internet. It may be a "private cloud" or a "public cloud." A public cloud provides computing, network storage, and application resources, such as those provided by a public cloud provider, as a service over a network, such as the Internet. The public cloud provider typically owns, manages, provisions, and maintains the infrastructure and provides it to customers as a service, usually in exchange for a periodic subscription or fee based on usage. The public cloud provider typically bears all capital, operating, and maintenance costs associated with the public cloud. Public clouds are scalable, allowing additional resources to be utilized on demand. In some cases, a public cloud is configured as a virtual private cloud within the system provided by the public cloud provider.

[0027] The cloud environment provides the capabilities of a cloud server in an environment including one or more remote OLTs, providing at least in part control plane load such as provisioning information, statistical measurements, connection configurations, etc., with sufficient performance and capacity for customers, while providing the ability to provide management and control services that are less critical to the control plane load, and the ability to use the cloud environment to provide other services that are dynamic and transient in nature. The more critical data plane load should remain primarily local to the remote OLTs, some of which may be provided by the cloud server.

[0028] Referring to FIG. 5, for geographically distributed environments, it has been determined that virtualized components of remote OLTs can improve performance when the time to provide such virtualized services is provided by a geographically proximate edge server (e.g., a general server). A remote OLT and a corresponding edge server are preferably located within five miles of each other, more preferably within two miles of each other, and more preferably within a quarter mile of each other. Pairs of remote OLTs and corresponding edge servers are preferably located more than five miles from each other, more preferably more than ten miles from each other, and more preferably more than twenty miles from each other. The core network may be used to provision and configure edge servers, if necessary. An edge server may include processing capabilities to provide, at least in part, control plane services for a geographically proximate remote OLT and / or may include processing capabilities to provide, at least in part, data plane services for a geographically proximate remote OLT. The edge server and a corresponding geographically remote OLT are preferably both interconnected using an Ethernet-based interconnection, which is typically available on the northside interface of the remote OLT. The remote OLTs are also preferably interconnected to a core network that provides interconnection to the Internet. In this manner, the data path for generalized Internet data traffic, such as Netflix, is from each of the remote OLTs via the core network, while virtualization of some of the control plane services and / or some of the data plane services is provided by the corresponding edge server. Each of the corresponding edge servers may be interconnected to the Internet via the core network and / or may be interconnected to the Internet using an alternative interconnection.Additionally, by virtualizing each of the remote OLTs that includes microservices running on the core network and / or on one or more edge servers, the microservices may be transferred between the core network and / or one or more edge servers, thereby redistributing the processing load.

[0029] Referring to Figure 6, an exemplary remote OLT is illustrated. By way of example, the diag, dma, clish, restapi, gRPC, rolt4isr, and / or rolt4api processes are preferably contained locally on the remote OLT. Also, a dynamic bandwidth allocation process that allocates available bandwidth among each of the ONTs is similarly contained locally on the remote OLT. Other processes associated with the remote OLT, such as the vomci and / or Yuma servers, may be virtualized and / or located on cloud-based servers. For example, the VOMCI may (1) receive service configuration from the virtualization entity, (2) convert the received configuration to an ITU G.988 OMCI management entity and format it into an OMCI message, (3) encapsulate and transmit the formatted OMCI message to the VOMCI proxy, (4) convert the OMCI message (representing ONT operational data) received from the vOMCI proxy into data understandable by the vOLT management function (e.g., notification acknowledgments, alarms, PM registers), and / or (5) transmit the above ONT operational data to the vOLT management function. See the TR-451 vOMCI specification, June 2022, and the ONT Management and Control Interface (OMCI) specification, G.988, November 2017, both of which are incorporated herein by reference in their entirety.

[0030] As an example, gRPC provides a gRPC server and client layer to interface to multiple vomci agents that may provide vomci services for ROLT.

[0031] As an example, the dispatcher provides a messaging pathway between components within the ponapp. Local microservices may register callbacks on message IDs that are part of the MSG layer. Any microservice can dispatch to another user based on the top two bytes of the message ID, which indicates the destination.

[0032] As an example, IPC provides TCP and UDP sockets for relaying messages to and from applications in MSG lib format and works alongside the dispatcher.

[0033] As an example, mgm is a ranging manager that provides the state machine and local for physical layer management of ONTs, including the auto-discovery process, ONT ranging, drift management, and LOS handling.

[0034] As an example, shwm is a shelf manager task that handles devices located outside the rolt4api / rolt4isr domain.

[0035] As an example, rolt4isr is a handler for interrupts from the PL.

[0036] As an example, rolt4api programs and interacts with ROLT by handling requests from various microservices within ponapp.

[0037] As an example, sim provides a simulation service to provide the ability to simulate devices that may not physically exist.

[0038] As an example, spit is a smart card proxy interface task that provides a server for application requests to and from ponapp. A typical path would be from an external client via IPC to the dispatcher and then into spit. SPIT may then relay to other microservices to perform the requested task. Some preparations may go through the softlib DB and be further relayed as preparation callouts.

[0039] As an example, mntc is a maintenance state machine, preferably an event-driven state machine for an ONT.

[0040] As an example, fdi is a fault detection and isolation task that serves as a hierarchical alarm tree service for tracking alarm conditions for different equipment types.

[0041] As an example, stat is a statistics manager that handles polling of on-board statistics and aggregating statistics for other calling functions.

[0042] As an example, iptv provides an IPTV service that includes IGMP snooping / proxy support.

[0043] As an example, dapr is a destination address programmer that handles unknown upstream source mac addresses for N:1 connections, which not only removes stale mac addresses but also allows the mac forwarding table in the PL to be maintained.

[0044] As an example, iotm is an IOT (aka ONT) manager that supports ONT command.

[0045] As an example, dba is dynamic bandwidth allocation.

[0046] As an example, keyx is a key exchange task that handles key exchange for ONTs.

[0047] As an example, softlib is a soft DB library implemented as a memory-based database used to store the configuration of ROLT.

[0048] As an example, ponid is a library used to associate ITUT serial numbers to ONT ids and / or to channel allocations.

[0049] As an example, debug is the debug library.

[0050] As an example, trans is a transaction library that is used for transaction-based and state-based requests for microservices.

[0051] As an example, QBList is a library of various list functions and of vector functions.

[0052] As an example, LOG is an event log.

[0053] As an example, MSG is a message library.

[0054] As an example, QB_OS is an operating system library.

[0055] As an example, QBLIB is a library for local APIs.

[0056] As an example, TIME is a timer library used for time-based callback logic.

[0057] As an example, PLMM is a ploam message library used for encoding and decoding ploam messages on a PON.

[0058] Referring to FIG. 7, a field programmable gate array (FPGA) includes blocks of gates that can be configured to implement logic. In comparison, a microprocessor is a central processing unit (CPU) that executes a program containing a specific set of instructions. A microprocessor has a fixed set of instructions, commonly referred to as programming code, used in conjunction with a suitable program. Each of these instructions has its own corresponding block wired within the microprocessor. In comparison, an FPGA does not have such hardwired logic blocks. FPGAs are often arranged like nets, with each junction containing a switch that can be made or broken. This set of interconnections determines how the logic of each block is determined. Programming an FPGA typically involves a hardware description language, commonly referred to as programming logic. In some cases, an FPGA and a microprocessor are combined within a single package, providing additional flexibility. The microprocessor typically performs most of the generalized processing while handing off more specific tasks to the FPGA gate array. For remote OLTs, processing systems based on a combination of a microprocessor and an FPGA gate array in a single package (i.e., chip) offer programming flexibility along with specific logic processing that is particularly well suited to supporting reduced power usage constraints.

[0059] Preferably, most of the processing side of the processing system is virtualized to computing devices external to the remote OLT (e.g., edge servers and / or core network). The virtualized processing side of the processing system preferably relates primarily to the control pane. Most of the programming logic of the processing system is preferably data plane processing for the remote OLT, some of which may be virtualized to computing devices (e.g., edge servers and / or core network). The programming logic of the processing system preferably relates primarily to the data plane. In particular, it is desirable to include a dynamic bandwidth allocation process that is contained within the processing system and is not virtualized.

[0060] As previously mentioned, it is desirable to include virtualized portions of the control pane of a processing system so that they are located sufficiently geographically close together using corresponding edge servers.

[0061] As previously mentioned, it is desirable to include virtualized portions of the data pane of a processing system so that they are located sufficiently geographically close together using corresponding edge servers.

[0062] The core network and / or optical line terminals provide management and control functions over the ONTs by using an optical network unit management and control interface (OMCI). The core network 200 and the OLT 210, to which the core network 200 provides and receives data, transmit and receive data using a PON protocol via an optical distribution network (e.g., optical splitter, etc.) 220. The OLT 210 passes data through the optical distribution network (ODN) 220 to the ONT 230 and receives data from the ONT 230 through the optical distribution network (ODN) 220. OMCI messages between the ONT 210 and the ONU 230 for management and control are similarly provided between the OLT 210 and the ONT 230 via the ODN 22. The ONT 230 provides access network line termination, user network interface line termination for subscriber devices, and service multiplexing and demultiplexing for subscriber devices.

[0063] Configuration management provides the ability to identify ONT capabilities and exercise control over the ONT. Management areas for the ONT include the configuration of (1) equipment, (2) passive optical network and reach extender protection, (3) user-network interfaces, (4) gigabit-capable passive optical network encapsulation (PON) port network contention termination points, (5) termination point interworking, (6) operations, management, and maintenance flows, (7) physical ports, (8) gigabit-capable passive optical network encapsulation (PON) adaptation layer profiles, (9) service profiles, (10) traffic descriptors, and (11) asynchronous transfer mode (ATM) adaptation layer profiles. As modeled by OMCI, the ONT detects and reports equipment, software, and interface faults and declares corresponding alarms. The ONT may be considered a managed entity through information exchange between the OLT and the ONT based on OMCI messages regarding the optical access network.

[0064] Each function associated with the capabilities and management of an ONT is described, to varying degrees, by a variety of standards, typically achieved by consensus among a diverse set of entities, each of which tends to have different views on the meaning of the descriptions within those standards. Thus, each ONT, particularly ONTs developed by different manufacturers, may have variations based on that particular manufacturer's interpretation of the various standards. This tends to be particularly true with respect to control and management functions.

[0065] The G.988 standard describes managed entities in a protocol-independent Management Information Base (MIB) that models information exchange between OLTs and ONTs within a PON-based access network that is the subject of a standard such as G.988. See G.988, i.e., ONU Management and Control Interface (OMCI) Specification, (11 / 17), G.988(2017) Amendment 1 (11 / 18), G.988(2017) Amendment 2 (08 / 19), G.988(2017) Amendment 3 (03 / 2), and G.988(2017) Amendment 4 (09 / 21), each of which is incorporated by reference in its entirety. G.988 also addresses the configuration, protocols, and message formats of the ONT Management and Control Channel (OMCC). In addition to considerations of various manufacturer interpretations of the G.988 standard, complete interoperability between different OLT and ONT manufacturers is also often not sufficient. Due to manufacturer decisions regarding implementation, various ONTs exist that simply do not comply with various standards.

[0066] Referring to Figure 8, one technique for providing OMCI messages to ONTs is for a server located in the core network (i.e., any server within the network) to create a set of virtual OMCI microservices specifically tailored to the capabilities of each ONT model from each vendor. Management data maintained by the system is typically defined in terms of a YANG data model, including modules and submodules that define configuration and status data, notifications, and remote procedure requests. A YANG module defines the data model through its data, as well as the hierarchical organization and constraints of that data. Each module is uniquely identified by a namespace URI. A module defines a single data model. However, a module can reference the definitions of other modules and submodules by importing external modules using import statements or by including one or more submodules using include statements. Additionally, a module can extend another data model by using extend statements to define the placement of the new node within the data model hierarchy and by using include statements to define the conditions under which the new node is valid. Modules use feature statements to specify conditional portions of the module and deviation statements to specify where the device implementation may deviate from the original definition. In this way, modules can have large and complex sets of conditions to accommodate various environments. The core network provides YANG requests to the OLT, which then translates the YANG requests and YANG responses and notifications into OMCI messages with the vOLTMF (vOLT Management Function), and the OLT further transmits and receives OMCI message requests, responses, and notifications to and from the ONT.

[0067] Referring to Figure 9, a high-level design of the vOLT Management Function (vOLTMF) is illustrated, which may be used to manage ONTs via vOMCI messages. Communication exists between the vOLTMF, the vOMCI proxy, and the vOMCI function based on the creation and deletion of ONTs, receiving ONT state change notifications, and transmitting requests to ONTs. The vOLTMF manages ONTs through an ONT adapter, which may be deployed as a broadband access abstraction, and the ONT adapter association is based on the model, type, vendor, and version specified when the ONT was created. The ONT adapter may use a library of YANG modules related to the ONT referenced by the vOLTMF to handle ONT requests, responses, and notifications from external management systems.

[0068] The vOLTMF performs operations upon receiving notifications and requests from the OLT device or from other components within the broadband access abstraction core. For example, an onu state change notification transmitted by the OLT device on its Northbound Interface (NBI) is received by the broadband access abstraction core. The broadband access abstraction core propagates the notification towards the vOLTMF and towards the broadband access abstraction NBI so that it can be handled by the access SDN M&C.

[0069] Upon receiving the notification, vOLTMF processes the notification, checks whether a pre-configured ONU device exists, and authenticates the ONU. vOLTMF converts the notification into Google Protobufs (GPB) format and propagates the ONU configuration communication action to the vOMCI function and the vOMCI proxy via the Kafka bus.

[0070] All YANG requests are transmitted in GPB format via the Kafka bus towards the vOMCI function and towards the vOMCI proxy. After the vOMCI function / proxy processes the request, the vOMCI function sends a notification / request response back to vOLTMF via the Kafka bus in GPB format, and the response is received via KafkaNotificationCallback#onNotification().

[0071] Upon receiving the response, the vOLTMF is responsible for processing the response and taking action accordingly.

[0072] There can be multiple interactions between vOLTMF and the vOMCI function, including parallel configuration requests / commands for the same or different ONUs. These interactions are parallel and asynchronous, so requests are not queued or blocked while waiting for a response because vOLTMF has separate task queues and thread pools to handle request / response interactions. Below is a list of vOLTMF thread pools created as new runnable tasks: processNotificationRequestPool, kafkaCommunicationPool, kafkaPollingPool, processNotificationResponsePool, and processRequestResponsePool. processNotificationRequestPool is used for mediated device event listener callbacks and to process device notification requests. kafkaCommunicationPool is used to process individual GET / COPY-CONFIG / EDIT-CONFIG requests inside the MediatedDeviceNetconfSession created by preocessRequestResponsePool. The kafkaPollingPool is used to start KafkaConsumer implementations and to poll for responses from the vOMCI function / vOMCI proxy. The processRequestResponsePool is used to process notification responses from the vOMCI function / vOMCI proxy. The processRequestResponsePool is used to process GET / COPY-CONFIG / EDIT-CONFIG requests and responses from the vOMCI function / vOMCI proxy. In general, a process may be considered as a type of protocol adapter running on an ONT that also interfaces with an OLT in a PON environment.As can be observed, the way the processing is performed is relatively complex and involves Google Protobufs, remote procedure calls, and other complex processing that requires a significant amount of computational resources to process all the microservices that are a burden to the OLT.

[0073] 10, generally, a server constructs or selects a YANG request for an ONT. The server then provides the YANG request to the OLT, which converts the YANG request into an OMCI message and transmits the OMCI message to the ONT. The OLT receives OMCI messages from the ONT and converts them into a YANG response that is provided to the server.

[0074] To maintain compliance with applicable standards, the set of Yang data models allowed for use is limited, and the remote OLT is designed to be able to process and provide responses to those data models as needed. Yang data models that do not conform to applicable standards are preferably not supported by the remote OLT, while Yang data models that conform to applicable standards are preferably supported by the remote OLT, allowing a server that conforms to the Yang data model standard to communicate effectively with a remote OLT that also conforms to the Yang data model standard. The YANG data model is provided using an extensible data model (XML).

[0075] Rather than providing extensions to the Yang data model by the remote OLT and associated server, it is desirable to include a REST API. Including a REST API adds additional computational complexity to the remote OLT while also providing an alternative interface for providing other data models that do not conform to the standard-compliant YANG data model. A REST API (also known as a RESTful API) is an application programming interface (API or Web API) that conforms to the constraints of the REST architectural style and, where appropriate, allows interaction with RESTful web services. REST is a set of architectural constraints, not a protocol or standard. Preferably, a REST API is used for communications that are, or can be, efficiently implemented using the standard-compliant Yang data model.

[0076] When a server request is made to a remote OLT via a RESTful API, a representation of the resource state is transferred to the remote OLT. This information or representation can be delivered in one of several formats, such as JSON (JavaScript Object Notation), HTML, XLT, Python, PHP, or plain text, with JSON being preferred. Note that the YANG data model is provided using XML, and the REST API-based data model is preferably provided using JSON, further increasing the complexity of the remote OLT because they use different formats.

[0077] RESTful API HTTP request headers and parameters include request metadata, authentication, a uniform resource identifier (URI), cache, cookies, and / or other identifier information. There are request and response headers, each with its own HTTP connection information and status code. REST APIs are often based on stateless server or remote OLT communication, meaning that no remote OLT information is stored between retrieved requests and that each request is separate and unconnected. Data transfer forms include ensuring that the requested resource is identifiable and distinct from the transmitted representation and / or that the representation contains sufficient information to execute the representation, so that the resource can be manipulated by the remote OLT via the received representation and / or that the self-describing message sent back to the server contains sufficient information describing how the server should process it.

[0078] The YANG server communicates with a dispatcher, which sends messages to the various microservices / threads exposed, for example, via an IPC or TCP channel. Similarly, the REST API sends messages to the dispatcher, which sends messages to the various microservices / threads exposed, for example, via an IPC or TCP channel. The YANG server and REST API provide an interface layer for the communication method, as messages from the dispatcher are preferably the same whether received from the YANG server or the REST API. Preferably, the dispatcher receives and provides message structures encoded in "C."

[0079] In some cases, implementing a specific standards-compliant YANG data model can be cumbersome and inefficient, requiring four or more YANG data model-based requests to populate multiple tables in the remote OLT so that the desired data can be determined and retrieved from the remote OLT. When standards-compliant YANG data models are limited, the REST API may include a more specific data model that requires fewer requests, preferably only a single request, for the desired data to be determined and retrieved from the remote OLT. Also, there may be some desirable information within the remote OLT and / or ONT for which standards-compliant YANG data models do not include corresponding objects, such as some device statistics. As an example, the REST API may be used to obtain information about multiple states of the ONT (more than two states), rather than simply whether it is operational or inoperable. More detailed information related to the ONT state is particularly useful for debugging. For example, the REST API may be used to obtain data or groups of data regarding any of the information described in the ONT Management and Control Interface (OMCI) Specification, G.988, November 2017.

[0080] Moreover, each functional block or various features in each of the foregoing embodiments may be implemented or performed by a circuit, typically an integrated circuit or multiple integrated circuits. Circuits designed to perform the functions described herein may include a general-purpose processor, a digital signal processor (DSP), an application-specific or general-purpose integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, or discrete hardware components, or a combination thereof. A general-purpose processor may be a microprocessor, or alternatively, the processor may be a conventional processor, controller, microcontroller, or state machine. The general-purpose processor or each circuit described above may be implemented using digital or analog circuits. Furthermore, as advances in semiconductor technology emerge, an integrated circuit based on this technology may be used to replace multiple integrated circuits currently used.

[0081] It is understood that the present invention is not limited to the particular embodiments described, and that changes may be made therein as interpreted in accordance with the principles of prevailing law, including the doctrine of equivalents or any other principle that expands the scope of enforceable claims beyond their literal scope, without departing from the scope of the invention as defined in the appended claims. Unless the context indicates otherwise, a reference in a claim to the number of instances of an element, whether to a single instance or to multiple instances, requires at least the recited number of instances of the element, but is not intended to exclude from the scope of the claim structures or methods having more instances of that element than recited. When used in the claims, the term "comprise" or derivatives thereof are used in a non-exclusive sense that is not intended to exclude the presence of other elements or steps in the claimed structure or method.

Claims

1. 1. An access network for a passive optical network, comprising: (a) a first optical line terminal including a northbound interface for transmitting and receiving data to and from a first server, (b) a first optical line terminal including a first port for transmitting and receiving optical data to and from a first set of optical network terminals via a first optical fiber; (c) a second optical line terminal including a northbound interface for transmitting and receiving data to and from a second server, (d) a second optical line terminal including a second port for transmitting and receiving optical data to and from the second set of optical network terminals via a second optical fiber; (e) the first server providing a first virtualized control plane service for the first optical line terminal, the first server and the first optical line terminal being within five miles of each other; (f) the second server providing a second virtualized control plane service for the second optical line terminal, the second server and the second optical line terminal being within 5 miles of each other; (g) the first server is at least five miles away from both the second optical line terminal and the second server; (h) the second server is at least five miles away from both the first optical line terminal and the first server; (i) an access network, wherein the first optical line terminal transmits and receives data services for the first set of optical network terminals via a core network separate from both the first server and the second server, and the second optical line terminal transmits and receives data services for the second set of optical network terminals via the core network separate from both the first server and the second server.

2. 2. The access network of claim 1, wherein the first server is at least 10 miles away from both the second optical line terminal and the second server, and the second server is at least 10 miles away from both the first optical line terminal and the first server.

3. 2. The access network of claim 1, wherein the first server is at least 20 miles away from both the second optical line terminal and the second server, and the second server is at least 20 miles away from both the first optical line terminal and the first server.

4. 2. The access network according to claim 1, wherein the first server and the first optical line terminal are within two miles of each other, and the second server and the second optical line terminal are within two miles of each other.

5. 2. The access network of claim 1, wherein the first server and the first optical line terminal are within 1 / 4 mile of each other, and the second server and the second optical line terminal are within 1 / 4 mile of each other.

6. 2. The access network of claim 1, wherein the first server is at least 20 miles away from both the second optical line terminal and the second server, the second server is at least 20 miles away from both the first optical line terminal and the first server, the first server and the first optical line terminal are within 1 / 4 mile of each other, and the second server and the second optical line terminal are within 1 / 4 mile of each other.

7. 1. An access network for a passive optical network, comprising: (a) a first optical line terminal including a northbound interface for transmitting and receiving data to and from a first server, (b) a first optical line terminal including a first port for transmitting and receiving optical data to and from a first set of optical network terminals via a first optical fiber; (c) the first server providing a first virtualized control plane service for the first optical line terminal, the first server and the first optical line terminal being within 5 miles of each other; (d) the first optical line terminal transmits and receives data services for the first set of optical network terminals via a core network separate from the first server; (e) the first optical line terminal includes a processing system including a single chip including (1) a field programmable gate array and (2) a microprocessor having a fixed set of instructions; (f) a portion of the first virtualized control plane service is selectively processed by either (1) the microprocessor using a portion of the fixed set of instructions and (2) the first server; (g) An access network, wherein dynamic bandwidth allocation for the first optical line terminal is processed by the field programmable gate array and not by the first server.

8. 8. The access network of claim 7, wherein the first optical line terminal and the first server are within 5 miles of each other, and the core network is at least 5 miles away from both the first optical line terminal and the first server.

9. 1. An access network for a passive optical network, comprising: (a) a first optical line terminal including a northbound interface for transmitting and receiving data to and from a core network, (b) a first optical line terminal including a first port for transmitting and receiving optical data to and from a first set of optical network terminals via a first optical fiber; (c) the core network providing a first virtualized control plane service for the first optical line terminal; (d) the first optical line terminal includes a processing system including a single chip containing (1) a field programmable gate array and (2) a microprocessor having a fixed set of instructions; (e) a portion of the first virtualized control plane service is selectively processed by either (1) the microprocessor using a portion of the fixed set of instructions; or (2) the first server; (f) an access network in which dynamic bandwidth allocation for the first optical line terminal is processed by the field programmable gate array and not by the first server.

10. 1. An optical line terminal for a passive optical network, comprising: (a) the optical line terminal includes a northbound interface for transmitting and receiving data to and from a core network; (b) the first optical line terminal includes a first port for transmitting and receiving optical data to and from a first set of optical network terminals via a first optical fiber; (c) transmitting data to at least one optical network terminal using the optical network unit management and control interface messages based on the optical line terminal receiving at least one YANG data model that is converted by the optical line terminal into an optical network unit management and control interface message; (c) the optical line terminal transmits data to at least one optical network terminal using the optical network unit management and control interface messages based on the optical line terminal receiving at least one REST API data model that is converted by the optical line terminal into an optical network unit management and control interface message.

Images