Resource Target Scheduling for PON Networks

Abstract

A system for resource target scheduling for PON networks.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 396,167, filed August 8, 2022. [Background technology]

[0002] The subject matter of this application relates to resource target scheduling for PON networks.

[0003] Passive optical networks (PONs) are often used as access networks, or as part of a larger communications network. 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 way, 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 terminals (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 respective optical fibers 13, or otherwise by respective fibers 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 street 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., apartment buildings). 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 between the endpoints.

[0007] An optical line terminal (OLT) 14 is located in a central office that interfaces 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 the ONTs 11 is provided to the feeder fiber 17. Thus, all of the data provided to each of the ONTs is provided to all of the ONTs through the optical splitter 12. Each of the ONTs selects the portion of the received optical signal intended for that particular ONT and transmits the data to its subscribers while discarding the remaining data. Typically, data to the ONTs is broadcast to the 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 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, 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 transmits 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 DESCRIPTION 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: [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 shows a network that includes a passive optical network. [Figure 2] FIG. 2 shows the OMCC messages provided to and from ONTs in a passive optical network. [Figure 3] FIG. 3 illustrates an example process flow of an OMCI message for managing an ONT in a passive optical network. [Figure 4]Figure 4 shows the vOLT management function for managing ONTs via vOMCI messages in a passive optical network. [Figure 5] FIG. 5 illustrates a dispatcher system with pending requests and requests to add to existing threads. [Figure 6] Figure 6 shows the dispatcher system with a new request and a new thread added. [Figure 7] FIG. 7 shows a dispatcher system with a new request, no available threads, and a task waiting list. DETAILED DESCRIPTION OF THE INVENTION

[0013] Referring to FIG. 2, the core network and / or optical line terminals provide management and control functions for the ONTs by using an optical network unit management and control interface (OMCI). The core network 200 and the OLTs 210, to which it provides and receives data, transmit and receive data using PON protocols via an optical distribution network (e.g., optical splitter) 220. The OLTs 210 pass data to and receive data from the ONTs 230 through the optical distribution network (ODN) 220. OMCI messages between the ONTs 210 and ONUs 230 for management and control are also provided between the OLTs 210 and ONTs 230 via the ODN 22. The ONTs 230 provide 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 area of the ONT includes the configuration of (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) operations, management, and maintenance flows, (7) physical ports, (8) gigabit-capable passive optical network encapsulation method conformance layer profiles, (9) service profiles, (10) traffic descriptors, and (11) asynchronous transfer mode conformance 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 in the optical access network.

[0015] The G.988 standard describes management entities in a protocol-independent management information base (MIB) that models information exchange between OLTs and ONTs in PON-based access networks covered by standards such as G.988. See G.988: 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 herein by reference in its entirety. G.988 also addresses ONT management and control channel (OMCC) setup, protocols, and message formats.

[0016] Referring to Figure 3, one technique for providing OMCI messages to the ONT is for a core network server (i.e., any server in the network) to create a virtual OMCI set of microservices. The management data maintained by the system is typically defined in terms of a YANG data model, including modules and submodules that define configuration and state data, notifications, and remote procedure calls. A YANG module defines a data model through its data and through the hierarchical organization and constraints on 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. The core network provides YANG requests to the OLT, which then converts the YANG requests and responses and notifications into OMCI messages to and from the vOLTMF (vOLT Management Function), and the OLT sends and receives OMCI message requests and responses and notifications to and from the ONT.

[0017] Referring to Figure 4, a high-level design of the vOLT Management Function (vOLTMF) is illustrated, which may be used to manage ONTs via vOMCI messages. Communication occurs between the vOLTMF, vOMCI proxy, and vOMCI function based on the creation and deletion of 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 during the ONT's creation. 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 the external management system.

[0018] 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 so that it can be processed by the access SDN M&C.

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

[0020] All YANG requests are sent towards 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 back to vOLTMF in GPB format via the Kafka bus, and the response is received via KafkaNotificationCallback#onNotification().

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

[0022] There can be multiple interactions between vOLTMF and vOMCI functions, including parallel configuration requests / commands to either the same or different ONUs. 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. The following shows the list of vOLTMF thread pools resulting in new runnable tasks: processNotificationRequestPool, kafkaCommunicationPool, kafkaPollingPool, processNotificationResponsePool, and processRequestResponsePool. processNotificationRequestPool is used to process mediated device event listener callbacks and device notification requests. kafkaCommunicationPool is used to process individual GET / COPY-CONFIG / EDIT-CONFIG requests within the MediatedDeviceNetconfSession spawned by preocessRequestResponsePool. kafkaPollingPool is used to fine-tune the KafkaConsumer implementation to poll for responses from vOMCI functions / vOMCI proxies. 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 considered a type of protocol adapter for running on an ONT that also functions as an OLT in a PON environment. OMCI messages are based on each message being 53 bytes long with a data payload of 31 bytes.

[0023] The OLT may provide OMCI messages to multiple ONTs in parallel. A preferred method for providing parallel OMCI messages is to use a multi-threaded execution module using a pool of available threads. The OLT may include a scheduler that manages the instantiation of threads and the use of the instantiated threads.

[0024] In a typical environment, an OLT communicates with hundreds, if not thousands, of ONTs. However, because an OLT has limited computational resources, it is desirable that only a limited number of threads be used at any particular time to ensure that the OLT has sufficient computational resources to provide data connectivity to its associated subscribers. The limited number of threads may be dynamically managed as desired. The threads available to the OLT may be from a thread pool. A traditional thread pool utilizes any available thread for the next request so that the requested task can be completed most efficiently. However, for an ONT receiving an OMCI message, many such messages or operations that are executed as a result are time-sensitive, meaning that operations associated with a first OMCI message (or set of messages) need to be completed before operations associated with a second OMCI message (or set of messages) can begin. Alternatively, operations associated with a second OMCI message (or set of messages) may be executed by the ONT before the first OMCI message (or set of messages). Thus, threads from the thread pool are defined by a specific allocation for a particular ONT.

[0025] Referring to FIG. 5, an exemplary thread dispatch system 500 is shown including five ONTs 502 accessible through an optical distribution network, designated ONT1, ONT2, ONT3, ONT4, and ONT5. Any number of OLTs may be included as desired. The server and / or OLTs form Optical Network Unit Management and Control Interface ("OMCI") messages that are provided to each ONT via an ONT Management and Control Channel ("OMCC"). Thread dispatch system 500 receives, for example, an ONT4 audit request 510. ONT4 audit request 510 is placed in a request handler queue 512 for processing. Dispatcher 520 receives the next request from request handler queue 512. Dispatcher 520 includes a dispatcher configuration 522 that sets the initial number of threads to be created 524, each of which requires computational resources to create, and the maximum number of threads that may be maintained simultaneously 526. Dispatcher 520 determines whether there is a currently pending allocation for ONT4. 5 shows that allocations for ONT2 are pending and / or active. If there are no currently pending allocations for ONT4 and there are currently unused available threads, dispatcher 520 may allocate a thread for ONT4 audit request 530 to dispatch destination 540 and dispatch the thread request as an OMCI message to ONT4.

[0026] Dispatcher 520 may receive requests for ONTs with active requests, such as an additional request for ONT2 while ONT2 has a currently active request 550. Rather than assigning the additional request for ONT2 to an available dispatcher 540, which may result in out-of-order operation by ONT2, the additional request for ONT2 552 is placed in a respective dispatcher queue 560 and dispatched after the currently active request 550 is completed. Each of dispatcher queues 560 is preferably a first-in, first-out queue.

[0027] When the dispatcher 520 exhausts its task queue for any particular dispatch destination 540 such that there are no current assignments and no pending requests for the particular dispatch destination 540, the dispatch destination 540 can signal to the dispatcher 520 that the particular dispatch destination 540 has completed all currently assigned and pending requests and is therefore available for additional assignments to the same or another ONT.

[0028] Thread dispatch system 500 initially creates an initial set of threads, each of which requires computational resources to create and maintain, based on initial dispatch destination configuration 524. Thread dispatch system 500 may spawn additional threads when all currently created threads have active assignments and the number of created threads is less than or equal to the maximum number of threads allowed based on maximum dispatch count 526. In this way, additional threads are created in a controlled manner that limits the computational load on the server and / or ONT at any particular time and also avoids creating a large set of threads not necessary for the system since few, if any, threads are used simultaneously.

[0029] 6 , when dispatcher 520 receives ONT1 active request 570, dispatcher 520 determines that there are no active requests for ONT1, determines that there are no previously created threads available, determines that there are fewer threads than the maximum number of dispatches allowed, and therefore creates another thread in which ONT1 audit request 570 is added at 572. In this way, the number of active threads is increased to accommodate the additional thread, and an OMCC message is provided to the ONT.

[0030] 7, when dispatcher 520 receives ONT5 audit request 580, dispatcher 520 determines whether there are any active requests for ONT5, whether there are any previously created available threads, whether there are any threads less than the maximum number of allowed dispatches, and if there are no such available threads, adds ONT5 audit request 582 to task wait list 590. Other requests may be added to task wait list 590 and preferably processed on a first-in, first-out basis. ONT5 audit request 582 in task wait list 590 is removed from task wait list 590 when dispatcher 520 determines there is an available dispatch destination 560, in which case it is assigned to that dispatch destination 560 and an OMCI message is provided to the respective ONT.

[0031] If necessary, thread dispatch system 500 may expand the maximum number of threads. Also, if desired, thread dispatch system 500 may shorten the maximum number of threads. Thread shortening is preferably performed when a particular thread is no longer actively being used.

[0032] If necessary, thread dispatch system 500 may extend the minimum number of threads. Also, if desired, thread dispatch system 500 may shorten the minimum number of threads.

[0033] Often, an event occurs to the ONTs in a PON network when a significant number of ONTs require control and management in the form of OMCI messages as a result of a service outage. In such cases, it is desirable to prioritize the OMCI messages based on the subscribers' service level agreements. For example, subscribers with high service level agreements may be provided with an OMCI message before subscribers with medium and low service level agreements. For example, subscribers with medium service level agreements may be provided with an OMCI message before subscribers with low service level agreements. For example, subscribers with low service level agreements may be provided with an OMCI message after all other subscribers have been provided with OMCI messages. Each of the requests may be maintained in a task waiting list 590, and each request from the task waiting list 590 may be removed based on the service level agreement prioritization. This provides a systematic method for prioritizing OMCI messages.

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

[0035] It will be understood that the present invention is not limited to the particular embodiments described, and that changes can 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 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. As used in the claims, the term "comprise" or derivatives thereof are 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) each of the optical line terminals includes a northbound interface for transmitting and receiving data to and from a server; (b) the optical line terminal includes ports for transmitting and receiving optical data to and from a plurality of optical network terminal devices via optical fibers, (c) the optical line termination includes a thread dispatch system that manages a plurality of threads that provide a first optical network termination management and control interface message to a first one of the plurality of optical network termination devices, a second optical network termination management and control interface message to a second one of the plurality of optical network termination devices, and a third optical network termination management and control interface message to the first one of the plurality of optical network termination devices; (d) an optical line termination, wherein the thread dispatch system has the first optical network termination management and control interface message active on a first thread, the second optical network termination management and control interface message active on a second thread, and a third thread with no active optical network termination management and control interface messages, and queues the third optical network termination management and control interface message on the first thread to be dispatched after completion of the first optical network termination management and control interface message on the first thread.

2. 2. The optical line terminal of claim 1, further comprising the thread dispatch system providing a fourth optical network terminal management and control interface message to a third one of the plurality of optical network terminals on the third thread.

3. 3. The optical line termination of claim 2, further comprising the thread dispatch system creating a fourth thread when the first thread, the second thread, and the third thread are active and the thread dispatch system receives another request for an optical network terminal device that is not an optical network terminal device associated with the first thread, the second thread, and the third thread.

4. 4. The optical line terminal of claim 3, further comprising: the thread dispatch system receiving a further optical network termination management and control interface message for the first optical network termination device; and queuing the further optical network termination management and control interface message on the first thread to be dispatched after completion of the first optical network termination management and control interface message on the first thread and the third optical network termination management and control interface message on the first thread.

5. 5. The optical line termination of claim 4, further comprising the thread dispatch system queuing additional optical network termination management and control interface messages that are not associated with any optical network termination device that has an active thread in the queue until a thread is available to provide one of the additional optical network termination management and control interface messages to a respective optical network termination device.

6. 10. The optical line terminal of claim 1, further comprising the thread dispatch system including an initial number of threads defined by an initial configuration value.

7. 10. The optical line terminal of claim 1, further comprising the thread dispatch system including a maximum number of threads defined by a maximum configuration value.

8. 2. The optical line termination of claim 1, further comprising the thread dispatch system providing the additional optical network termination management and control interface message to each optical network termination device based on a service level agreement with each subscriber associated with the additional optical network termination management and control interface message.

Images