OLT interoperable with different ONTs

Abstract

A system having OLTs with mesh interconnections.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 397,735, filed August 12, 2022.

[0002] The subject matter of this application relates to OLTs with mesh interconnections. [Background technology]

[0003] Passive optical networks (PONs) are often employed as access networks, or portions of larger communications networks. Communications networks typically have a high-capacity core section through which data or other information related to telephone calls, digital television, and Internet communications is transmitted over significant distances. The core section may have the ability to interact with other networks to complete the transmission of telephone calls, 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 fixed access, such as a passive optical network or a cable network.

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

[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 cabinet or other structure in which one or more optical splitters 12 are located, each serving a respective set of ONTs. In some cases, an ONT may serve multiple subscribers, such as subscribers in multiple dwelling units (e.g., apartments). In this way, a PON can be considered a point to multipoint topology, in which 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, interfacing directly or indirectly with 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 distributes 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 observed, an optical signal containing all of the data for ONT 11 is provided to feeder fiber 17. Thus, all of the data provided to each of the ONTs is provided to all of the ONTs through optical splitter 12. Each ONT selects the portion of the received optical signal intended for that particular ONT and passes the data on to the subscriber while simultaneously discarding the remaining data. Typically, data to the ONTs is broadcast to 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 sent in bursts according to a schedule provided to each ONT by the 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 sent using different wavelengths of light so that they do not interfere with each other. In this manner, a PON may utilize wavelength division multiplexing, using one wavelength for downstream traffic and another wavelength for upstream traffic over a single-mode fiber.

[0010] A schedule from the OLT allocates upstream bandwidth to ONTs. Because the optical distribution network is shared, ONT 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 sets registers in each ONT to equalize that delay with respect to other ONTs associated with the OLT. Once the delay is accounted for, the OLT sends so-called grants to individual ONTs 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 a 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] 1 illustrates a network that includes a passive optical network. [Figure 2] 1 illustrates OMCC messages provided to and from ONTs in a passive optical network. [Figure 3] 1 illustrates an example process flow of an OMCI message for managing an ONT in a passive optical network. [Figure 4] 1 illustrates a vOLT management function for managing ONTs through vOMCI messages in a passive optical network. [Figure 5]1 illustrates an exemplary YANG model selection. [Figure 6] 1 illustrates an exemplary technique for providing firmware updates to an OLT. [Figure 7] 1 illustrates another exemplary technique for providing firmware updates to an OLT. [Figure 8] 1 illustrates another exemplary technique for providing firmware updates to an OLT. DETAILED DESCRIPTION OF THE INVENTION

[0013] Referring to Figure 2, the core network and / or optical line terminal provides management and control functions on 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 PON protocols via an optical distribution network (e.g., optical splitter) 220. The OLT 210 passes data to the ONT 230 through the optical distribution network (ODN) 220 and receives data from the ONT 230 through the optical distribution network (ODN) 220. OMCI messages between the ONT 210 and ONT 230 for management and control are similarly provided between the OLT 210 and ONT 230 through 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.

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

[0015] Each of the capabilities and management-related functions of an ONT are described in a more or less concise manner by various standards, which are typically achieved by consensus among a diverse set of entities, each of which tends to have a different perspective on the meaning of the standard's descriptions. Thus, each ONT, especially ONTs developed by different manufacturers, may have variations based on the particular manufacturer's interpretation of the various standards. This tends to be particularly true for control and management functions.

[0016] The G.988 standard describes management entities in a protocol-independent management information base (MIB) that models the information exchange between OLTs and ONTs in PON-based access networks that are the subject of standards such as G.988: ONU management and control interface (OMCI) specification (November 17), G.988(2017) Amendment 1 (November 18), G.988(2017) Amendment 2 (August 19), G.988(2017) Amendment 3 (March 2), and G.988(2017) Amendment 4 (March 2). 4 (09 / 21), each of which is incorporated herein by reference in its entirety. G.988 also addresses ONT management and control channel (OMCC) setup, protocols, and message formats. In addition to considerations of various manufacturer interpretations of the G.988 standard, it is often not sufficient for complete interoperability between different OLT and ONT manufacturers. The G.988 standard also does not define the large-scale sequencing of actions in the delivery of complex services. Furthermore, the G.988 standard is not adapted to accommodate multi-channel PON systems and has not been extended to fully address the characteristics and requirements of multi-channel PON systems. Also, there are ONTs that simply do not comply with various standards due to manufacturer decisions to do so.

[0017] Referring to Figure 3, one technique for providing OMCI messages to the ONT is to create a virtual OMCI set of microservices for servers in the core network (i.e., any server in the network) specifically tailored to the functionality of each ONT model from each vendor. The management data maintained by the system is typically defined in terms of a YANG data model, which includes modules and submodules that define configuration and status data, notifications, and remote procedure calls. A YANG module defines the data model through its data and defines 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 the import statement or by including one or more submodules using the include statement. Furthermore, a module can extend another data model by using the augment statement to define the placement of a new node in the data model hierarchy and the when statement to define the conditions under which the new node is valid. A module uses the feature statement to specify the parts of the module that are conditional and the deviation statement to specify where the device implementation may deviate from the original definition. In this way, the module can have a large and complex set of conditions that correspond to various environments. The core network provides YANG requests to the OLT, and the OLT then converts the YANG requests, responses, and notifications into OMCI messages with the vOLTMF (vOLT Management Function), and the OLT sends and receives OMCI message requests, responses, and notifications with the ONT.

[0018] Referring to Figure 4, a high-level design of the vOLT Management Function (vOLTMF) is illustrated, which may be used to manage ONTs through vOMCI messages. Communication between the vOLTMF, vOMCI proxy, and vOMCI functions is based on creating and deleting ONTs, receiving ONT state change notifications, and sending requests to ONTs. The vOLTMF manages ONTs through an ONT adapter, which may be deployed as a broadband access abstraction, and its association is based on the model, type, vendor, and version mentioned when creating the ONT. The ONT adapter may use a library of YANG modules for the ONT pointed to by the vOLTMF to process ONT requests, responses, and notifications from an external management system.

[0019] The vOLTMF performs actions upon receiving notifications and requests from the OLT device or other components within the broadband access abstraction core. For example, an ONU state change notification sent 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 to the vOLTMF and the broadband access abstraction NBI, which can then be processed by the access SDN M&C.

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

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

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

[0023] There can be multiple interactions between vOLTMF and vOMCI functions, including parallel configuration requests / commands for either the same or different ONTs. These interactions are parallel and asynchronous, and vOLTMF has separate task queues and thread pools to handle request / response interactions so requests are not idle / blocked while waiting for a response. Below is a list of vOLTMF thread pools spawned as new runnable tasks: processNotificationRequestPool, kafkaCommunicationPool, kafkaPollingPool, processNotificationResponsePool, and processRequestResponsePool. processNotificationRequestPool is used to process mediated device event listener invocations and device notification requests. kafkaCommunicationPool is used to process individual GET / COPY-CONFIG / EDIT-CONFIG requests within the MediatedDeviceNetconfSession spawned by preocessRequestResponsePool. The kafkaPollingPool improves the implementation of KafkaConsumer and is used 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 can be seen as a kind of protocol adapter running on the ONT that also interfaces with the OLT in a PON environment. As can be observed, the way in which processing is performed is relatively complex, including Google Protobufs, remote procedure calls, and other complexities, and requires a considerable amount of computational resources to process all the microservices that burden the OLT.

[0024] 5, upon determining that the ONT is inconsistent in its intended functionality, the server constructs or otherwise selects a specific YANG request for the particular ONT based on an identification of the nature of the particular ONT. For example, this identification may be based on a device ID, a vendor-specific product code attribute, and / or a vendor ID attribute, which may be obtained from the ONT or otherwise maintained in a database. The server then provides the specific YANG request to the OLT, which converts the YANG request into an OMCI message and sends such an OMCI message to the ONT. The OLT receives the OMCI messages from the ONT and converts them into YANG responses, which are provided to the server.

[0025] When OMCI messaging is used for minor changes requiring relatively small amounts of data, such as setting up a connection or requesting status, the impact on the OLT's computational resources is limited. OMCI messaging is based on each message being 53 bytes long with a 31-byte data payload. Therefore, up to several hundred requests may be required to set up a connection and request status. When performed on one or a limited number of ONTs at a time, several hundred requests tend not to substantially impact the OLT's computational resources.

[0026] OMCI messaging may be used to provide firmware image updates to each ONT so that the ONT's firmware can be updated. Firmware is relatively large compared to the transmission of control or management messages. Therefore, downloading an updated firmware image may require more than 80,000 OMCI messages. Due to the relatively complex process of gRPC protocol conversion, the OLT must consume a significant amount of its computing resources to perform protocol conversion and OMCI messaging for such a large number of messages. As an example, it may take more than 3 to 7 minutes to perform gRPC protocol conversion and transfer an updated firmware image to the ONT using OMCI messaging.

[0027] An OLT may provide service to thousands (e.g., 2,000 or more) of ONTs accessed through an optical distribution network. Often, most, if not all, ONTs need to be updated when a firmware update is released. The OLT typically only has the computational resources to perform the processing required to provide updated firmware to a single ONT at a time, which may take seven minutes. For an exemplary 2,000 ONTs updating at seven minutes per firmware update, it would take the OLT 14,000 minutes (i.e., approximately 233 hours, or approximately 9.75 days) to contend for the firmware update. However, if the service window during which updates are performed is three hours per day, it would take approximately 78 days to contend for the firmware update, which is a particularly long time. Furthermore, because OMCI messaging is point-to-point traffic where data (e.g., firmware images) are designated for a single ONT, there is no opportunity to simultaneously send the same firmware update to update multiple ONTs.

[0028] After further consideration, it was determined that the use of OMCI (Optical Network Unit Management and Control Interface) protocol messages conveyed over the ONT Management Control Channel (OMCC), specifically designed for the control and management of ONTs, should not be used to update the firmware image of an ONT. Rather, an extended OMCC (Optical Network Unit Management and Control Channel) based on Internet packet-sized data packets with approximately 1980 bytes of payload data and limited overhead signaling for the payload data should be used, rather than based on OMCI messages, which reduces overhead signaling. Furthermore, by using the extended OMCC channel, the OLT does not need to perform YANG protocol conversion, thus further reducing the computational burden on the OLT. In this way, because the extended OMCC does not use OMCI messages conveyed over the OMCC channel, the OLT has a lower computational load per byte. The reduced signaling and increased data payload size make firmware image downloads substantially faster.

[0029] Referring to FIG. 6, one technique for determining the manner in which to provide a firmware update to a particular ONT may be based on the specific identification of the ONT, i.e., its vendor product code attribute, which provides a vendor-specific product code for the ONT, and its vendor ID attribute, which identifies the ONT's vendor as the most significant four bytes of the ONT serial number. The server and / or OLT may obtain the vendor-specific product code attribute and the vendor ID attribute using OMCI messages. The attributes may also be stored in a database available for inspection. If the vendor-specific product code attribute and the vendor ID attribute indicate that the ONT can receive data using extended OMCC, the firmware update is provided using this technique. If the vendor-specific product code attribute and the vendor ID attribute indicate that the ONT cannot receive data using extended OMCC, the firmware update is provided using OMCI messaging. In some cases, an ONT may not explicitly indicate that it supports extended OMCC, but that supporting such extended OMCC only supports downloaded actions and not uploaded actions, which may be based on vendor product code information obtained by the OLT or otherwise known to the system.

[0030] 7, another technique for determining how to provide a firmware update is to use OMCI messaging to query the ONT device ID to determine whether extended OMCC is available. If the device ID indicates that the ONT can receive data using extended OMCC, the firmware update is provided using this technique. Alternatively, the firmware update is provided using OMCI messaging.

[0031] Referring to Figure 8, another technique for determining the manner in which to provide the firmware update is to first use extended OMCC to provide the firmware update to the ONT. If the ONT does not respond by returning an error message to the OLT, extended OMCC continues to be used until the firmware update is completed for the ONT. However, if an attempt to use extended OMCC results in an error message from the ONT to the OLT, the OLT switches to using OMCI messaging to provide the firmware update to the ONT. In this way, one of the techniques for providing the firmware image to the ONT can be determined as a result of the error message.

[0032] In many cases, a server creates firmware images that are downloaded to a set of ONTs, and then the OLT sequentially distributes the firmware images to the ONTs using extended OMCC and / or OMCI messaging. However, it has been determined that during this process, firmware images tend to change periodically, and therefore, if several firmware images are sequentially transferred to the OLT while the OLT is still processing and transmitting previous firmware images, the storage capabilities of the OLT may be insufficient to provide temporary storage for any additional firmware images that are subsequently processed while the previous firmware images have not yet been processed and transmitted to a particular ONT. Therefore, it is desirable for the server and / or OLT to limit the number of firmware images stored for subsequent processing by the OLT until sufficient storage capacity is available.

[0033] Furthermore, 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. A circuit 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 by digital circuits or analog circuits. Furthermore, as advances in semiconductor technology allow integrated circuits to replace multiple integrated circuits today, integrated circuits based on this technology may also be used.

[0034] It will be 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 doctrine 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 one 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. As used in the claims, the term "comprise" or its derivatives is used in a non-exclusive sense, which is not intended to exclude the presence of other elements or steps in the claimed structure or method.

Claims

1. An optical line terminal, (a) the optical line terminal includes a northbound interface for receiving and transmitting data to and from a server, respectively; (b) the optical line termination includes at least one port for receiving and transmitting optical data to and from an optical network termination over an optical fiber; (c) at least one of the server and the optical line termination device examining a vendor specific generated code attribute of the optical line termination device and a vendor ID attribute as the most significant four bytes of a serial number for the optical network termination device to determine whether the optical network termination device is capable of receiving firmware updates using an extended optical network termination device management and control channel; (d) based on said determining, alternatively, (1) the optical line terminal sends the firmware update to the optical network terminal using the extended optical network terminal management and control channel; and (2) the optical line terminal sends the firmware update to the optical network terminal using an optical network unit management and control interface message based on said optical line terminal receiving a YANG data model, wherein the YANG data model is converted by the optical line terminal into the optical network unit management and control interface message.

2. 2. The optical line terminal of claim 1, wherein the at least one of the server and the optical line terminal obtains the vendor-specific generated code attribute and the vendor ID attribute from the optical network terminal using an optical network unit management and control interface message to the optical network terminal.

3. An optical line terminal, (a) the optical line terminal includes a northbound interface for receiving and transmitting data to and from a server, respectively; (b) the optical line termination includes at least one port for receiving and transmitting optical data to and from an optical network termination over an optical fiber; (c) at least one of the server and the optical line termination examining a device ID of the optical network termination to determine whether the optical network termination is capable of receiving firmware updates using an enhanced optical network termination management and control channel; (d) based on said determining, alternatively, (1) the optical line terminal sending the firmware update to the optical network terminal using the extended optical network terminal management and control channel, and the optical line terminal sending the firmware update to the optical network terminal using an optical network unit management and control interface message based on the optical line terminal receiving a YANG data model, wherein the YANG data model is converted by the optical line terminal into the optical network unit management and control interface message.

4. 4. The optical line terminal of claim 3, wherein the at least one of the server and the optical line terminal obtains the device ID of the optical network terminal using an optical network unit management and control interface message to the optical network terminal.

5. An optical line terminal, (a) the optical line terminal includes a northbound interface for receiving and transmitting data to and from a server, respectively; (b) the optical line termination includes at least one port for receiving and transmitting optical data to and from an optical network termination over an optical fiber; (c) the optical line terminal sending a firmware update to the optical network terminal using an extended optical network terminal management and control channel, and in response to receiving an error as a result of using the extended optical network terminal management and control channel, the optical line terminal sending the firmware update to the optical network terminal using an optical network unit management and control interface message based on the optical line terminal receiving a YANG data model, wherein the YANG data model is converted by the optical line terminal into the optical network unit management and control interface message.

6. An optical line terminal, (a) the optical line terminal includes a northbound interface for receiving and transmitting data to and from a server, respectively; (b) the optical line termination includes at least one port for receiving and transmitting optical data to and from an optical network termination over an optical fiber; (c) the optical line terminal receiving, from a server, a YANG request based on the identified attributes of the optical network terminal, and in response, translating the YANG request to the optical network terminal using an optical network unit management and control interface message.

7. The optical line terminal of claim 6, wherein the identification is based on a device ID, a vendor specific product code attribute, and / or a vendor ID attribute of the optical network termination device.

Images