Dynamic selection of management information bases

A method, a device, and a non-transitory storage medium provide to transmit to an optical network unit, a first message that queries the optical network unit for managed information bases supported by the optical network unit; receive a second message from the optical network unit, which indicates the managed information bases supported by the optical network unit; compare the managed information bases supported by the optical line terminal with the managed information bases supported by the optical network unit; select one of the managed information bases supported by the optical line terminal that is also supported by the optical network unit; transmit to the optical network unit, a third message, which indicates the selected managed information base supported by the optical line terminal and the optical network unit; and receive a fourth message from the optical network unit, which indicates whether the selected managed information bases is successfully instantiated.

BACKGROUND

In a passive optical network (PON), an optical line termination (OLT) (also known as an optical line terminal) manages an optical network unit (ONU) or an optical network termination (ONT) (also known as an optical network terminal) based on messaging via an Optical Management Communications Interface (OMCI) channel. For example, the OMCI channel is used to read and write attributes of managed entities (MEs). A managed entity is a representation of a logical element or a physical element of the ONU or the ONT.

In 2010, the International Telecommunication Union-Telecommunication (ITU-T) authored an OMCI specification known as Recommendation G.988. Recommendation G.988 specifies, among other things, the managed entities of a protocol-independent management information base (MIB) that models the exchange of information between the OLT and the ONU.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

ITU-T Recommendation G.988 (Oct. 2012), which is incorporated in its entirety by reference, defines a number of options that are left for vendor preference, such as specifying proprietary managed entities, attributes, and methods within what is known as “vendor-specific” code point space. Recommendation G.988 also omits coverage on some high-scale sequencing of actions in the provisioning of complex services.

In PON deployments, the OLT and the ONU are typically from the same vendor or the same partner vendor. This framework effectively encourages single-vendor non-interoperable PON environments. Unfortunately, there are not current standards or procedures to support dynamic selection of G.988-compliant managed information bases (MIBs) involving OLTs and ONUs that are not from the same vendor or the same partner vendor.

According to exemplary embodiments, an MIB configuration service is described. According to exemplary embodiments, the MIB configuration service provides interoperability between optical equipment from different vendors in a PON. For example, the optical equipment may be an OLT of a service provider endpoint, and an ONU at the customer premise. The term ONU is intended to be broadly interpreted as an ONU, an ONT, a Multi-Dwelling Unit (MDU), or a Single Family Unit (SFU). The MIB configuration service may be implemented in various types of PONs, such as, for example, a Gigabit PON (GPON), a 10G-PON, a 10G Symmetrical PON (XGS-PON), an Ethernet PON (EPON), a 10G-EPON, a Next Generation-PON2 (NG-PON2), or other type of legacy, current, or future generation PON.

According to an exemplary embodiment, a managed entity is instantiated, at the ONU, which reports the various MIBs supported by the ONU. According to an exemplary implementation, the managed entity is instantiated autonomously by the ONU. According to another exemplary implementation, the managed entity is instantiated based on a request from the OLT. For example, the OLT may issue a create command or action to the ONU for instantiating the managed entity.

According to an exemplary embodiment, the OLT selects one of the reported MIBs. According to an exemplary implementation, the OLT selects the MIB based on the application (e.g., business applications, voice-only applications, SFU applications, etc.) for which the ONU is targeted. According to an exemplary embodiment, the OLT directs the ONU to use the selected MIB. According to an exemplary implementation, the OLT sets an attribute value of the managed entity that indicates the selected MIB.

According to an exemplary embodiment, the ONU attempts to use the selected MIB. According to an exemplary embodiment, the ONU reports the success or failure of the use of the selected MIB to the OLT. When the report indicates success, the OLT may monitor the status of the running of the selected MIB. Additionally, for example, when OLT redundancy is used and/or OLT control software switchover is used, an OLT may query the ONU to determine which MIB the ONU is currently supporting or running. According to an exemplary implementation, the ONU sets an attribute value of the managed entity that indicates the MIB currently running. The OLT may periodically or otherwise monitor the attribute value. When the report indicates failure, the OLT may select another one of the reported MIBs.

According to another exemplary embodiment, a managed entity is instantiated, at the ONU, which allows the OLT to challenge the ONU to instantiate a MIB, which is supported by the OLT, and to receive a response from the ONU that indicates whether the MIB is successfully instantiated. According to an exemplary implementation, the managed entity is instantiated autonomously by the ONU. According to another exemplary implementation, the managed entity is instantiated based on a request from the OLT. For example, the OLT may issue a create command or action to the ONU for instantiating the managed entity.

According to an exemplary embodiment, the OLT reports a list of one or multiple MIBs, which the OLT supports, to the ONU. According to an exemplary embodiment, the ONU selects one of the reported MIBs when the ONU determines it supports one of the reported MIBs. According to an exemplary embodiment, the ONU attempts to use the selected MIB. According to an exemplary embodiment, the ONU reports the success or failure of the use of the selected MIB to the OLT. When the report indicates success, the OLT may monitor the status of the running of the selected MIB. According to an exemplary implementation, the ONU sets an attribute value of the managed entity that indicates the MIB currently running. The OLT may periodically or otherwise monitor the attribute value. When the report indicates failure, the ONU may select another one of the reported MIBs. According to an exemplary embodiment, when the ONU determines that it does not support any MIB included in the list, the ONU transmits a message to the OLT indicating that it does not support any MIB included in the list.

FIG. 1is a diagram illustrating an exemplary environment100in which an exemplary embodiment of a MIB configuration service may be implemented. As illustrated, environment100includes a central office105. Central office105includes an OLT110. Additionally, environment100includes an optical distribution network (ODN)115, and ONUs125-1through125-Z (also referred to as ONUs125, or individually or generally as ONU125). The connections between OLT110, ODN115, and ONU125include optical fibers. According to an exemplary embodiment, OLT110, ODN115, and ONU125form a PON.

The number and arrangement of devices in environment100are exemplary. According to other embodiments, environment100may include additional devices and/or differently arranged devices, than those illustrated inFIG. 1. Additionally, the number and arrangement of connections are exemplary.

Central office105is a distribution node of a service provider. Central office105hosts OLT110and other elements not illustrated (e.g., an optical distribution frame (ODF), etc.), and provides electrical power. According to various exemplary implementations, central office105may or may not include core network equipment. For example, the core network equipment may include television provider equipment, Internet provider equipment, and/or telephone provider equipment (e.g., packet-switched, etc.).

OLT110includes an optical device that performs various functions, such as traffic scheduling, buffer controlling, and bandwidth allocating. According to exemplary embodiments, OLT110includes logic that provides the MIB configuration service, as described herein.

ODN115includes an optical network that provides an optical transmission medium for the connection between OLT110and ONUs125. Although not illustrated, ODN115may include optical fibers, fiber optic connectors, optical splitters/combiners, and other passive optical components.

ONU125includes an optical device that provides network-side line termination and user-side line termination functions. For example, ONU125performs various functions, such as converting an optical signal in the optical fiber to electrical form, and multiplexing and de-multiplexing. ONU125may be connected to various end devices or user devices. According to exemplary embodiments, ONU125includes logic that provides the MIB configuration service, as described herein.

FIG. 2is a diagram illustrating exemplary components of a device200that may be included in one or more of the devices described herein. For example, some or all of the components of device200may be included in OLT110and ONU125. As illustrated inFIG. 2, device200includes a bus205, a processor210, a memory/storage215that stores software220and other data, a communication interface225, an input230, and an output235. According to other embodiments, device200may include fewer components, additional components, different components, and/or a different arrangement of components than those illustrated inFIG. 2and described herein. Additionally, or alternatively, according to other embodiments, multiple components may be combined into a single component. For example, processor210, memory/storage215, and communication interface225may be combined.

Bus205includes a path that permits communication among the components of device200. For example, bus205may include a system bus, an address bus, a data bus, and/or a control bus. Bus205may also include bus drivers, bus arbiters, bus interfaces, clocks, and so forth.

Processor210may control the overall operation or a portion of operation(s) performed by device200. Processor210may perform one or multiple operations based on an operating system and/or various applications or computer programs (e.g., software220). Processor210may access instructions from memory/storage215, from other components of device200, and/or from a source external to device200(e.g., a network, another device, etc.). Processor210may perform an operation and/or a process based on various techniques including, for example, multithreading, parallel processing, pipelining, interleaving, etc.

Memory/storage215includes one or multiple memories and/or one or multiple other types of storage mediums. For example, memory/storage215may include one or multiple types of memories, such as random access memory (RAM), dynamic random access memory (DRAM), cache, read only memory (ROM), a programmable read only memory (PROM), a static random access memory (SRAM), a single in-line memory module (SIMM), a dual in-line memory module (DIMM), a flash memory, and/or some other type of memory. Memory/storage215may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, etc.), a Micro-Electromechanical System (MEMS)-based storage medium, and/or a nanotechnology-based storage medium. Memory/storage215may include drives for reading from and writing to the storage medium.

Memory/storage215may be external to and/or removable from device200, such as, for example, a Universal Serial Bus (USB) memory stick, a dongle, a hard disk, mass storage, off-line storage, or some other type of storing medium (e.g., a compact disk (CD), a digital versatile disk (DVD), a Blu-Ray disk (BD), etc.). Memory/storage215may store data, software, and/or instructions related to the operation of device200.

Software220includes an application or a program that provides a function and/or a process. As an example, with reference to OLT110and ONU125, software220may include an application that, when executed by processor210, provides the functions of the MIB configuration service, as described herein. Software220may also include firmware, middleware, microcode, hardware description language (HDL), and/or other form of instruction. Software220may include an operating system.

Communication interface225permits device200to communicate with other devices, networks, systems, and/or the like. Communication interface225includes one or multiple optical interfaces. Communication interface225may include one or multiple wired and/or wireless interfaces. Communication interface225includes one or multiple transmitters and receivers, or transceivers. Communication interface225may operate according to a protocol stack and a communication standard. Communication interface225may include one or multiple line cards. For example, communication interface225may include processor210, memory/storage215, and software220.

Input230permits an input into device200. For example, input230may include a keyboard, a mouse, a display, a touchscreen, a touchless screen, a button, a switch, an input port, speech recognition logic, and/or some other type of visual, auditory, tactile, etc., input component. Output235permits an output from device200. For example, output235may include a speaker, a display, a touchscreen, a touchless screen, a light, an output port, and/or some other type of visual, auditory, tactile, etc., output component.

Device200may perform a process and/or a function, as described herein, in response to processor210executing software220stored by memory/storage215. By way of example, instructions may be read into memory/storage215from another memory/storage215(not shown) or read from another device (not shown) via communication interface225. The instructions stored by memory/storage215cause processor210to perform a process described herein. Alternatively, for example, according to other implementations, device200performs a process described herein based on the execution of hardware (processor210, etc.).

FIGS. 3A and 3Bare diagrams illustrating exemplary processes of exemplary embodiments of the MIB configuration service. As illustrated, according to various embodiments, the MIB configuration service provides for the exchange of messages. The messages described are exemplary. According to an exemplary embodiment, the messages are exchanged via the OMCI channel established between OLT110and ONU125. According to an exemplary implementation, the messages are exchanged via the OMCI channel according to a master-slave management protocol in which OLT110is the master and ONU125is the slave. According to other exemplary implementations, one or multiple messages, as described herein, may be transmitted by ONU125to OLT110in an autonomous or non-master-slave manner. Additionally, according to various exemplary implementations, fewer, additional, and/or different messages may be exchanged.FIGS. 3A and 3Bare further described in reference to the flow diagrams illustrated inFIGS. 4 and 5.

FIGS. 4A and 4Bare diagrams illustrating an exemplary process400of the MIB configuration service. OLT110and ONU125perform steps of process400. For example, processor210executes software220to perform the steps illustrated inFIGS. 4A and 4B, and described herein.FIG. 3Aillustrates exemplary operations performed and messages exchanged between OLT110and ONU125in accordance with process400.

Referring toFIG. 4A, block402, a managed entity is instantiated at an ONU. For example, ONU125instantiates the managed entity302. According to an exemplary embodiment, the managed entity supports a reporting to OLT110of the MIB(s) ONU125can implement. As described herein, the managed entity includes various attributes and each attribute may be assigned an attribute value.

According to an exemplary implementation, the managed entity is instantiated during boot-up of ONU125. For example, the managed entity may be instantiated during a power-up cycle, a system restart, a software restart, or during some other initialization process performed by ONU125. According to other exemplary implementations, the managed entity is instantiated subsequent to boot-up of ONU125. For example, the managed entity may be instantiated after a control channel (e.g., an OMCI channel) is established between OLT110and ONU125, after ONU125registers with OLT110, after a command to create the managed entity is received from OLT110via the control channel, or responsive to some other triggering event or time (e.g., invoked by a human operator, a change in hardware, etc.).

In block404, a list of one or multiple MIBs supported by the ONU is stored. For example, ONU125stores data indicating the one or multiple MIBs304supported by ONU125. As an example, ONU125may store data indicating a type of MIB (e.g., G.988 edition 2.0; XYZ vendor, version 3.1; etc.).

In block406, an OLT queries the ONU for supported MIB(s). For example, OLT110generates and transmits a message to ONU125via the control channel. The message includes data that queries ONU125to provide one or multiple MIB(s)306supported by ONU125.

In block408, the supported MIB(s) is/are transmitted to the OLT. For example, in response to receiving and analyzing the message from OLT110, ONU125retrieves the stored data indicating the one or multiple MIBs supported. ONU125generates and transmits a message, which carries data indicating the supported MIB(s)308, to OLT110. The message may also carry data pertaining to the managed entities afforded under the supported MIB.

In block410, one of the supported MIB(s) is selected by the OLT. For example, in response to receiving and analyzing the message from ONU125, OLT110selects one of the supported MIB(s)312indicated in the message. According to an exemplary implementation, OLT110compares the supported MIB(s) of ONU125with supported MIBs of OLT110, which are stored by OLT110. Based on the result of the comparison, OLT110identifies one or multiple mutually supported MIBs. According to an exemplary implementation, OLT110selects the MIB (e.g., a single MIB), which may be from among multiple supported MIBs, based on the applications and/or services for which ONU125is targeted. By way of example, OLT110may determine the types of applications and/or services regarding ONU125during the registration process with ONU125.

In block412, the selected MIB is transmitted to the ONU. For example, OLT110transmits a message314, which indicates the selected MIB, to ONU125. According to an exemplary implementation, an attribute value of the managed entity indicates the selected MIB.

In block414, it is determined whether the selected MIB is successfully used. For example, in response to receiving and analyzing the message from OLT110, ONU125attempts to instantiate the selected MIB318.

When the selected MIB is successfully used (block414—YES), a message, which indicates that the selected MIB is successfully used, is transmitted to the OLT (block416). For example, when ONU125successfully instantiates the selected MIB, ONU125generates and transmits a message320, which indicates that the selected MIB is successfully instantiated, to OLT110. In response to receiving and analyzing the message, the OLT determines whether to select another MIB322. For example, in this case, when the selected MIB is successfully instantiated, OLT110determines that another MIB selection is not necessary.

Referring toFIG. 4B, in block418, an attribute value of the managed entity, which indicates that the selected MIB is successfully running on the ONU, is populated. For example, ONU125sets the attribute value324of the managed entity316.

In block420, the attribute value is monitored by the OLT. For example, OLT110may periodically and/or aperiodically read the attribute value326so as to identify the MIB currently running on the ONU125.

Referring back toFIG. 4A, when the selected MIB is not successfully used (block414-NO), a message, which indicates that the selected MIB is not successfully used, is transmitted to the OLT (block422). For example, when ONU125fails to instantiate the selected MIB (e.g., due to error, etc.), ONU125generates and transmits a message320, which indicates that the selected MIB is not successfully instantiated, to OLT110. As illustrated inFIG. 4A, process400may return to block410. For example, in response to receiving and analyzing the failure message from ONU125, OLT110may select another one of the mutually supported MIBs in view of the types of applications and/or services regarding ONU125.

AlthoughFIGS. 4A and 4Billustrate an exemplary process400of the MIB configuration service, according to other embodiments, process400may include additional operations, fewer operations, and/or different operations than those illustrated inFIGS. 4A and 4B, and described herein. For example, in block420, when OLT redundancy and/or OLT control software switchover is used, an OLT, other than OLT110, may query and/or monitor the attribute value so as to identify the MIB currently running on ONU125.

FIG. 5is a diagram illustrating another exemplary process500of the MIB configuration service. According to an exemplary embodiment, OLT110and ONU125perform steps of process500. For example, processor210executes software220to perform the steps illustrated inFIG. 5, and described herein.FIG. 3Billustrates exemplary operations performed and messages exchanged between OLT110and ONU125in accordance with process500. According to this example, it is assumed that ONU125supports at least one MIB in common with OLT110.

Referring toFIG. 5, in block502, a managed entity is instantiated at an ONU. For example, ONU125instantiates the managed entity340. According to an exemplary embodiment, the managed entity allows OLT110to challenge ONU125with a MIB to instantiate, which is supported by OLT110, and to receive a response from ONU125that indicates whether the MIB is successfully instantiated by ONU125. As described herein, the managed entity includes various attributes, each attribute being assigned an attribute value.

According to an exemplary implementation, the managed entity is instantiated during boot-up of ONU125. For example, the managed entity may be instantiated during a power-up cycle, a system restart, a software restart, or during some other initialization process performed by ONU125. According to other exemplary implementations, the managed entity is instantiated subsequent to boot-up of ONU125. For example, the managed entity may be instantiated after a control channel (e.g., an OMCI channel) is established between OLT110and ONU125, after ONU125registers with OLT110, after a command to create the managed entity is received from OLT110via the control channel, or responsive to some other triggering event or time (e.g., invoked by a human operator, a change in hardware, etc.).

In block504, the MIB(s) supported by the ONU are stored. For example, ONU125stores data indicating the one or multiple MIBs342supported by ONU125. As an example, ONU125may store data indicating a type of MIB (e.g., G.988 edition 2.0; XYZ vendor, version 3.1; etc.).

In block506, a supported MIB(s) is selected by the OLT. For example, OLT110stores data that indicates the type of MIBs supported by OLT110. According to an exemplary implementation, OLT110selects the supported MIB(s)344based on an order of preference. For example, the order of preference may be an administrative configuration. According to another exemplary implementation, OLT110selects the supported MIB(s)344based on the applications and/or services for which ONU125is targeted. By way of example, OLT110may determine the types of applications and/or services regarding ONU125during the registration process with ONU125.

In block508, the selected MIB is transmitted to the ONU. For example, OLT110transmits a message346, which indicates the selected type of MIB, to ONU125. According to an exemplary implementation, an attribute value of the managed entity indicates the selected type of MIB.

In block510, it is determined whether the selected MIB is successfully used. For example, in response to receiving and analyzing the message from OLT110, ONU125attempts to instantiate the selected type of MIB348. It is assumed that ONU125stores a type of MIB in common with the selected type of MIB.

When the selected MIB is successfully used (block510—YES), a message, which indicates that the selected MIB is successfully used, is transmitted to the OLT (block512). For example, when ONU125successfully instantiates the selected MIB, ONU125generates and transmits a message350, which indicates that the selected MIB is successfully instantiated, to OLT110. In response to receiving and analyzing the message, the OLT determines whether to select another MIB352. For example, in this case, when the selected MIB is successfully instantiated, OLT110determines that another MIB selection is not necessary.

In block514, an attribute value of the managed entity, which indicates that the selected MIB is successfully running on the ONU, is populated. For example, ONU125sets the attribute value of the managed entity354.

In block516, the attribute value is monitored by the OLT. For example, OLT110may periodically and/or aperiodically read the attribute value358so as to identify the MIB currently running on the ONU125.

Referring back to block510, when the selected MIB is not successfully used (block510-NO), a message, which indicates that the selected MIB is not successfully used, is transmitted to the OLT (block518). For example, when ONU125fails to instantiate the selected MIB (e.g., due to error, etc.), ONU125generates and transmits a message350, which indicates that the selected MIB is not successfully instantiated, to OLT110. As illustrated inFIG. 5, process500may return to block506. For example, in response to receiving and analyzing the failure message from ONU125, OLT110may select another one of the mutually-supported MIBs in view of the types of applications and/or services regarding ONU125.

AlthoughFIG. 5illustrates an exemplary process500of the MIB configuration service, according to other embodiments, process500may include additional operations, fewer operations, and/or different operations than those illustrated inFIG. 5, and described herein. For example, in block510, when ONU125determines that it does not support the type of MIB indicated in the message from OLT110, ONU125may generate and transmit a message, which indicates a rejection of the challenge (e.g., does not support the type of MIB), to OLT110. Additionally, or alternatively, ONU125may generate and transmit a message, which indicates one or multiple types of MIBs that are supported, to OLT110.

The foregoing description of embodiments provides illustration, but is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. In the preceding description, various embodiments have been described with reference to the accompanying drawings. However, various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The description and drawings are accordingly to be regarded as illustrative rather than restrictive.

In addition, while series of blocks have been described with regard to the processes illustrated inFIGS. 4A, 4B, and 5, the order of the blocks may be modified according to other embodiments. Further, non-dependent blocks may be performed in parallel. Additionally, other processes described in this description may be modified and/or non-dependent operations may be performed in parallel.

The embodiments described herein may be implemented in many different forms of software executed by hardware. For example, a process or a function may be implemented as “logic” or as a “component.” The logic or the component may include, for example, hardware (e.g., processor210, etc.), or a combination of hardware and software (e.g., software220). The embodiments have been described without reference to the specific software code since the software code can be designed to implement the embodiments based on the description herein and commercially available software design environments/languages.

The terms “a,” “an,” and “the” are intended to be interpreted to include one or more items. Further, the phrase “based on” is intended to be interpreted as “based, at least in part, on,” unless explicitly stated otherwise. The term “and/or” is intended to be interpreted to include any and all combinations of one or more of the associated items.

The word “exemplary” is used herein to mean “serving as an example.” Any embodiment or implementation described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or implementations.

Additionally, embodiments described herein may be implemented as a non-transitory storage medium that stores data and/or information, such as instructions, program code, data structures, program modules, an application, etc. The program code, instructions, application, etc., is readable and executable by a processor (e.g., processor210) of a computational device. A non-transitory storage medium includes one or more of the storage mediums described in relation to memory/storage215.

No element, act, or instruction described in the present application should be construed as critical or essential to the embodiments described herein unless explicitly described as such.