Systems and methods for bandwidth allocation in passive optical networks

Abstract

This disclosure describes systems and methods for bandwidth allocation in passive optical networks. An optical line terminal (OLT) may communicate with one or more optical network terminals (ONT). A dynamic bandwidth allocation (DBA) engine configured within the OLT may allocate a constant location rate (CBR) bandwidth for one or more transport containers from an upstream bandwidth capacity of a PON when registering the transport containers. Each transport container may be used by an associated ONT for one or more CBR applications. The OLT may receive an indication of a state of a CBR application. In response to receiving the indication, the DBA engine may adjust CBR bandwidth usage for the corresponding ONT in a bandwidth map. The OLT may communicate an updated bandwidth map to the ONT.

Description

Technical Field

[0001] This disclosure generally relates to passive optical networks, and more specifically, to systems and methods for allocating bandwidth to optical network terminals connected to optical line terminals. Background Technology

[0002] The increasing prevalence of virtual reality and augmented reality devices is transforming the digital environment, impacting communications, entertainment, privacy, and security. As these technologies become more integrated, network management is becoming increasingly critical. Passive optical networks (PONs) are a key technology for delivering high bandwidth to users. A PON network can comprise central office equipment and customer residence equipment. The central office equipment is responsible for allocating bandwidth at the PON system's transport aggregation layer to manage upstream traffic from user equipment. Summary of the Invention

[0003] This disclosure relates to bandwidth allocation in passive optical networks. Wireless networks support a wide range of applications, from web browsing to intensive real-time communication and entertainment, such as audio / video conferencing and online gaming. These applications require not only efficient data transmission but also rapid packet delivery to provide a seamless user experience. Latency-sensitive applications can experience significant degradation in user experience due to latency in data transmission. Passive optical networks (PONs) can implement dynamic bandwidth allocation (DBA) algorithms to improve data transmission. However, these algorithms prioritize efficiency over latency, which can pose challenges for real-time applications such as online gaming and video conferencing.

[0004] The DBA algorithm in PON can rely on fixed-size time frames (typically 1 ms) to manage bandwidth distribution. This configuration works well for applications with a consistent data flow. However, upstream data from applications such as video conferencing or cloud gaming consoles can exhibit bursty behavior. For example, these applications generate data in bursts (e.g., video frames) at specific time intervals (16, 30, or 60 milliseconds, depending on the frame rate), with inactive periods in between. User commands from cloud gaming consoles may also occur infrequently (e.g., every few seconds). Within these time frames, transmission opportunities (e.g., allocations) can be communicated to the Optical Network Terminal (ONT) via control messages. However, to account for variations in clock speed / rate and signal travel distance across the network, a guard time buffer can be inserted between each allocation. While this configuration prevents data collisions, the guard time can create unused "invalid" time slots, thus reducing channel throughput (effective data transmission rate). To minimize the overhead associated with frequent allocation switching, the DBA algorithm can be configured to allocate larger time slots to each ONT. Reducing these guard times between allocations can improve bandwidth utilization for bulk data transmissions, but this can increase packet latency.

[0005] In this regard, a constant bit rate (CBR) allocation mechanism can be used to provide a constant allocated rate. However, these mechanisms are primarily intended for services provided by the operator (e.g., voice / video) rather than user applications. Most latency-sensitive applications (e.g., gaming, augmented reality (AR), and virtual reality (VR)) are treated as data and operate under a variable bit rate (VBR) allocation, which adjusts according to data demand. However, for low-latency applications such as video conferencing, complete frame data is expected at the decoder. If the last byte of the frame is stuck or delayed at the ONT, this can prolong the decoding process on the receiver side and add as much latency as the entire frame. Many decoder implementations cannot initiate decoding until the entire frame is received. Furthermore, with CBR, a fixed amount of bandwidth is allocated to the ONT during registration. However, this allocation remains constant and may not adjust based on the actual activity of low-latency applications within the network.

[0006] The technical solution disclosed herein overcomes these challenges associated with balancing bandwidth efficiency and low latency requirements. The solution enables a dynamic switching mechanism within the DBA. The DBA can assign virtual time slots within a frame to latency-sensitive allocations identified by Alloc_ID. Alloc_ID is an identifier assigned to each ONT within the PON. Alloc_ID serves as a reference point for the OLT to distinguish and manage different ONTs on the network. Dedicated time slots provide a bounded maximum latency between allocations for low-latency applications. For other allocations prioritizing bandwidth efficiency, the DBA can combine virtual time slots into larger consecutive allocations or a single longest possible consecutive allocation, thereby maximizing actual throughput. Type of service detection (bandwidth relative to latency) can be communicated to the DBA through various methods, including management systems, deep packet inspection at the optical line terminal (OLT) or ONT, service monitoring systems, or existing infrastructure.

[0007] Furthermore, technical solutions allow for trade-offs between bandwidth utilization and latency to minimize delays caused by waiting for complete data frames. This becomes critical for real-time applications, where data transmission latency can significantly impact user experience. In this regard, the ONT can be configured to identify and prioritize the transmission of data packets associated with low-latency or CBR applications before assembling complete frames. While the low-latency application is active on a client device, the ONT can receive low-latency information via a low-latency agent within the ONT or a low-latency controller on the network. The ONT can modify its status report messages to include a time-to-live concept for low-latency allocations. This timestamp indicates the closest deadline for the next allocation. The OLT's DBA can use the deadline information to improve prioritization. For example, the OLT can schedule low-latency allocations with tighter deadlines first to provide timely delivery of critical data. This prioritization is beneficial for real-time applications such as AR-VR applications, where complete frames are critical for proper decoder operation. Delaying the last part of a frame due to insufficient bandwidth can lead to dropping the entire frame, resulting in a negative user experience. To further enhance prioritization within low-latency allocations, a Layer 2 (L2) flag can be defined to identify data segments within packets. For example, this flag can indicate the end of a video or audio frame. In some cases, similar to the TCP PUSH / PSH flag, setting the L2 flag can instruct the OLT to prioritize the transmission of data associated with low-latency applications, even if the ONT queue associated with the corresponding TCONT data buffer only holds a single byte for that particular allocation.

[0008] Furthermore, CBR allocation can address low-latency requirements by assigning fixed bandwidth to the ONT, but this configuration can lead to inefficiency when no real-time services are available. To address this issue, a low-latency controller can monitor applications on connected devices across the network. When a low-latency application is detected as active, the controller can communicate with the OLT / DBA to provide CBR services to a specific ONT. When a low-latency application is deactivated, the controller can instruct the OLT to disable CBR via the DBA. The ONT can be equipped with a mechanism for identifying active low-latency applications on connected devices. Based on predefined criteria or service patterns, the ONT can dynamically request CBR service activation / deactivation from the OLT. The OLT can be enhanced to handle service patterns at the network level. By identifying characteristics associated with real-time applications, the OLT can autonomously activate CBR services for a specific ONT. This adaptive approach allows the system to provide consistent bandwidth during the active periods of low-latency applications and maintain improved performance without wasting resources when these applications are inactive. Therefore, this technical solution can maintain low latency and improve network efficiency by dynamically adjusting bandwidth allocation based on real-time application demands.

[0009] At least one aspect of the technical solution relates to a system for bandwidth allocation in a passive optical network. The system may include an optical line terminal (OLT) of a passive optical network (PON). The OLT may communicate with one or more optical network terminals (ONTs). The system may include a dynamic bandwidth allocation (DBA) engine configured to allocate constant bit rate (CBR) bandwidth to one or more transport containers from the upstream bandwidth capacity of the PON in response to registration of one or more transport containers. Each of the one or more transport containers may be used by an associated ONT for one or more CBR applications. The OLT may be configured to receive indications of the status of CBR applications among the one or more CBR applications. In response to the indications, the DBA engine may be configured to modify the CBR bandwidth usage of the one or more ONTs in a bandwidth mapping (BW mapping). The OLT may communicate the bandwidth mapping to the one or more ONTs.

[0010] In some embodiments, the state may include either on or off. In some embodiments, the DBA engine may be further configured to modify the bandwidth mapping to increase the CBR bandwidth allocation for the one or more ONTs in response to the state of the CBR application being on. In some embodiments, the DBA engine may be further configured to modify the bandwidth mapping to decrease the CBR bandwidth allocation for the one or more ONTs in response to the state of the CBR application being off. In some embodiments, the OLT may be further configured to receive an indication of the state of the CBR application from at least one of the one or more ONTs. In some embodiments, the at least one of the one or more ONTs may be further configured to receive the indication of the state of the CBR application from a low-latency agent or a latency controller. In some embodiments, the OLT may be further configured with a low-latency agent. The low-latency agent may be configured to receive the indication of the state of the CBR application from the one or more CBR applications. In some embodiments, the OLT may be further configured to receive the indication of the state of the CBR application from a low-latency controller on another device.

[0011] Another aspect of the technical solution relates to a method for bandwidth allocation in a passive optical network. The method may include: identifying one or more transport containers used by optical line terminals (OLTs) of a passive optical network (PON), the OLTs communicating with one or more optical network terminals (ONTs); in response to registration of one of the transport containers, allocating constant bit rate (CBR) bandwidth from the upstream bandwidth capacity of the PON to the one or more transport containers, each of the transport containers being used by an associated ONT for one or more CBR applications; receiving an indication of the status of a CBR application within the one or more CBR applications from the OLT; in response to the indication, modifying the CBR bandwidth usage of the one or more ONTs in a bandwidth mapping (BW mapping) by the DBA engine; and communicating the bandwidth mapping to the one or more ONTs by the OLT.

[0012] In some embodiments, the state may include either on or off. In some embodiments, the method may include, in response to the state of the CBR application being on, the DBA engine modifying the bandwidth mapping to increase the CBR bandwidth allocation for the one or more ONTs. In some embodiments, the method may include, in response to the state of the CBR application being off, the DBA engine modifying the bandwidth mapping to decrease the CBR bandwidth allocation for the one or more ONTs. In some embodiments, the method may include, by the OLT, receiving the indication of the state of the CBR application from at least one of the one or more ONTs. In some embodiments, the method may include, by the OLT, receiving the indication of the state of the CBR application from a low-latency agent or a latency controller. In some embodiments, the method may include, by the OLT, receiving the indication of the state of the CBR application from the one or more CBR applications. In some embodiments, the method may include, by the OLT, receiving the indication of the state of the CBR application from a low-latency controller on another device.

[0013] Another aspect of the technical solution relates to a bandwidth allocation device in a passive optical network. The device may include one or more processors coupled to memory and configured with a dynamic bandwidth allocation (DBA) engine to identify one or more transport containers used by optical line terminals (OLTs) of a passive optical network (PON). The OLT may communicate with one or more optical network terminals (ONTs). The DBA engine may be configured to allocate constant bit rate (CBR) bandwidth to the one or more transport containers from the upstream bandwidth capacity of the PON in response. Each of the one or more transport containers may be used by an associated ONT for one or more CBR applications. The device may be configured to receive an indication that the status of a CBR application in the one or more CBR applications is open or closed. In response to the indication, the DBA engine may be configured to modify the CBR bandwidth usage of the one or more ONTs in a bandwidth mapping (BW mapping). The device may communicate the bandwidth mapping to the one or more ONTs.

[0014] In some embodiments, the device may be further configured to receive the instruction from one of the one or more ONTs. In some embodiments, the device may be further configured to receive the instruction from a second device. In some embodiments, the device may be further configured to receive the instruction from the CBR application. Attached Figure Description

[0015] The foregoing and other objects, aspects, features, and advantages of this disclosure will become more apparent and better understood from the following description taken in conjunction with the accompanying drawings, wherein:

[0016] Figure 1A This describes a general schematic block diagram of a communication system according to one or more embodiments;

[0017] Figure 1B Description according to one or more embodiments Figure 1A A general schematic block diagram of a part of the communication system described herein;

[0018] Figure 1C Description of one or more embodiments and for use Figure 1A A general schematic block diagram illustrating the application of cloud infrastructure communication in the communication system described herein;

[0019] Figure 1D Description of one or more embodiments for use Figure 1A A general schematic block diagram of the application program of the communication system described herein;

[0020] Figure 1E Description of one or more embodiments for use Figure 1A A general schematic block diagram of the application program of the communication system described herein;

[0021] Figure 1F Description according to one or more embodiments Figure 1A The schematic block diagram of the communication system described herein includes a server configured for augmented reality / virtual reality and / or metaverse applications;

[0022] Figure 2A A block diagram illustrating an embodiment of a computing device according to one or more embodiments;

[0023] Figure 2B A block diagram illustrating a computing environment including a client device communicating with a cloud service provider, according to one or more embodiments;

[0024] Figure 3A A block diagram illustrating an example system for dynamically switching between a time-delay-sensitive mode and a bandwidth-efficient mode in a passive optical network, according to one or more embodiments.

[0025] Figure 3B This illustrates a block diagram of an example system for pushing partial data upstream in a passive optical network, according to one or more embodiments.

[0026] Figures 3C to 3E A block diagram illustrating an example system for dynamic constant bit rate bandwidth allocation in a passive optical network according to one or more embodiments;

[0027] Figure 4A This describes an example data transmission frame according to one or more embodiments;

[0028] Figure 4B This describes another example of a data transmission frame according to one or more embodiments;

[0029] Figure 5 Example flowchart illustrating a method for dynamically switching between a time-delay-sensitive mode and a bandwidth-efficient mode in a passive optical network according to one or more embodiments;

[0030] Figure 6 An example flowchart illustrating a method for pushing partial data upstream in a passive optical network according to one or more embodiments; and

[0031] Figure 7 Example flowchart illustrating a method for dynamic constant bit rate bandwidth allocation in a passive optical network according to one or more embodiments. Detailed Implementation

[0032] The following disclosure provides numerous different embodiments or instances for implementing various features of the provided subject matter. Specific examples of components and arrangements are described below to simplify this disclosure. Of course, these are merely examples and are not intended to be limiting. For example, in the following description, a first feature communicating or communicatively coupled to a second feature may include embodiments in which the first feature directly communicates with or is directly coupled to the second feature, and may also include embodiments in which an additional feature may be intermediate between the first and second features such that the first feature indirectly communicates with or is indirectly coupled to the second feature. Additionally, in various instances, reference numerals and / or letters may be repeated in this disclosure. This repetition is for simplicity and clarity and does not in itself indicate a relationship between the various embodiments and / or configurations discussed.

[0033] The following IEEE standards (including any draft versions of such standards) are hereby incorporated herein by reference in their entirety and constitute part of this disclosure for all purposes: IEEE 802.11 TM IEEE 802.14 TM IEEE P802.3 TM and IEEE Ethernet standard systems, including but not limited to LRM, VSR, SR, MR, LR, ZR, and KR. Although this disclosure may reference aspects of these standards, it is in no way limited to them.

[0034] In some embodiments, devices provided by an ISP and customer-owned AR / VR devices, mobile phones, OTT devices, and cloud gaming clients are configured for low-latency use. Some embodiments of the systems and methods disclosed herein provide real-time or near-real-time systems for monitoring end-to-end latency. In some applications, latency monitoring is performed using a Precise Time Protocol (PTP) synchronization protocol to synchronize timestamps with applications at intermediate nodes and terminal devices. In some embodiments, end-to-end latency monitoring allows for the identification of sources of significant latency by taking into account the latency of all devices throughout the entire end-to-end process.

[0035] In some embodiments, the system and method achieve synchronization of time references across all nodes and end-user devices by timestamping low-latency data packets at each node. The latency at each node is determined by the application at each node. The latency determination is reported back to the server communicating with the application. The system and method allow the communication system to distinguish whether the latency originates from a home network, an ISP, or a cloud server.

[0036] In some embodiments, the low-latency application server extension is integrated into a modem or router provided by an ISP. In some embodiments, the server extension has the ability to filter all necessary information and transmit it to the ISP's cloud server or share open data with application developers. In some embodiments, the server extension can store or receive information about a customer's low-latency plan subscription and can track low-latency usage within the home.

[0037] In some embodiments, a server extension can refer to a software component or module that enhances the functionality of a server application (e.g., a low-latency application). Server extensions can be used in various server environments, such as web servers, application servers, ISP servers, and database servers, to enhance their capabilities or add specific features tailored to the needs of users or applications, and can be installed using extension files. Extensions can be installed on any of the devices discussed herein. In some embodiments, extensions are provided via ISP-controlled servers in the cloud, ISP-controlled modems or access points, third-party Wi-Fi access points, third-party modems, or low-latency devices provided by ISPs.

[0038] In some embodiments, the server extension allows users to select device applications for different latency handling. A server within a residence can use classifiers and queues to reduce latency for low-latency devices. In some embodiments, the server may be part of a router, set-top box, hub, etc. In some embodiments, the server extension supports end-to-end use by multiple parties (e.g., cloud managers, ISPs, application developers, and silicon vendors).

[0039] Regarding latency, in some embodiments, latency generally refers to the amount of time required for a system, application, or device to process and respond to a request. Regarding low latency, in some embodiments, low latency refers to this amount of time being within a threshold, performance level, user experience level, or requirement of an application or use. Thresholds, performance levels, user experience levels, or requirements of an application can vary based on context, such as the type of application and / or use case, the system, network, and computing environment in which such use cases and / or applications operate or perform. From a computing environment perspective, for a context or use case that provides such a response, low latency refers to the ability of a computing system or network to provide a response without unacceptable or inappropriate delays, or otherwise with minimal delay. System criteria and application parameters can influence low latency thresholds. Thresholds can be fixed or variable (e.g., depending on conditions or actual needs or requirements at a specific time). Regarding low-latency networks and systems in the context of networks and network communications, low latency describes computer networks, systems, and environments designed, configured, and / or implemented to support applications, network services, and processing operations by reducing or improving latency or meeting low latency thresholds. End-to-end latency refers to the latency between two points in a network or communication system. In some embodiments, the two points may be a data source and a data consumer, or an intermediate point between them.

[0040] In some embodiments, a low-latency device refers to any hardware, device component, or system that has low-latency considerations or requirements. A low-latency device may be, for example, a telecommunications, remote control system, gaming, audio processing, financial transaction, augmented reality, and / or virtual reality device, where latency can affect user experience or system performance. In some embodiments, there may be several levels of low-latency requirements, with one low-latency device having more stringent requirements than another. In some embodiments, a low-latency path refers to a low-latency operation path. In some embodiments, latency data refers to any latency indication associated with communication or configuration data related to low-latency operation or control. In some embodiments, a low-latency application refers to the use or performance of low-latency operation. Low-latency devices or software programs can be used to perform low-latency operations (e.g., video conferencing, cloud gaming, augmented reality / virtual reality (AR / VR) applications, and metaverse applications).

[0041] Some embodiments relate to a system including a first device and an application. The application operates on the first device and is configured to append timestamps to first packets received by the first device. The timestamps indicate a first time the first packet was received by the first device and a second time the first packet was sent by the first device. In some embodiments, append refers to adding or attaching information to a data structure (e.g., a packet).

[0042] In some embodiments, the application is configured to use timestamps to determine latency information associated with communication through the first device. The timestamps include a first timestamp at a first time and a second timestamp at a second time. In some embodiments, the application is configured to provide a second packet containing latency information and transmit the second packet to a server remotely located on the first device via a virtual communication link. In some embodiments, the first timestamp is an ingress timestamp, and the second timestamp is an egress timestamp.

[0043] In some embodiments, the timestamp is provided as part of a precise time protocol. In some embodiments, the first packet is used in low-latency operation. In some embodiments, the timestamp is derived from a satellite time source. In some embodiments, the latency information includes timestamp history. In some embodiments, the first device is a user device, cloud infrastructure, Internet service provider infrastructure, set-top box, cable modem, or wireless router.

[0044] Some embodiments refer to a non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to receive a first packet from a first node. The first packet contains latency information associated with a second packet provided to the first node of a low-latency application. If the latency information indicates that a latency threshold for the low-latency application has not yet been met, the instructions further cause the processor to provide a third packet to the first node or other nodes to increase the packet priority for the low-latency application. The first node may be part of a communication system comprising cables, optical fibers, or wireless networks. Other nodes and the first node are in the path associated with the second packet provided to the first node of the low-latency application.

[0045] In some embodiments, the processor is located on a server at a remote location of the first node. In some embodiments, the server communicates with an Internet service provider infrastructure, and a third packet is provided to the Internet service provider infrastructure. In some embodiments, the third packet is provided to the Internet service provider infrastructure, a set-top box, a cable modem, or a wireless router.

[0046] In some embodiments, if latency information indicates that the latency threshold for a low-latency application has been met and additional bandwidth is available, then the instruction causes the processor to provide a fourth packet or data unit (e.g., a network layer packet, cell, frame, etc. used when transmitting data) to the first node or other nodes to reduce the packet priority of the low-latency application. In some embodiments, the processor is located on a server located remotely from the first node.

[0047] In some embodiments, latency information includes user identification.

[0048] Some embodiments relate to a method for providing low-latency services. The method includes providing a first timestamp to a first packet being provided to a first device. The first packet may be received by a low-latency device or used in low-latency operation. The method further includes providing a second packet containing latency information to a server remotely located at the first device via a virtual communication link.

[0049] In some embodiments, the method further includes providing a second timestamp to a first packet being provided to a first device. In some embodiments, the first timestamp is an ingress timestamp, and the second timestamp is an egress timestamp. In some embodiments, the first device includes an application configured to append the first timestamp to the first packet.

[0050] Some embodiments relate to a server. The server includes a first application configured to monitor end-to-end latency of a network. The network includes devices. The application is configured to receive latency information from at least one of the devices. The latency information includes timestamps or time-segment data of packets to be transmitted across devices or links. Monitoring or monitoring refers to the act of observing, checking, and / or recording performance, and typically occurs over a period of time.

[0051] A non-transitory computer-readable medium stores instructions thereon that, when executed by a processor, cause the processor to receive a first packet from a first node. The first packet contains latency information associated with a second packet provided to the first node of the low-latency application. The instructions also cause the processor to provide a subscription offer in response to the latency information. The first node is part of a communication system including a cable, fiber optic, or wireless network. Other nodes and the first node are in a path associated with the second packet provided to the first node of the low-latency application.

[0052] In some embodiments, the first device is a set-top box, cable modem, or wireless router. In some embodiments, device may refer to any equipment, system, or component used to perform operations. Low-latency device may refer to any device capable of performing low-latency operations. In some embodiments, low-latency operation refers to an operation in which higher-latency operations would affect performance levels, user experience levels, or requirements for an application or use. In some embodiments, packet refers to a data unit transmitted over a network and includes, for example, cells, frames, and network layer packets. Packets may include a header and a payload. In some embodiments, timestamps and latency information may be appended to packets. In some embodiments, classify may refer to any operation used to determine classification, grouping, or arrangement. For example, in some embodiments, packets may be classified for use with low-latency devices or applications by looking at their addresses, appended data, their data type, or other information. In some embodiments, bandwidth may refer to a quantity of communication capacity. In some embodiments, priority refers to a sequence of precedence, hierarchy, level, or other classification. For example, in some embodiments, packets may be ordered according to a priority associated with latency requirements for transmission. In some embodiments, cable, fiber optic, or wireless network refers to any network that uses one or more of fiber optic cables, coaxial cables, Ethernet cables, other wires, or wireless media.

[0053] The following description of portions of this specification and its corresponding contents may be helpful for the purpose of reading the descriptions of the various embodiments described below:

[0054] Part A describes a communication system that may be useful in practicing the embodiments described herein.

[0055] Part B describes low-latency applications that may be useful for practicing the embodiments described herein.

[0056] - Part C describes embodiments of network and computing environments that may be useful for practicing the embodiments described herein.

[0057] Part D describes embodiments of systems and methods for bandwidth allocation in passive optical networks.

[0058] A. Communication System

[0059] Network latency significantly impacts internet connectivity, user experience, and the performance of various online applications and services. Some embodiments provide ISPs with information to address end-to-end latency issues through network optimization, infrastructure upgrades, and efficient routing to ensure a reliable and responsive internet experience for their customers. In some embodiments, tools are provided that enable ISPs' cloud servers to collect and analyze data and to reconfigure ISP-provided devices, such as cable modems, GPON modems, or set-top boxes. In some embodiments, systems and methods allow multiple parties (e.g., more than one ISP, cloud service provider, public switch operator, and application developer) to address low-latency usage, including but not limited to video conferencing, augmented reality (AR) / virtual reality (VR), and metaverse end-to-end usage. In some embodiments, systems and methods allow multiple parties to collaborate and work together to address latency issues. In some embodiments, systems and methods can be used with Wi-Fi networks, Ethernet networks, modems, access networks, backbone networks, IXPs, and cloud infrastructure and allow multiple teams to work together to optimize latency across various media.

[0060] In some embodiments, a latency monitor measures and reports latency for each link, device, and end application. Reports are provided to path controllers, such as ISPs, application developers, end users, etc., so that action can be taken if low-latency requirements are not met. In some embodiments, the system and method provide seamless latency monitoring, analysis, and optimization. Analysis of latency measurement and reporting allows for real-time identification of latency factors and optimization by mapping services requiring low latency to low-latency queues or paths. In some embodiments, devices in the path have applications (e.g., software) for implementing monitoring, analysis, and optimization. Analysis of latency measurement and reporting allows control of devices to appropriately provide low-latency services to low-latency queues or paths. The application may communicate with a latency server (e.g., the application's server), which coordinates operations and accumulates data based on monitoring, analysis, and optimization operations. An application (application / app) can refer to a software program or module configured to perform a specific function or task on an electronic device.

[0061] refer to Figure 1AThe communication system 100 includes network 1002A of residences 1016A and 1018A, network 1002B of residences 1016B and 1018B, cloud infrastructure 1004, and a BQUICK_TOP server 1005. The communication system 100 is advantageously configured to provide information to an ISP to address latency issues through network optimization, infrastructure upgrades, service upgrades, and / or efficient routing, ensuring a reliable and responsive internet experience for customers on networks 1002A and 1002B. In some embodiments, the BQUICK_TOP server 1005 is configured to receive information and address latency issues. In some embodiments, the BQUICK_TOP server 1005 communicates (e.g., via a direct or virtual connection) with cloud infrastructure 1004 and networks 1002A and B (residences 1016A to B and 1018A to B) to share information, reports, commands, and other data. BQUICK_TOP servers 1005, infrastructure 1004, and residential units 1016A to B and 1018A to B can use any form of communication media, network, protocol, etc. to transmit data and information.

[0062] In some embodiments, cloud infrastructure 1004 includes a collection of hardware, software, networking, and other resources that enable the delivery of cloud computing services over the Internet. In some embodiments, cloud infrastructure 1004 includes physical servers, storage devices, networking equipment, and other hardware components hosted in data centers spanning multiple geographically distributed locations. In some embodiments, the data centers are equipped with high-performance servers, storage arrays, and network equipment to support the computing needs of cloud services. In some embodiments, cloud infrastructure 1004 is configured to provide high-speed, redundant network links, routers, switches, and content delivery networks (CDNs) to deliver low-latency, high-bandwidth content to users. In some embodiments, cloud infrastructure 1004 includes block storage (e.g., Amazon EBS, Azure Disk Storage), object storage (e.g., Amazon S3, Google Cloud Storage), and file storage (e.g., Amazon EFS, Azure Files).

[0063] Residences 1016A and 1018A may include a network associated with a first ISP, and residences 1016B and 1018B may include a network associated with the same ISP or a second ISP. In some embodiments, the networks of residences 1016A and 1018A, as well as residences 1016B and 1018B, are part of a Broadband Access Server (BAS) network. Network 1002A includes infrastructure 1006A, headend 1008A, BQUICK ISP_A server 1012A, splitter 1014A, residential equipment 1016A, and residential equipment 1018A. Residential equipment 1018A includes an optical network unit (ONU) 1020, a user device 1022, and a television 1024. In some embodiments, the modem or optical network unit 1020 may be a fiber optic router, switch, gateway, etc., and has Wi-Fi capability for the Wi-Fi network associated with residence 1018A. In some embodiments, the optical network unit 1020 is a GPON modem or optical network terminal (ONT). GPON is a technology that allows high-speed Internet access via fiber optic cables. The optical network unit 1020 converts optical signals transmitted via fiber optic cables into electrical and / or radio frequency signals that can be used by devices in residence 1018A. Although system 100 is shown communicating via coaxial and optical cables, terrestrial wireless and satellite communications can be utilized in system 100. The optical network unit 1020 is typically provided by an optical network operator (ISP-A) and may be referred to as an optical network terminal. The BQUICK_TOP server 1005 and BQUICK ISP_A server 1012A can be Broadcom Analytics System (BAS) servers that collect and analyze data from various devices such as modems, set-top boxes, and other devices.

[0064] User device 1022 can be a smartphone, AR / VR device, tablet, laptop, smartwatch, sports equipment, smart home appliance, camera, headset, automobile, or other computing device. Residence 1016A may have similar devices to residence 1018A. Television 1024 and user device 1022 communicate with optical network unit 1020 via a wireless network or wired connection. In some embodiments, optical network unit 1020 may include an Ethernet router that includes wired connections to user device 1022, wireless modem, and television 1024.

[0065] Headend 1008A includes routers, switches, servers, and / or other infrastructure for communication between ISP infrastructure 1006A and cloud infrastructure 1004. ISP infrastructure 1006A includes routers, switches, servers, and / or other infrastructure for communication between headend 1008A and splitter 1014A. Splitter 1014A communicates between infrastructure 1006A and residences 1016A and 1018A via fiber optic cable. BQUICK ISP_A1012A and BQUICK_TOP server 1005 communicate with server 1012, infrastructure 1006A, headend 1008A, and residences 1016A and 1018A via direct or indirect communication (e.g., via the Internet).

[0066] In some embodiments, splitter 1014A is an optical fiber splitter. Splitter 1014A can be used in an optical fiber network to split an incoming optical signal into multiple separate signals for residential 1016A and 1018A, and to unify the signal into one or more signals for infrastructure 1006A. Splitter 1014A can be configured for passive optical network (PON) architectures. In some embodiments, bidirectional communication occurs across splitter 1014A. In some embodiments, splitter 1014A is a conductive cable type splitter (e.g., for coaxial cable rather than optical cable). In some embodiments, splitter 1014A includes repeaters, amplifiers, signal conditioners, etc.

[0067] The BQUICK ISP_A server 1012A is a computing device, such as a machine equipped with one or more processors, memory, and storage drivers. In some embodiments, the BQUICK ISP_A server 1012A delivers a variety of services to ISP customers (e.g., residences 1016A and 1018A). The BQUICK_TOP server 1005 is configured as a central hub, responsible for managing and routing Internet traffic for its users. The BQUICK ISP_A server 1012A handles requests from users, such as accessing websites, sending emails, streaming content, and downloading files. The BQUICK ISP_A server 1012A manages network protocols, assigns IP addresses, and facilitates communication between different devices on the Internet. The BQUICK ISP_A server 1012A includes an operating system (such as Linux or Windows Server) and networking software, such as routing protocols (e.g., BGP, OSPF), a DNS (Domain Name System) server, a Dynamic Host Configuration Protocol (DHCP) server for IP address allocation, and firewall / security software to protect system 100 from network threats. The BQUICK ISP_A server 1012A employs service shaping and Quality of Service (QoS) mechanisms to prioritize and optimize Internet services, thereby ensuring a smooth and consistent user experience for all users. These operations may involve managing bandwidth allocation, prioritizing certain types of services (such as VoIP or video streaming), and mitigating network congestion during peak usage periods, and can be performed in response to information from server 1012. In some embodiments, the BQUICK ISP_A server 1012A uses monitoring tools or applications to continuously analyze service data to detect anomalies, troubleshoot network problems, and ensure compliance with Service Level Agreements (SLAs) and regulatory requirements.

[0068] BQUICK_TOP server 1005 is a computing device similar to servers 1012A and 1012B and configured to communicate with them. In some embodiments, BQUICK_TOP server 1005 includes software advantageously configured to address latency issues through network optimization, infrastructure upgrades, and efficient routing to ensure a reliable and responsive internet experience for its customers. In some embodiments, BQUICK_TOP server 1005 may receive network activity logs, including but not limited to business patterns, usage statistics, and security events from servers 1012A and 1012B. In some embodiments, BQUICK_TOP server 1005 employs monitoring tools to continuously analyze business data to detect anomalies, troubleshoot network problems, and ensure compliance with Service Level Agreements (SLAs) and regulatory requirements. In some embodiments, BQUICK_TOP server 1005 is a platform configured to perform real-time latency monitoring, real-time latency analysis, and real-time latency optimization. In some embodiments, latency optimization is performed to provide reports indicating latency issues. In some embodiments, the BQUICK_TOP server 1005 can configure paths and control devices in networks 1002A and 1002B to meet low latency requirements.

[0069] BQUICK_TOP server 1005 and BQUICKISP_B server 1012B are similar to BQUICKISP_A server 1012A and can be configured to operate within residences 1016B and 1018B. Residences 1016A, 1018A, 1016B, and 1018B are similar to each other and may contain similar devices. Residence 1018B includes a cable modem 1030B, a set-top box 1036B, a game controller 1038, a television 1034, and a user device 1032. User device 1032 is similar to user device 1022. Headend 1008B is similar to headend 1008A, and ISP infrastructure 1006B is similar to ISP infrastructure 1006A. Televisions 1024 and 1034 are monitors, smart TVs, or other audio / video equipment. In some embodiments, networks 1002A and 1002B may include cameras, security equipment, fire and safety equipment, smart home appliances, etc., that communicate with infrastructures 1006A and 1006B. In some embodiments, ISP infrastructures 1006A and 1006B may each include fiber optic cables, coaxial cables, remote nodes, splitters, and other equipment for cable customers. Equipment may include amplifiers, remote physical devices or layers, and remote media access control devices or layers. Intermediate nodes in ISP infrastructures 1006A and 1006B can process data packets and monitor latency and traffic at various points in the network. In some embodiments, BQUICK_TOP server 1005, BQUICK ISP_B server 1012B, and BQUICK_ISP_A server 1012A are controlled by an ISP (e.g., the respective ISP).

[0070] In some embodiments, ISP infrastructure 1006B is coupled to residences 1016B and 1018B via coaxial cable. Cable modem 1030B is a device configured to connect devices in residence 1018B to ISP infrastructure 1006B. In some embodiments, cable modem 1030 includes a computer, router, gateway, or other communication device. Modem 1030 may be configured to provide a wireless network for communicating with devices in residence 1018B. In some embodiments, repeaters, amplifiers, signal conditioners, etc., may be located on the cable associated with modem 1030. In some embodiments, cable modem refers to any device used for communication across a cable. Optical network unit 1020 and modem 1030 provide data connectivity to the ISP data pipeline via fiber optic cable or cable. All devices within the home can connect to the modem via, for example, Wi-Fi or Ethernet to achieve internet connectivity. Each node within the home (e.g., router, repeater, modem, Wi-Fi access point) can introduce latency. In some embodiments, the ONU 1020 and modem 1030 can be any device in a home or business that connects to an ISP via an Internet data pipeline through a coaxial cable, fiber optic cable, digital subscriber line (DSL), or cell connection (e.g., via a tower (e.g., a 5G, LTE modem)).

[0071] Set-top box 1036 is configured to receive and decode digital television, movie, streaming media, or other video signals for viewing on television 1034. Set-top box 1036 may be configured for gaming and can communicate with game controller 1038. Set-top box 1036 may also be configured to provide internet access, shopping services, home automation, audio features, screen mirroring, etc. In some embodiments, set-top box 1036 includes one or more processors, memory, a dedicated graphics processing unit (GPU), and / or storage capacity for storing games, applications, latency data, and recorded content. Set-top box refers to any device connected to a television or monitor that allows a user to receive and decode video signals. In some embodiments, set-top box may serve as an interface between a television and various broadcast media sources, such as cable television, satellite, or internet-based streaming media services. Dashed lines in the figures may represent virtual connections, while solid lines may represent physical connections (e.g., wires or fiber optic cables).

[0072] Cloud infrastructure 1004, headends 1008A and 1008B communicate virtually or directly with the Internet 1009. Headends 1008A and 1008B may be associated with buildings 111A and 111B, respectively. In some embodiments, communication system 100 is typically an end-to-end combination of networking elements for networking services from a home or business to the Internet 1009 (e.g., the public Internet). In some embodiments, cloud infrastructure 1004 is a group of multiple servers, switches, and storage units. ISPs may have a data center / cloud server pool co-located with headends 1008A and 1008B, or a dedicated link from headends 1008A and 1008B to cloud infrastructure 1004 and a headend connection to the Internet 1009.

[0073] Although cloud infrastructure 1004 is presented as a single block, cloud servers and data servers may co-locate with ISP headends 1008A and / or 1008B. Cloud servers may be located at third-party private facilities, and the ISP may have a dedicated physical link or a link via the Internet 1009. Depending on congestion and server processing capacity, cloud infrastructure 1004 may be a source of latency. In some embodiments, cloud server processing elements may be upgraded to support latency monitoring applications (e.g., BQUICK applications) or configurable devices to support low-latency services. Headends 1008A and 1008B may be central facilities (e.g., central offices). In some embodiments, "headend" refers to a facility that receives, processes, and routes Internet data or audio / video content to end users, such as residential or business owners. Headends 1008A and 1008B may have multiple switching, routing, data metering, queuing, security elements, and / or other devices that may introduce latency. The 1008A and 1008B headends can also host cable modem terminal systems (CMTS) in cable networks, DSLAMs (Digital Subscriber Line Access Multiplexers) in DSL networks, and OLTs (Optical Line Terminals) in fiber optic networks.

[0074] Networks 1002A and 1002B are operated by ISP-A and ISP-B, respectively. ISPs extend their services to various residences or businesses within a community, city, or specific area. Networks 1002A and 1002B represent two dissimilar networks served by the same or different ISPs, which may be located in the same community or completely different regions or countries. Homeowners or business owners seek ISPs that provide services in their local area and subscribe to internet services accordingly.

[0075] B. Application

[0076] System 100 advantageously includes an ISP infrastructure BQUICK application 1056A for ISP infrastructure 1006A, a headend BQUICK application 1058A for headend 1008A, a modem BQUICK application 1020A for optical network unit 1020, a user device BQUICK application 1022A for user device 1022, and a television BQUICK application 1024A for television 1024. Applications 1056A, 1058A, 1020A, 1022A, and 1024A may be software applications or programs designed to perform specific tasks or provide specific functions described herein (e.g., latency monitoring, latency analysis, latency optimization, and communication and storage of related data). Applications 1056A, 1058A, 1020A, 1022A, and 1024A can be installed on any electronic device in the communication system 100, including but not limited to servers, computers, smartphones, tablets, smart devices, home appliances, cameras, security devices, vehicles, user devices, and other digital platforms. In some embodiments, applications 1056A, 1058A, 1020A, 1022A, and 1024A can run on Windows, macOS, iOS, Android, or other operating systems, or can be web-based and accessible via an internet browser. In some embodiments, applications 1056A, 1058A, 1020A, 1022A, and 1024A can be cross-platform, capable of running on multiple OS environments. Applications 1056A, 1058A, 1020A, 1022A, and 1024A can be installed from various sources (e.g., app stores, software repositories) or directly from an ISP's website. In some embodiments, applications 1056A, 1058A, 1020A, 1022A, and 1024A are configured to communicate with the BQUICK_TOP server 1005 via a virtual connection. In some embodiments, applications 1056A, 1058A, 1020A, 1022A, and 1024A are configured to communicate with the BQUICK_TOP server 1005 via the BQUICK ISP_A server 1012A. Applications 1056A, 1058A, 1020A, 1022A, and 1024A may be updated via an app store or via automatic updates, depending on device settings.

[0077] BQUICK applications 1056A, 1058A, 1020A, 1022A, and 1024A are configured to facilitate integration and communication with other services or platforms, data sharing, collaboration, and / or seamless access to additional functionality. Applications 1056A, 1058A, 1020A, 1022A, and 1024A allow optical network unit 1020, television 1024, and user device 1022 to monitor latency, store subscription information (e.g., classic bandwidth in megabits per second (MPPS), monitor low-latency bandwidth (MBPS), and hybrid jitter in milliseconds), and provide options for upgrading internet services. In some embodiments, latency and subscription information may be tracked based on device, device type, user identification, application, residence identification, etc. In some embodiments, latency information may be provided to BQUICK_TOP server 1005 in timestamped packets. The user interface can be provided by applications 1056A, 1058A, 1020A, 1022A, and 1024A on the optical network unit 1020, television 1024, and user device 1022 to upgrade or downgrade to different service levels based on latency information. In some embodiments, different service levels can be provided to a latency server and BQUICK_TOP server 1005, BQUICKISP_A BQUICK server 1012A, or BQUICKISP_B BQUICK server 1012B.

[0078] System 100 advantageously includes an ISP infrastructure BQUICK application 1056B for ISP infrastructure 1006B, a headend BQUICK application 1058B associated with headend 1008B, a modem BQUICK application 1030B for modem 1030, and a set-top box BQUICK application 1036B for set-top box. Applications 1056B, 1058B, 1030B, and 1036B are similar to applications 1056A, 1058A, 1020A, 1022A, and 1024A. In some embodiments, when applications 1030B, 1036B, 1056A, 1056B, 1058B, 1058A, 1020A, 1022A, and 1024A are installed or associated devices join the network, applications 1030B, 1036B, 1056A, 1056B, 1058B, 1058A, 1020A, 1022A, and 1024A are registered at server 1012 for operations consistent with those described herein. User device 1032, television 1034, and game controller 1038 may also include applications similar to BQUICK applications 1022A and 1024A.

[0079] In some embodiments, BQUICK applications 1030B, 1036B, 1056A, 1056B, 1058B, 1058A, 1020A, 1022A, and 1024A are latency applications configured to deliver data to provide topology reports. The topology report identifies devices / networks end-to-end. In some embodiments, latency requirements for each device are provided in the report (e.g., based on device, usage type, user ID, or application). In some embodiments, the report may be stored at server 1012. Latency requirements across the topology can be used for traffic shaping, flow prioritization, etc. In some embodiments, the report tracks which devices are offline, such that in some embodiments, bandwidth reserved for those devices can be made available to another device. In some embodiments, the report tracks whether a device is not running a low-latency (e.g., BQUICK) application and whether it is online, such that in some embodiments, bandwidth reserved for that device can be made available to other devices. In some embodiments, offline refers to a state where a device, system, or application is not actively communicating with other devices or accessing online resources. In some embodiments, a device that is turned off or in hibernation is offline. In some embodiments, the low-latency application can be offline when it is not running.

[0080] In some embodiments, low-latency packets are tagged so that applications 1030B and 1036B, 1056A, 1056B, 1058B, 1058A, 1020A, 1022A, and 1024A can process the packets and streams as low-latency streams. In some embodiments, a terminal device (e.g., application 1024A) may send a command or request indicating that latency requirements have not been met, and in some embodiments, each application in the path (applications 1020A, 1056A, and 1058A) may respond to this command by processing that device's packets with higher priority or removing the service from that path. Latency issues can originate from APs, meshes, devices, or nodes. Tracking the bit rate or latency at each location allows the solution to be directed to the specific location of the latency problem.

[0081] refer to Figure 1BResidential building 1018B may include an access point 1031 communicating with a modem 1030, a wireless router 1074 communicating with a television 1034, a television 1035, a set-top box 1036, and a user device 1032. Access point 1031 may be integrated with modem 1030 or may be a separate unit. User device 1032 includes a user device BQUICK application 1032B, and access point 1031 includes a latency access point application 1031B. Router 1074 includes a wireless router BQUICK application 1074B, television 1034 includes a television BQUICK application 1034B, and television 1035 includes a television BQUICK application 1035B. In some embodiments, the BQUICK_TOP server 1005, BQUICK_ISP_A server 1012A, and BQUICK_ISP_B server 1012B communicate virtually with applications 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, and 1058B. In some embodiments, "server" refers to any computing device that provides services or resources to other computers or clients within the network.

[0082] Applications 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, and 1058B are similar to applications 1056A, 1058A, 1020A, 1022A, and 1024A. Applications 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, and 1058B allow modems 1030, televisions 1034 and 1035, access point 1031, router 1074, set-top box 1036, user device 1032, and other cable modem terminal systems to monitor latency, store subscription information (e.g., classic bandwidth in megabits per second (MPPS), low-latency bandwidth (MBPS), and hybrid jitter in milliseconds), and provide options for upgrading Internet services. The user interface can be configured on the optical network unit 1020, television 1024, and user device 1022 to upgrade or downgrade to different service levels based on latency information. In some embodiments, this capability is available even if the device is a third-party device. In some embodiments, application 1031B or 1074B can be configured to update network topology information to the BQUICK TOP server 1012, and applications 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, and 1058B can monitor low-latency resources, request services, register devices, and request different latency processing (e.g., for video, audio, commands, downloads, etc.). In some embodiments, the devices or nodes associated with applications 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, and 1058B may include algorithms for changing packet priorities based on time and latency requirements. Applications 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, and 1058B may communicate using virtual or logical connections (e.g., using the Internet 1009).

[0083] Access point 1031 is a networking device that allows Wi-Fi-enabled devices to connect to a wired network. In some embodiments, access point 1031 acts as a bridge between wireless devices (e.g., wireless router 1074, set-top box 1036, user device 1032, television 1034 and 1035) and wired network infrastructure (e.g., modem 1030, router, switch, and server). Wireless router 1074 may be a networking device that provides a wireless access point for a wireless network. Wireless router 1074 acts as a hub for a wireless local area network (LAN), allowing multiple devices in or around residence 1018B to connect to the Internet and communicate with each other. Wireless router 1074 may include a wireless built-in Ethernet switch that provides multiple ports for connecting wired devices. In some embodiments, a wired connection can connect router 1074 to access point 1031 or modem 1030. In some embodiments, "wireless router" refers to any device that provides a wireless access point for a wireless network.

[0084] refer to Figures 1B to 1C Applications 1030B and 1032B communicate with the BQUICK_TOP server 1005 via a logical interface. The architecture of applications 1030B and 1032B can be used in any of applications 1031B, 1036B, 1074B, 1034B, 1035B, 1056B, 1058B, 1056A, 1058A, 1020A, 1022A, and 1024A. The logical interface is a virtual interface that represents a specific network configuration or functionality within a networking device (e.g., modem 1030 or user device 1032). In some embodiments, the logical interface is software-defined and can be created, configured, and managed within the device's operating system. Applications 1030B and 1032B may include modems, routers, access points, mesh devices, set-top boxes, AR / VR devices, game consoles, mobile phones, over-the-top (OTT) devices, etc. Applications 1030B and 1032B, and cloud infrastructure 1004 can communicate using application-to-application communication. In some embodiments, application-to-application communication is the exchange of data, messages, or commands between two or more software applications running on the same or different devices over a network. In some embodiments, application-to-application communication enables integration and collaboration between different applications, allowing them to share information, trigger actions, or synchronize state without user intervention. The BQUICK_TOP server 1012 may include an application for monitoring and / or determining end-to-end latency.

[0085] In some embodiments, applications 1020A, 1024A, 1032B, 1034B, 1035B, 1036B, and 1032B are client-level applications. Application 1036B can be configured to have the highest priority (e.g., the lowest latency application), while normal streaming latency is associated with applications 1020A, 1024A, 1032B, 1034B, 1035B, and 1032B. Applications 1074B and 1031B are node-level applications and can be configured to provide or assign priority to applications 1020A, 1024A, 1032B, 1034B, 1035B, 1036B, and 1032B (client-level applications) and associated devices. Application 1030B can be configured to provide or assign priority among applications 1036B, 1074B, and 1031B (e.g., node-level applications) and applications 1020A, 1024A, 1032B, 1034B, 1035B, and 1032B (e.g., client-level applications) and their associated devices. In some embodiments, cloud-level applications may include applications 1056B and 1058B. In some embodiments, the partitioning of applications 1056B, 1058B, 1020A, 1024A, 1030B, 1032B, 1034B, 1035B, 1036B, 1074B, and 1032B allows for the separation of local and cloud processing, reduced cloud server communication and ISP bandwidth, local data storage and security, local resource availability (including edge processing and filtering of information), and faster response to low-latency devices. In some embodiments, application 1030B has a server extension and handles communication between server 1012 and applications 1020A, 1024A, 1032B, 1034B, 1035B, 1036B and 1032B.

[0086] In some embodiments, when application 1030B includes a server extension, application 1030B may be a client-level application or a cloud-level application and maintain a virtual connection to server 1012. In some embodiments, the server extension provides the following advantages: decoupling development from the ISP, which can facilitate standardization; a direct data path from application 1020A or 1031B to the application developer's server; maintaining local data privacy; availability of local resources (e.g., local machine learning (ML), edge processing, and filtering information); and faster response to local low-latency gadgets or devices.

[0087] In some embodiments, applications 1056B, 1058B, 1020A, 1024A, 1030B, 1032B, 1034B, 1035B, 1036B, 1074B, and 1032B can synchronize time references across all nodes and end-user devices. Applications 1056B, 1058B, 1020A, 1024A, 1030B, 1032B, 1034B, 1035B, 1036B, 1074B, and 1032B utilize the timestamps of low-latency data packets at each node. In some embodiments, this enhancement enables the determination of latency at each node and reporting it to server 1012. In some embodiments, by utilizing the Precision Time Protocol (PTP), applications 1056B, 1058B, 1020A, 1024A, 1030B, 1032B, 1034B, 1035B, 1036B, 1074B, and 1032B can use timestamps to distinguish whether latency originates from a home network, an ISP, or a cloud server. Each device may have an associated PTP clock that communicates with the application associated with the device. Latency at each node can be shared across the network, allowing the network to avoid devices with latency issues or to perform other operations to reduce latency at that node (e.g., offloading higher-latency traffic from the problematic node). In some embodiments, the PTP clock may be derived from a satellite clock.

[0088] refer to Figure 1C Applications 1030B and 1032B each include a latency module 1040, an application 1042, an application framework 1044, a library and hardware abstraction layer 1046, a driver and Linux kernel 1048, and hardware and firewall 1050. In some embodiments, the latency module 1040 is configured to control and monitor the hardware and firewall based on latency. The latency module or BQUICK module 1040 is software configured to provide the low-latency operation described herein. Application 1042 is an application for performing various operations and may contain third-party applications (e.g., Android installer tools (APKs)). Application framework 1044 is a set of structured software components that provide the necessary infrastructure for building and running applications.

[0089] The Library and Hardware Abstraction Layer 1046 provides a standardized interface for device drivers to interact with hardware components. The Library and Hardware Abstraction Layer 1046 allows applications and system services to access hardware functionality across different devices in a consistent manner. The Library and Hardware Abstraction Layer 1046 provides developers with a collection of pre-written code that can be used to perform common tasks or implement specific functionality, and typically contains reusable functions, classes, or modules that provide specific capabilities.

[0090] In some embodiments, the driver and Linux kernel 1048 act as a bridge between the hardware and software layers of the system, managing system resources. In some embodiments, the driver and Linux kernel 1048 provide basic services and facilitate communication between software processes and hardware devices. In some embodiments, the driver and Linux kernel 1048 include software components that facilitate communication between the operating system (OS) and hardware devices.

[0091] refer to Figure 1D Functions, services, processes, or operations 1080 can be provided by applications 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, 1058B, 1056A, 1058A, 1020A, 1022A, and 1024A. Figure 1A and 1B Any control within the network device or system 100. Operation 1080 uses classifier 1082, low-latency queue 1084, and classic queue 1086. Queues 1084 and 1086 are used to manage network devices or systems 100. Figure 1A A queue is a memory or logical construct (e.g., implemented using data structures) of packets or message flows within a communication system 100. In some embodiments, queue 1084 is associated with a high-performance path, while queue 1086 is associated with a low-performance path. In some embodiments, a queue refers to any structure used for storing information (e.g., packets). Any network device may have separate queues to support low-latency services and may have multiple queues within the communication system 100. Figure 1A Operations can be performed on any device within the application. Applications 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, 1058B, 1056A, 1058A, 1020A, 1022A, and 1024A can independently report the latency of each queue.

[0092] In some embodiments, queues 1084 and 1086 are configured as first-in-first-out (FIFO) buffers that temporarily store packets or messages before they are transmitted or processed. In some embodiments, queue 1084 may store messages for high-performance paths (e.g., low-latency paths), and queue 1086 may store messages for low-performance paths (e.g., high-latency paths). In some embodiments, low-latency operations may use low-performance paths, while high-latency operations may use high-performance paths, or each may use the same path. In some embodiments, a path refers to any communication route or channel through which data or information travels from its source to its destination (e.g., via a device and across a medium). In some embodiments, a path may include intermediate components and links involved in transmitting data between two or more points in one or more networks. In some embodiments, a low-latency path refers to a path used for low-latency services.

[0093] Classifier 1082 is a processor and / or software configured to classify or categorize network services based on certain criteria (e.g., according to latency requirements and / or priority). In some embodiments, classifier 1082 is configured to enforce network policies, prioritize services (e.g., for high-performance or low-performance paths), and / or apply specific actions based on classification results. Classifier 1082 distinguishes different categories of services (e.g., voice, video, data) and applies QoS policies to ensure that critical applications receive sufficient bandwidth and latency requirements. Classifier 1082 prioritizes services based on predefined criteria, ensuring that important or time-sensitive applications are processed before less critical services by appropriately serving services to queues 1084 and 1086. In some embodiments, classifier 1082 may utilize information about customer subscriptions (e.g., device level, user level, residential level) to classify services.

[0094] refer to Figure 1E Operation 1088 can be controlled by any of the applications 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, 1058B, 1056A, 1058A, 1020A, 1022A, and 1024A. Operation 1088 is similar to operation 1080 and utilizes a classifier 1090, a first low-latency queue 1092, a second low-latency queue 1094, a classic queue 1096, and a priority queue 1098. Queues 1092, 1094, 1096, and 1098 are used to manage network devices or systems 100 (…). Figure 1AThis refers to a memory or data structure containing packets or message flows within a network. In some embodiments, queues 1092 and 1094 are associated with high-performance paths, while queue 1096 is associated with low-performance paths. In some embodiments, queue 1098 receives messages from queues 1092 and 1094 and provides messages or data to high-performance paths based on a priority scheme associated with queues 1092 and 1094. In some embodiments, classifier 1090 is similar to classifier 1082 and is configured to classify or categorize network traffic based on certain criteria (e.g., latency requirements) of queues 1092, 1094, and 1096. In some embodiments, classifiers 1082 and 1090 are software modules operating on a device (e.g., a server, an ISP-provided device, a user device, etc.). In some embodiments, queues 1084, 1086, 1092, 1094, 1096, and 1098 are virtual queues provided on the memory of a device configured by operating 1080 or 1088. In some embodiments, queues 1084, 1086, 1092, 1094, 1096, and 1098 are dedicated hardware queues (e.g., FIFO memories) on the device. In some embodiments, classifiers 1090 and 1082, as well as queues 1084, 1086, 1092, 1094, 1096, and 1098, are implemented in the application layer of the device and can utilize the services and structures provided by the media access layer and the physical layer. In some embodiments, classifiers 1082 and 1090 can be configured via commands provided by the BQUICK TOP server 1012 to appropriately classify low-latency traffic.

[0095] In some embodiments, applications 1080 and 1088 are configured to operate at nodes associated with devices, including but not limited to ONU 1020, modem 1030, set-top box 1036, television 1024, access point 1031, user equipment 1032, and / or router 1074. Applications 1080 and 1088 are configured to control and / or partition subscribed low-latency bandwidth services (e.g., 20 Mbps vs. 50 Mbps), track latency statistics (e.g., minimum, maximum, and average latency of low-latency streams), process five tuples (e.g., source IP address, source port, destination IP address, destination port, and transport protocol) of X streams (where X is any integer) with latency and / or bandwidth requirements, monitor latency introduced by nodes, provide timestamps at ingress and egress ports, monitor buffer depth, enforce boundary clock precision protocols (e.g., the IEEE 10588-2008 standard and its extensions), and prioritize services among multiple low-latency clients. Monitoring and measurement information can be appended to packets to provide them to other nodes and servers (e.g., server 1012). For example, timestamps can be applied to packets at each node or device. Latency can be determined by comparing timestamps. In some embodiments, applications 1080 and 1088 are also configured to track the state of low-latency applications and provide a user interface for controlling low-latency configurations. In some embodiments, classifiers 1082 and 1090 and / or queues 1084, 1086, 1092, 1094, 1096 are configured by applications 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, 1058B, 1056A, 1058A, 1020A, 1022A, and 1024A (e.g., at each respective node). In some embodiments, servers 1012, 1012A, and 1012B configure classifiers 1082 and 1090 and / or queues 1084, 1086, 1092, 1094, and 1096 via virtual connections.

[0096] Applications 1080 and 1088 can identify end-to-end bandwidth available for low-latency applications, provide users with real-time feedback on monitored latency, and adjust latency responses. In some embodiments, adjustments may be made in response to purchased services or bandwidth upgrades. In some embodiments, applications 1080 and 1088 can be configured to offer advertisements or customer offers for low-latency resources. Applications 1080 and 1088 can address variable latency for each user and adjust latency levels at specific times or within specific time periods. In some embodiments, latency information may be transmitted as a timestamp appended to the packets or packet identifiers (e.g., 5 tuples and a sequence number) described herein to servers 1012A, 1012B, and 1012, and applications 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, 1058B, 1056A, 1058A, 1020A, 1022A, and 1024A. In some embodiments, the timestamp information may be sent to servers 1012A, 1012B, and / or 1012 via a separate virtual / logical channel.

[0097] refer to Figure 1F Cloud infrastructure 1004 may contain application 1004A. Application 1004A is similar to applications 1030B, 1031B, 1036B, 1074B, 1032B, 1034B, 1035B, 1056B, and 1058B. BQUICK TOP server 1012 may be configured to monitor AR / VR applications and / or metaverse applications. Applications running on BQUICK TOP server 1012 can perform monitoring functions. Application 1004A communicates with BQUICK TOP server 1012. Servers 1012A and 1012B may contain applications similar to application 1004A.

[0098] Using applications 1020A, 1024A, 1030B, 1032B, 1034B, 1035B, 1036B, 1074B, and 1032B, low-latency usage can be facilitated by ISP-provided devices, customer-owned AR / VR setups, mobile phones, over-the-top (OTT) devices, and cloud gaming clients. Applications 1020A, 1024A, 1030B, 1032B, 1034B, 1035B, 1036B, 1074B, and 1032B allow devices in residences 1018A and 1018B to interact with the server extension and modem 1030 or router (e.g., provided by the ISP) integrated into the ONU 1020. Additionally, the server extension has the ability to filter all necessary information and transmit it to servers 1012A and 1012B or share open data with application developers.

[0099] C. Computing Environment

[0100] Before discussing the details of embodiments of the system and method of this solution, it may be helpful to discuss the computing environment in which such embodiments may be deployed.

[0101] like Figure 2A As shown, computer 2001 may include one or more processors 2003, volatile memory 2022 (e.g., random access memory (RAM)), non-volatile storage 2028 (e.g., one or more hard disk drives (HDDs) or other magnetic or optical storage media, one or more solid-state drives (SSDs) (e.g., flash drives or other solid-state storage media), one or more hybrid magnetic and solid-state drives and / or one or more virtual storage volumes (e.g., cloud storage) or a combination of such physical storage volumes and virtual storage volumes or an array thereof), user interface (UI) 2023, one or more communication interfaces 2018, and communication bus 2050. User interface 2023 may include graphical user interface (GUI) 2024 (e.g., touch screen, display, etc.) and one or more input / output (I / O) devices 2026 (e.g., mouse, keyboard, microphone, one or more speakers, one or more cameras, one or more biometric scanners, one or more environmental sensors, one or more accelerometers, remote control, video game controller or joystick, etc.). Non-volatile memory 2028 stores operating system 2015, one or more application programs 2016, and data 2017, such that computer instructions, such as those of operating system 2015 and / or application programs 2016, are executed by processor 2003 outside of volatile memory 2022. In some embodiments, volatile memory 2022 may include one or more types of RAM and / or cache memory, which can provide a faster response time than main memory. Data can be input using the input device of GUI 2024 or received from I / O device 2026. Various components of computer 2001 can communicate via one or more communication buses (shown as communication bus 2050).

[0102] like Figure 2AThe computer 2001 shown herein is for illustrative purposes only. Clients, servers, intermediary devices, and other networking devices can be implemented by any computing or processing environment and can be implemented using any type of machine or set of machines that has suitable hardware and / or software capable of operating as described herein. The processor 2003 can be implemented by one or more programmable processors to execute one or more executable instructions, such as a computer program, to perform the functions of the system. As used herein, the term "processor" describes a circuit system that performs a function, operation, or sequence of operations. Functions, operations, or sequences of operations can be hard-coded into the circuit system or can be soft-coded by instructions stored in a memory device and executed by the circuit system. A "processor" can perform functions, operations, or sequences of operations using digital values ​​and / or analog signals. In some embodiments, a "processor" can be embodied in one or more application-specific integrated circuits (ASICs), microprocessors, digital signal processors (DSPs), graphics processing units (GPUs), microcontrollers, field-programmable gate arrays (FPGAs), programmable logic arrays (PLAs), multi-core processors, or general-purpose computers with associated memory. A "processor" can be analog, digital, or mixed-signal. In some embodiments, a "processor" may be one or more physical processors or one or more "virtual" (e.g., remotely located or "cloud") processors. A processor containing multiple processor cores and / or multiple processors may provide the ability to execute instructions in parallel and simultaneously, or to execute an instruction in parallel on more than one data line.

[0103] The communication interface 2018 may include one or more interfaces to enable the computer 2001 to access a computer network, such as a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or the Internet, via various wired and / or wireless or cellular connections.

[0104] In some implementations, computing device 2001 may execute applications on behalf of a user of a client computing device. For example, computing device 2001 may execute a virtual machine that provides an execution session within which an application executes an application on behalf of a user or client computing device, such as a hosted desktop session. Computing device 2001 may also execute a terminal services session to provide a hosted desktop environment. Computing device 2001 may provide access to a computing environment comprising one or more of the following: one or more applications, one or more desktop applications, and one or more desktop sessions in which one or more applications can execute.

[0105] refer to Figure 2BThis describes a computing environment 2060. The computing environment 2060 can generally be considered as implemented as a cloud computing environment, an on-prem (“on-prem”) computing environment, or a hybrid computing environment comprising one or more on-prem and one or more cloud computing environments. When implemented as a cloud computing environment (also referred to as a cloud environment, cloud computing, or cloud network), the computing environment 2060 can provide shared services (e.g., computer services) and the delivery of shared resources (e.g., computer resources) to multiple users. For example, the computing environment 2060 may include an environment or system for providing or delivering access to multiple shared services and resources to multiple users via the Internet. Shared resources and services may include, but are not limited to, networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, databases, software, hardware, analytics, and intelligence.

[0106] In some embodiments, computing environment 2060 may provide client 2062 with one or more resources provided by a network environment. Computing environment 2062 may include one or more clients 2062a to 2062n communicating with cloud 2068 via one or more networks 2064. Client 2062 may include, for example, fat clients, thin clients, and zero clients. Cloud 2068 may include a backend platform, such as server 1005, storage, server farm, or data center. Client 2062 may communicate with... Figure 2A The computer is the same as or substantially similar to the 2001 computer.

[0107] User or client 2062 may correspond to a single organization or multiple organizations. For example, computing environment 2060 may include a private cloud (e.g., an enterprise cloud) serving a single organization. Computing environment 2060 may include a community cloud or public cloud serving multiple organizations. In some embodiments, computing environment 2060 may include a hybrid cloud, which is a combination of a public cloud and a private cloud. For example, cloud 2068 may be public, private, or hybrid. Public cloud 2068 may include a public server maintained by a third party for client 2062 or the owner of client 2062. The server may be geographically located at a remote geographic location, as described above or elsewhere publicly available. Public cloud 2068 can be connected to the server via public network 2064. Private cloud 2068 may include a private server physically maintained by client 2062 or the owner of client 2062. Private cloud 2068 can be connected to the server via private network 2064. Hybrid cloud 2068 may include both private and public networks 2064 and the server.

[0108] Cloud 2068 may include a backend platform, such as servers, storage, server farms, or data centers. For example, cloud 2068 may include or correspond to servers or systems remote from one or more clients 2062 to provide third-party control over shared services and resource pools. Computing environment 2060 may provide resource pooling to serve multiple users via clients 2062 through a multi-tenant environment or multi-tenant model, wherein different physical and virtual resources are dynamically assigned and reallocated in response to different needs within the respective environment. A multi-tenant environment may include a system or architecture that provides software, applications, or a single instance of a software application to serve multiple users. In some embodiments, computing environment 2060 may provide on-demand self-service to unilaterally provide computing power (e.g., server time, network storage) to multiple clients 2062 across a network. Computing environment 2060 may provide elasticity to dynamically scale out or expand in response to different needs from one or more clients 2062. In some embodiments, computing environment 2060 may include or provide monitoring services to monitor, control, and / or generate reports corresponding to the shared services and resources provided.

[0109] In some embodiments, computing environment 2060 may include and provide different types of cloud computing services. For example, computing environment 2060 may include Infrastructure as a Service (IaaS). Computing environment 2060 may include Platform as a Service (PaaS). Computing environment 2060 may include serverless computing. Computing environment 2060 may include Software as a Service (SaaS). For example, cloud 2068 may also include cloud-based delivery, such as Software as a Service (SaaS) 2070, Platform as a Service (PaaS) 2072, and Infrastructure as a Service (IaaS) 2074. IaaS can refer to a user renting infrastructure resources required for a specific period of time. IaaS providers may offer storage, networking, server, or virtualization resources from a large pool, allowing users to quickly scale as needed by accessing more resources. IaaS instances include Amazon Web Services provided by Amazon.com, Inc. of Seattle, Washington; Rackspace Cloud provided by Rackspace US, Inc. of San Antonio, Texas; Google Compute Engine provided by Google Inc. of Mountain View, California; or RightScale provided by RightScale, Inc. of Santa Barbara, California. PaaS providers offer the functionality provided by IaaS, including, for example, storage, networking, servers, or virtualization, as well as additional resources, such as, for example, operating systems, middleware, or runtime resources. PaaS instances include Windows Azure provided by Microsoft Corporation of Redmond, Washington; Google App Engine provided by Google Inc.; and Heroku provided by Heroku, Inc. of San Francisco, California. SaaS providers offer the resources offered by PaaS, including storage, networking, servers, virtualization, operating systems, middleware, or runtime resources. In some embodiments, SaaS providers may offer additional resources, including, for example, data and application resources.SaaS instances include Google Apps, provided by Google Inc.; Saleforce, provided by Salesforce.com Inc. of San Francisco, California; or Office 365, provided by Microsoft Corporation. SaaS instances may also include data storage providers such as Dropbox, Inc. of San Francisco, California; Microsoft SkyDrive, provided by Microsoft Corporation; Google Drive, provided by Google Inc.; or Apple iCloud, provided by Apple Inc. of Cupertino, California.

[0110] Client 2062 can access IaaS resources using one or more IaaS standards, including, for example, Amazon Elastic Compute Cloud (EC2), Open Cloud Computing Interface (OCCI), Cloud Infrastructure Management Interface (CIMI), or OpenStack standards. Some IaaS standards allow clients to access resources via HTTP and can use the Representative State Transfer (REST) ​​protocol or Simple Object Access Protocol (SOAP). Client 2062 can access PaaS resources using different PaaS interfaces. Some PaaS interfaces use HTTP packets, standard Java APIs, Java Mail APIs, Java Data Objects (JDO), Java Persistence APIs (JPA), Python APIs, network integration APIs for different programming languages ​​(including, for example, Ruby's Rack, Python's WSGI, or Perl's PSGI), or other APIs that can be built on REST, HTTP, XML, or other protocols. Client 2062 can access SaaS resources via a web-based user interface provided by a web browser (such as Google Chrome, Microsoft Internet Explorer, or Mozilla Firefox provided by the Mozilla Foundation of Mountain View, California). Client 2062 can also access SaaS resources via smartphone or tablet applications, including applications such as Salesforce Sales Cloud or Google Drive. Client 2062 can also access SaaS resources through the client's operating system, including, for example, the Windows file system for Dropbox.

[0111] In some embodiments, access to IaaS, PaaS, or SaaS resources can be authenticated. For example, a server or authentication server can authenticate users via a security certificate, HTTPS, or an API key. The API key can contain various encryption standards, such as, for example, Advanced Encryption Standard (AES). Data resources can be sent via Transport Layer Security (TLS) or Secure Sockets Layer (SSL).

[0112] While examples of the communication systems described above may include devices operating according to Ethernet and other standards, it should be understood that embodiments of the described systems and methods may operate according to alternative standards and utilize various wireless communication devices. For example, multi-unit communication interfaces associated with cellular networks, satellite communications, vehicular communication networks, wired networks, and networks may utilize the systems and methods described herein without departing from the scope of the systems and methods described herein.

[0113] D. Systems and methods for bandwidth allocation in passive optical networks

[0114] The following is a detailed description of various concepts related to techniques, approaches, methods, devices, and systems for bandwidth allocation in passive optical networks, as well as embodiments of these techniques, approaches, methods, devices, and systems. The various concepts introduced above and discussed in more detail below can be implemented in any of a variety of ways, as the described concepts are not limited to any particular implementation. Specific embodiments and examples of applications are provided primarily for illustrative purposes.

[0115] The technical solutions disclosed herein address the challenges of bandwidth allocation in Passive Optical Networks (PONs). Optical Line Terminals (OLTs) communicating with one or more Optical Network Terminals (ONTs) can dynamically manage bandwidth allocation. A Dynamic Bandwidth Allocation (DBA) engine configured within the OLT allocates Constant Bit Rate (CBR) bandwidth from the upstream bandwidth capacity of the PON. CBA bandwidth allocation responds to the registration of one or more transport containers by the associated ONTs. Transport containers can be used by the ONTs for specific low-latency or CBR applications. The OLT can receive indications of the status of the low-latency or CBR applications. Status updates allow the OLT to dynamically manage bandwidth allocation among the ONTs. The OLT can communicate the updated bandwidth mapping to one or more ONTs, ensuring that each ONT receives an appropriate bandwidth allocation to support its operation, particularly for low-latency or CBR applications. By dynamically managing and updating bandwidth allocation, the technical solutions disclosed herein improve the efficiency and responsiveness of the network to changing demands of connected devices.

[0116] Figure 3AThis describes an example system 300A for dynamically switching between delay-sensitive and bandwidth-efficient modes in a passive optical network (PON), such as GPON (Gigabit Passive Optical Network). Example system 300A may include one or more optical network terminals (ONTs) 310A to 310N (sometimes referred to herein as optical network terminal 310) coupled to one or more optical line terminals (OLTs) 320 via one or more splitters 330. Example system 300A may include one or more client devices 325A to 325N (sometimes referred to herein as client device 325) communicatively coupled to one or more ONTs 310. OLTs 320 may receive data streams from the Internet via one or more networks 315. Figures 1A to 1F And any system described in 2A to 2B can be configured, constructed, or implemented to implement, operate, and / or use Figure 3A Any options and techniques described herein.

[0117] Point-to-multipoint (PON) is a fiber optic telecommunications technology that uses optical splitters to deliver data from a single central point to multiple end users. This point-to-multipoint architecture allows Internet Service Providers (ISPs) to serve numerous customers using a single fiber optic cable. PON is typically used for the last mile connection between ISPs and residential or commercial users, providing high-speed internet access. PON can include EPON (Ethernet Passive Optical Network) or GPON (Gigabit Passive Optical Network), among others. EPON is a PON that uses Ethernet technology for data transmission. Compared to GPON, EPON offers a simpler and more cost-effective solution. EPON is typically used in applications with lower bandwidth requirements or where cost is a primary concern. GPON is a high-speed PON technology capable of delivering downstream data rates up to 2.4 Gbps and upstream data rates up to 1.2 Gbps. GPON is preferred in applications with high bandwidth requirements where Quality of Service (QoS) is critical.

[0118] The ONT 310 may contain one or more transport containers 340A to 340N (sometimes referred to herein as transport container 340). Each transport container may contain one or more data buffers 350A to 350N (sometimes referred to herein as data buffer 350). The ONT 310 may be located at a specific residence (e.g., residence #1 in this example). The OLT 320 may contain one or more dynamic bandwidth allocation engines 345. Both the ONT 310 and OLT 320 may contain one or more low-latency agents 335. The low-latency agents 335 may be the same version or different versions of a low-latency agent.

[0119] The ONT 310 may include a device, system, or module (comprising a combination of hardware and software) that converts optical signals received from a service provider's network (via fiber optic cable) into electrical signals and vice versa. The ONT 310 may provide access to a PON (e.g., GPON (Gigabit Passive Optical Network)) to multiple end users in a residence. For example, the ONT 310 may connect to a wired Ethernet connection and provide wireless connectivity using a radio frequency link, acting as a wired access point. The ONT 310 may be implemented (e.g., configured, designed, and / or built) for operation on a wireless local area network (WLAN). In some embodiments, the ONT 310 may be configured to provide routing capabilities. The ONT 310 may be implemented to support standards for transmitting and receiving data using one or more radio frequencies. Those standards and the frequencies they use may be defined by IEEE (e.g., the IEEE 802.11 standard). The ONT 310 may be configured to support Internet hotspots and / or extend the Wi-Fi signal range of a network.

[0120] OLT 320 may include means, systems, or modules (including both hardware and software) that receive electrical signals from a service provider's network and convert them into optical signals for transmission over fiber optic cables. OLT 320 may aggregate optical signals from ONT 310 into a single multiplexed beam, which may be converted back into electrical signals. OLT 320 may be located in a service provider's central office or switching center. OLT 320 may be configured to terminate fiber optic cables from customer locations. OLT 320 may manage data communication between the service provider's network and multiple ONT 310s. For example, OLT 320 may be configured to manage upstream traffic (data sent from customer locations) and downstream traffic (data received by customer locations). OLT 320 may be configured to operate within a local area network (LAN) and / or a metropolitan area network (MAN). In some embodiments, OLT 320 may provide network management features such as service shaping and Quality of Service (QoS) management. The OLT 320 can be configured to manage network scalability and support additional services such as Internet Protocol Television (IPTV) or Voice over Internet Protocol (VoIP) to enhance network capabilities.

[0121] In some embodiments, the OLT 320 may receive data streams from the service provider's core network via network 315. For example, similar to a combination Figure 2B The network 315 of the network 2064 described may include computer networks such as the Internet, local area networks, wide area networks, metropolitan area networks or other regional networks, intranets, satellite networks, other computer networks (e.g., voice or data mobile phone communication networks), and combinations thereof.

[0122] Splitter 330 (e.g., similar to a combination) Figure 1AThe described splitter 1014A may include a device, system, or module that facilitates point-to-multipoint fiber optic network connections. Splitter 330 can be used as a service hub between OLT 320 and ONT 310, which may be located in multiple residences. Splitter 330 can be used to aggregate or multiplex fiber optic signals to a single upstream fiber optic cable. Splitter 330 can split the power of incoming optical signals from OLT 320 to distribute them among the individual ONTs 310. The number of outputs that splitter 330 may have varies depending on its design, and common configurations for specific applications include, for example, 1x2 (one input, two outputs) and 1x4 (one input, four outputs).

[0123] Client device 325 may be a wireless communication device configured for wireless communication in a wireless communication network (e.g., LAN, WAN, or cellular network). Client device 325 may be configured to wirelessly communicate with a network device (e.g., ONT 310) using any IEEE standard (e.g., IEEE 802.11 standard). Client device 325 may be combined with... Figures 1A to 1F Any user device described. In some embodiments, client device 325 may include, for example, Figure 2B The description includes one or more clients 2062, and / or one or more client devices connected to network 315 or network 2064 to access resources or services. In some embodiments, client device 325 (e.g., a computer, set-top box, AR / VR device, or game console) may establish a wired connection with ONT 310 using Ethernet or coaxial cable.

[0124] The low-latency agent 335 may include any combination of hardware and software for identifying, managing, and controlling low-latency applications. The low-latency agent 335 may provide localized management at the ONT 310 and / or OLT 320 level. In some embodiments, the low-latency agent 335 may use predefined tags, protocols, and detailed packet information (e.g., tuples, headers, and contents) to provide rapid identification and classification of data packets associated with low-latency applications.

[0125] The Transport Container (TCONT) 340 may be or contain any script, file, program, application, instruction set, or computer-executable code configured to separate and isolate different types of service flows within the GPON network. The TCONT 340 is a logical entity within the ONT 310 that encapsulates and carries a specific type of service. The TCONT 340 can be used as a virtual container for isolating and managing different data flows within the ONT 310. By separating services into TCONT 340s, the ONT 310 can allocate bandwidth and enforce QoS policies for various applications. Each TCONT 340 may be configured to use time slots allocated by the OLT 320 to transmit upstream data services. Each TCONT 340 may contain or be associated with one or more data buffers 350A to 350N (sometimes referred to herein as data buffer 350) carrying a specific type of data (e.g., voice, video, or data services). Each TCONT 340 may have an associated data queue containing the data buffer 350. A data queue can be a storage device for a list of data items in a buffer or data structure (e.g., an ordered list of data items including packets). A data queue can be a linear data structure that stores a set of data items. A data queue can be used as a buffer to hold data packets before they are transmitted. Each TCONT 340 can be configured with specific QoS parameters, such as priority or bandwidth allocation.

[0126] Each ONT 310 may have its own group of TCONTs 340 for managing its services. Each ONT 310 may register its associated TCONT 340 with the OLT 320 during the initialization process or when creating a new TCONT 340. The initialization process in PON refers to the initial setup and configuration of the ONT 310 when it is first powered on or connected to the network. This process may involve establishing communication with the OLT 320 by discovering the presence of the OLT and establishing a communication link. The ONT 310 may undergo authentication and authorization, verifying its identification code with the OLT 320 and obtaining permission to access the network. The ONT 310 may receive initial configuration parameters from the OLT 320, such as bandwidth allocation, QoS settings, and other operational parameters. TCONT registration may be a subsequent step in which the ONT 310 notifies the OLT 320 of the creation of a new TCONT 340 or the modification of an existing TCONT 340. This process allows the OLT 320 to maintain an updated view of the network topology and allocate resources accordingly. During initialization, TCONT 340s pre-configured for basic operation can be registered during the initial setup process. Newly created TCONT 340s (e.g., for on-demand services) can be registered upon creation. Each TCONT 340 within the ONT 310 can be configured to allocate bandwidth to its corresponding ONT 310 connected to the OLT 320. For example, an Alloc_ID can be assigned to a TCONT 340 to help identify and address ONT 310s connected to the OLT 320.

[0127] The Dynamic Bandwidth Allocation (DBA) engine 345 can be or contain any script, file, program, application, instruction set, or computer-executable code configured to adjust available bandwidth. The DBA engine 345 can monitor network traffic and allocate bandwidth to the ONT 310 to prevent congestion. The DBA engine 345 can determine how different devices (TCONT or ONT) connected to the OLT 320 utilize bandwidth. When allocating bandwidth, the DBA engine 345 can use predefined configuration parameters, such as QoS requirements, for example, for low-latency applications.

[0128] The DBA engine 345 can be configured to generate and maintain bandwidth (BW) maps. A bandwidth map is a visual representation illustrating the distribution and availability of network bandwidth across different segments or components. BW maps can be used for dynamic scheduling, specifying the upstream bandwidth allocation for each connected TCONT 340 associated with a particular ONT 310. Based on the BW map, the DBA engine 345 can assign specific time slots and frame structures to each TCONT for transmitting data frames upstream to the OLT 320. The DBA engine 345 can communicate the BW map, or an updated BW map, to the connected ONT 310. Each ONT 310 can be configured to transmit its data frames upstream during its assigned time slot according to the BW map. The DBA engine 345 can be configured to assign an Alloc_ID to each connected ONT 310. The Alloc_ID can be used as an identifier for the ONT 310 within the PON. Alloc_ID allows the OLT 320 to identify a specific ONT 310 when communicating with an individual ONT 310 for control or configuration purposes.

[0129] In some embodiments, the OLT 320 or DBA engine 345 may allow multiple devices to share a single data transmission frame. (As in combination) Figure 4A As shown, two ONTs 310 can be configured to use the same frame 402 to avoid collisions or interference. For example, a first ONT 310 associated with Alloc_ID 1 may transmit its data during the first portion of frame 402, and a second ONT 310 associated with Alloc_ID 2 may transmit its data during the remainder of the same frame 402. The duration of each frame 402 may be 1 millisecond. In some embodiments, the shared frame 402 may be divided into multiple smaller virtual frames 404. The duration of each virtual frame 404 may be 125 microseconds. In some embodiments, the duration of each virtual frame 404 may be determined by the latency requirements requested by the ONT 310 associated with a particular Alloc_ID, such as in combination with... Figure 4B As shown.

[0130] For example, Figure 4BThis describes how the DBA engine 345 allocates virtual frames 404 to ONTs 310 identified by their respective Alloc_IDs. In the latency optimization mode for Alloc_ID 1, the DBA engine 345 can be configured to prioritize minimizing the time delay (e.g., latency) experienced by the ONT 310 associated with Alloc_ID 1 during data transmission. As shown, Alloc_ID 1 can be given frequent opportunities to transmit data. For example, the DBA engine 345 can periodically allocate virtual frames 404 or time slots to Alloc_ID 1 at the beginning and throughout the main frame 402 to minimize latency. In the BW optimization mode for Alloc_ID 2, the DBA engine 345 can be configured to maximize data transmission capacity. For example, the DBA engine 345 can allocate one or more consecutive virtual frames 404 to Alloc_ID 2, thereby allowing the corresponding ONT 310 to transmit more data during these consecutive time slots. In some embodiments, when both Alloc_ID 1 and Alloc_ID 2 are configured for latency optimization mode, the DBA engine 345 can be configured to divide the 1ms main frame 402 into multiple virtual frames 404. The DBA engine 345 can periodically distribute these virtual frames 404 between Alloc_ID 1 and Alloc_ID 2, allowing each corresponding ONT 310 to transmit data more frequently within frame 402, thereby reducing the time each ONT 310 must wait before transmitting data associated with its low-latency application.

[0131] Figure 3B This describes an example system 300B for pushing a portion of data upstream in a passive optical network. Example system 300B may include one or more ONTs 310 and one or more OLTs 320 coupled to each other via one or more splitters 330. Figure 3B The various components of the system 300B shown in the figure are similar to Figure 3A System 300A, and includes Figure 3A Any structure and functionality of the 300A system. For example, Figure 3B The network 315 shown in the image is similar to Figure 3A The difference between network 315 and OLT 320 lies only in its function of facilitating the connection between ONT 310 and OLT 320. The components of ONT 310 and OLT 320 may include... Figure 3A Some or all of the structure and functionality of their specific counterparts.

[0132] Instance system 300B may further include one or more servers 355. Server 355 may be referred to herein as a latency server, such as latency server 1005, as in combination. Figures 1A to 1FAs described. In some embodiments, a low-latency controller 360 (or a subset of its functionality) may be integrated into a server 355. The server 355 and / or the low-latency controller 360 may be configured to communicate with an ONT 310, an OLT 320, or other client devices 325 via a network 315.

[0133] Figures 3C to 3E Example systems 300C to 300E are described for dynamic constant bit rate (CBR) bandwidth allocation in passive optical networks (PON). Example systems 300C to 300E may include one or more ONTs 310 and one or more OLTs 320 coupled to each other via one or more splitters 330. Figures 3C to 3E The various components of the systems 300C to 300E shown in the figure are similar to Figure 3A System 300A or Figure 3B The system 300B, and includes any of their structure and functionality. For example, Figures 3C to 3E The server 355 shown in the image is similar to Figure 3B Server 355. Components of ONT 310 and OLT 320 may include Figures 3A to 3B Some or all of the structure and functionality of their specific counterparts.

[0134] like Figure 3C As shown, a client device 325 within a single household can (e.g., via a low-latency agent 335) communicate low-latency application requests to an ONT 310. The ONT 310 can (e.g., via the low-latency agent 335) continuously update these low-latency requests to an OLT 320. The low-latency agent 335 residing within the OLT 320 can provide input to a Dynamic Bandwidth Allocation (DBA) engine 345 to enable or disable CBR bandwidth for a specific ONT 310. CBR is a transmission technology used in telecommunications and networking. CBR maintains a stable data rate throughout the transmission. CBR is useful for applications that require predictable and reliable data delivery (e.g., voice and video). In this example implementation, the server 355 does not directly participate in enabling or disabling CBR.

[0135] exist Figure 3D In this implementation, a client device 325 within a single household can (e.g., via a low-latency agent, a low-latency application, or a CBR application) directly transmit low-latency application requests to the OLT 320. A low-latency agent 335 residing within the OLT 320 can provide input to the dynamic bandwidth allocation engine 345 to enable or disable CBR bandwidth for a specific OLT 310. In this example implementation, the server 355 does not directly participate in enabling or disabling CBR. Figure 3EIn this configuration, client device 325 within a single household can directly communicate low-latency application requests to server 355. Low-latency controller 360 residing within server 355 can provide input to OLT 320. Based on the received input, OLT 320 can enable or disable CBR bandwidth for a specific ONT 310 via dynamic bandwidth allocation engine 345.

[0136] Figure 5 This describes a method 500 for dynamically switching between delay-sensitive and bandwidth-efficient modes in a passive optical network (PON). Method 500 can be implemented using systems 100, 300, or any other features discussed in Figures 1-3. Method 500 may include actions 502 to 516. At 502, the optical line terminal (OLT) can communicate with the optical network terminal (ONT). At 504, the OLT can identify the transport container (TCONT) used for communication with the ONT. At 506, the OLT can allocate bandwidth from upstream bandwidth capacity to each associated TCONT in the bandwidth (BW) mapping. At 508, the OLT can receive an indication of the service type from the associated ONT. At 510, the OLT can determine that the service type is delay-sensitive. At 512, if the OLT determines that the service type is delay-sensitive, then the OLT can allocate a smaller virtual frame at a higher frequency to the corresponding ONT. At point 514, if the OLT determines that the service type is not latency-sensitive, then the OLT can allocate consecutive virtual frames to the corresponding ONT. At point 516, the OLT can communicate the updated BW mapping to the connected ONT.

[0137] At position 502, the OLT can communicate with the ONT. The OLT can communicate with the ONT using standardized protocols, such as GPON (Gigabit Passive Optical Network), which defines the message formats and procedures used for control functions. In some embodiments, the OLT can be physically installed in a central office or data center, and the ONT can be installed at a customer's residence. In some embodiments, the connection between the OLT and the ONT can be established using fiber optic cable, which can use optical pulses to transmit data. For example, the network can use fiber optic cable extending from the OLT to a passive optical splitter, which can split the signal from the OLT to serve multiple ONTs. The ONT can be configured to receive messages and respond.

[0138] At position 504, the OLT can identify the TCONT used for communication with the ONT. The TCONT (also known as a service bearer entity) can be a logical channel within the PON and can also be used as a virtual conduit within a fiber optic connection. When an ONT wants to transmit data upstream to the OLT, the ONT can place data packets into the TCONT based on the type of service (e.g., voice data, video data, etc.). During the initialization process, the OLT can assign identifiers (e.g., Alloc_ID) to each connected ONT within the network via the Dynamic Bandwidth Allocation Engine (DBA). The Alloc_ID can be used to distinguish each associated ONT. Each TCONT used to communicate with a specific ONT can be associated with the Alloc_ID assigned to that specific ONT. When managing services and allocating bandwidth via the DBA, the OLT can use this association to identify which TCONT belongs to which ONT. For example, the Alloc_ID assigned to each ONT during initial network setup allows the OLT to determine the number of TCONT instances supported by a given ONT.

[0139] At 506, the OLT can allocate bandwidth from upstream bandwidth capacity to the identified TCONTs in the BW map. Upstream bandwidth capacity is the maximum data transfer rate from the device to the network or the Internet. Upstream bandwidth capacity determines the speed at which data (e.g., video uploads or file transfers) can be sent from an end-user device. The BW map can be a data structure maintained by the OLT. In some embodiments, the BW map can serve as a framework for defining how upstream bandwidth is allocated among TCONTs supported by one or more ONTs within the network. The OLT can use the BW map via the DBA to allocate specific time slots to each TCONT within the ONT based on service requirements or user configuration. A time slot indicates the time period during which each ONT can transmit its data upstream to the OLT via its associated TCONT. In some embodiments, the network can be configured to use Time Division Multiple Access (TDMA) for upstream bandwidth allocation. For example, TDMA can divide time on a single channel, thereby allowing multiple ONTs to access upstream bandwidth.

[0140] At 508, the OLT may receive a service type indication from the associated ONT. The indication refers to a specific signal or measurement that provides information about network performance or connectivity. In this regard, the indication may refer to a signal sent by one device (ONT) to another device (OLT) to transmit specific data about network service or application behavior. In some embodiments, the OLT may receive the service type indication, for example, using a standardized signaling protocol established between the OLT and the ONT. The signaling protocol may allow the ONT to transmit a signal indicating the type of service currently being generated by the ONT (e.g., delay-sensitive or real-time-insensitive). In some embodiments, the OLT may process data packets received from the ONT within a frame. For example, the OLT may process data packets based on factors such as packet size, inter-packet arrival time, or header information to determine the service type. In some embodiments, the OLT may receive service type information directly from an application running on a user equipment connected to the ONT.

[0141] At 510, the OLT can determine whether a service type is latency-sensitive. The OLT can use service type information received from the ONT to determine whether a service is latency-sensitive. For example, if a standardized signaling protocol is used, the OLT can directly interpret the signal received from the ONT to identify it as latency-sensitive. In some embodiments, if service analysis is involved, a constant flow of small packets can indicate real-time voice or video services (latency-sensitive). In some embodiments, a short inter-packet arrival time can indicate real-time services. Some embodiments may include header information indicating the service type.

[0142] At 512, if the OLT determines that the service type is latency-sensitive, the OLT can allocate smaller virtual frames at a higher frequency to the corresponding ONT. The OLT can divide a main frame (e.g., a 1ms frame) into smaller logical units called virtual frames. Each virtual frame can indicate a dedicated time slot within the main frame for data transmission from a specific ONT. When the OLT identifies a latency-sensitive service for an ONT, the OLT can allocate smaller virtual frames at a higher frequency to the specific ONT in the BW mapping via DBA. For example, the OLT can be configured to create short data bursts that will be transmitted more frequently by allocating virtual frames at a higher frequency. In some embodiments, using smaller virtual frames can help reduce latency. For example, smaller frames take less time to transmit compared to larger frames, thereby minimizing latency for latency-sensitive services.

[0143] At point 514, if the OLT determines that the service type is not latency-sensitive, then the OLT can allocate consecutive virtual frames to the corresponding ONT. Real-time-insensitive services may involve bulk data transmission, such as file downloads, where occasional latency is not significant. The OLT can be configured to allocate a single, larger virtual frame to the corresponding ONT in the BW map by aggregating multiple consecutive virtual frames. In this respect, larger virtual frames can be used more efficiently for bulk data transmission. For example, because non-latency services handle large amounts of data, allocating a larger time slot allows more data to be transmitted per frame.

[0144] At point 516, the OLT can communicate the updated BW mapping to the connected ONTs. The OLT can transmit the updated BW mapping to the connected ONTs, allowing the ONTs to be aware of changes in their allocated bandwidth, including the number and size of virtual frames assigned to latency-sensitive and bulk-transmission services. Based on the received information, the connected ONTs can adjust their transmission behavior accordingly, for example, by adapting their packet scheduling or queue management policies. In this way, the connected ONTs can have a consistent view of the current bandwidth allocation scheme.

[0145] Figure 6 This describes a method 600 for pushing partial data upstream in a passive optical network. Method 600 can be implemented using systems 100, 300, or any other features discussed in Figures 1-3. Method 600 may include actions 602 to 616. At 602, the ONT may receive data packets from a connected client device. At 604, the ONT may detect a low-latency application running on the connected client device. At 606, the ONT may assign a lifetime value to the corresponding data packet. At 608, the ONT may record the arrival timestamp of each data packet entering the queue associated with the transmission container. At 610, the ONT may calculate the time stuck in the queue associated with the transmission container for each data packet. At 612, the ONT may determine that the calculated time stuck for each data packet exceeds the lifetime value. At 614, if their calculated time stuck exceeds the corresponding lifetime value, then the ONT may discard the corresponding data packet. At position 616, if their calculated stuck time does not exceed the corresponding live time value, then the OLT can prioritize the transmission of the corresponding data packets.

[0146] At position 602, the ONT can receive data packets from connected client devices. Client devices (e.g., game consoles, PCs, etc.) can transmit data to the ONT via, for example, wired or wireless connections. Wired connections can use Ethernet cables, and wireless connections can use the Wi-Fi protocol. The ONT can convert the data received from the connected client devices into optical signals. The ONT can transmit the optical signals to the OLT via fiber optic cables. The OLT facilitates communication between client devices and external Internet resources. For example, the OLT can route data packets to the Internet backbone. Data from the Internet can be transmitted back to the ONT via the OLT, where the data can be converted from optical signals to electrical signals and transmitted to the client devices.

[0147] At position 604, the ONT can detect low-latency applications running on connected client devices. The ONT can process data packets from connected client devices via a low-latency agent to detect low-latency applications. Packets may contain, but are not limited to, predefined tags, tuple information, and header information, which the ONT can process to detect any low-latency applications running on the client devices. In some embodiments, the low-latency agent within the ONT can communicate with a latency controller running on a server in the network to receive identification of low-latency applications traversing the network. For example, the low-latency controller may convey low-latency 5-tuple information to the ONT.

[0148] At position 606, the ONT can assign a Time-to-Live (TTL) value to the corresponding data packet. The ONT can assign a TTL value to each data packet associated with a low-latency application. The TTL value can represent a duration (e.g., X milliseconds). The TTL value indicates how long a data packet can exist on the network, computer, or server before being discarded.

[0149] At 608, the ONT may record the arrival timestamp of each data packet entering the queue associated with the transmission container. The queue may be a buffer or a storage device for a list of data items in a data structure (e.g., an ordered list of data items including packets). The queue may be used as a buffer to hold data packets before they are transmitted. The ONT may use the packet timestamp for each data packet stored in the queue associated with the transmission container to determine the arrival timestamp of the corresponding data packet. The arrival timestamp indicates when each data packet arrived at the ONT. In some embodiments, the ONT may use the current system time to obtain the current timestamp as a reference point. The current timestamp may be obtained from a network synchronization source, an internal clock within the ONT, or another device interacting with the ONT.

[0150] At position 610, the ONT can calculate the time each data packet has been stuck in the queue associated with the transport container. The ONT can be configured to determine the stuck time for each data packet by subtracting the arrival timestamp from the current timestamp. In this way, the ONT can determine how long each data packet has been waiting in the associated queue. The ONT can compare the calculated stuck time value of each packet with its corresponding TTL value. For example, the ONT can be configured to assess how long a packet has been in the network relative to its corresponding TTL value.

[0151] At point 612, the ONT can determine that the calculated time-to-live (TTL) for each data packet exceeds the time-to-live value. For example, to avoid latency and routing issues, the ONT can determine whether the corresponding data packet has experienced delay within the network. At point 614, if the calculated time-to-live for a corresponding data packet exceeds the corresponding TTL value, the ONT can discard the corresponding data packet. At point 616, if the calculated time-to-live for a corresponding data packet does not exceed the corresponding TTL value, the OLT can prioritize the transmission of the corresponding data packet.

[0152] In some embodiments, method 600 may include actions 618 to 624. At 618, the ONT may determine that a data packet matches low-latency tuple information. At 620, if the data packet matches the low-latency tuple information, the ONT may route the data packet to a low-latency queue associated with the transport container. At 622, if the data packet does not match the low-latency tuple information, the ONT may route the data packet to a separate queue for normal data services. At 624, the OLT may prioritize the transmission of the corresponding data packets that match the low-latency information.

[0153] At position 618, the ONT determines whether a data packet matches low-latency tuple information. The ONT can be configured, via a low-latency agent or low-latency controller, to process the headers of packets traversing the network to determine the 5-tuple information. The 5-tuple information may include source and destination IP addresses, source and destination ports, and the protocol. By processing the fields within the header, the ONT can be configured to detect low-latency applications.

[0154] At 620, if a data packet matches low-latency tuple information, the ONT can route the data packet to a low-latency queue associated with the transport container. A queue can be a row of data packets waiting to be processed. A queue can be a buffer or a storage device for a list of data items in a data structure (e.g., an ordered list of data items including packets). Each queue can be configured with different priorities based on the needs of the data packets managed by the corresponding queue. Routing to a low-latency queue can be triggered in response to the detection of a low-latency application. Low-latency queues can be prioritized so that data packets within a low-latency queue are served before other data packets in different queues.

[0155] At point 622, if a data packet does not match the low-latency tuple information, the ONT can route the data packet to a separate queue for normal data traffic. The standard queue associated with the transport container can be configured to manage less time-sensitive data (e.g., packets from website browsing or email services), allowing the network to manage traffic by separating urgent communications (e.g., video streaming, voice calls, online gaming, etc.) from more regular data transmission.

[0156] At position 624, the OLT can prioritize the transmission of corresponding data packets that match low-latency information. During the DBA process, the ONT can communicate the presence of low-latency services in its queues (e.g., low-latency queues) to the OLT. In some embodiments, the ONT can be configured to request transmission opportunities once a threshold is met in the low-latency queue. The ONT can allocate resources for normal services, and if necessary, data services from low-latency queues can be processed in smaller transactions in upstream data. In some embodiments, the ONT can be configured to request transmission opportunities even if the low-latency queue holds only a single byte of data. The OLT can detect the presence of low-latency services via a low-latency controller on a server or a low-latency agent residing within the OLT. Based on the received information about low-latency services, the OLT can update the BW mapping via the DBA engine to prioritize the transmission of data packets stored in the low-latency queue. For example, the OLT can allocate more bandwidth or grant more frequent transmission opportunities to data packets associated with the low-latency queue.

[0157] In some embodiments, method 600 may include actions 626 to 630. At 626, the ONT may determine that the TCP URG / PUSH flag in the received data packet is active. At 628, if the ONT identifies that the TCP URG / PUSH flag in the data packet is active, then the ONT may prioritize the transmission of the corresponding data packet. At 630, if the ONT identifies that the TCP URG / PUSH flag in the data packet is inactive, then the ONT may route the data packet to a separate queue for normal data services.

[0158] At position 626, the ONT can determine if the TCP URG / PUSH flag in a received data packet is active. A flag is a single bit within the header of a TCP segment (data packet) that is used in communication. The ONT processes the TCP header to identify the TCP URG / PUSH flag. For example, the ONT can check the value of the flag bit. If the flag is set to "1", this indicates the presence of the corresponding flag. If the flag is set to "0", this indicates that the corresponding flag is not active. The presence of the TCP PUSH flag signals that the sender of the data packet (e.g., a voice call application) is requesting the ONT (or another receiver) to immediately transmit the data contained within the segment to a higher layer (e.g., the application layer) without waiting for the buffer to fully fill. In some embodiments, the TCP URG flag can indicate the presence of urgent data within a TCP segment. The TCP URG flag can be used to bypass queues in the data pipeline.

[0159] At point 628, if the ONT detects that the TCP URG / PUSH flag in a data packet is active, the ONT can prioritize the transmission of the corresponding data packet. For example, the ONT can place the corresponding data packet in a low-latency queue. In some embodiments, the ONT can bypass queues in the data pipeline to accelerate transmission. In some embodiments, the ONT can request the OLT to allocate additional bandwidth or grant more frequent transmission opportunities for the corresponding data packet.

[0160] At point 630, if the ONT detects that the TCP URG / PUSH flag in a data packet is inactive, the ONT can route the data packet to a separate queue for normal data traffic. These standard queues can be configured for normal data traffic. The ONT maintains the efficiency of normal data traffic by preventing corresponding data packets from being continuously overtaken by prioritized low-latency data packets.

[0161] Figure 7 A method 700 for dynamic constant bit rate bandwidth allocation in a passive optical network is described. Method 700 can be implemented using systems 100, 300, or any other features discussed in Figures 1 to 3. Method 700 may include actions 702 to 710. At 702, a passive optical network is established. At 704, the ONT receives low-latency application state updates from connected client devices. At 706, the ONT determines the current low-latency application state of each client device. At 708, the ONT periodically updates the OLT using the current low-latency application state of the corresponding client device. At 710, the OLT adjusts the CBR bandwidth allocation for the associated ONT.

[0162] At point 702, a passive optical network can be established. For example, the configuration may include the installation of devices such as ONTs and OLTs. The ONT can be connected to the OLT via fiber optic cable, which facilitates high-speed data transmission and efficient signal distribution across the network. Depending on the implementation, the ONT can be connected to client devices via coaxial cable or Ethernet. In some embodiments, each ONT within the network may be configured with an integrated Wi-Fi access point to facilitate wireless connectivity with client devices.

[0163] At 704, the ONT can receive low-latency application status updates from connected client devices. Status can refer to the current state or condition of a network component, application, or service. Status can provide information about the operational status, performance, or availability of a specific entity within the network. The client device's operating system can be configured to include flags or tags within data packets generated by the low-latency application. In some embodiments, the client device's operating system may transmit control messages (e.g., via API calls or related protocols) to the ONT at regular time intervals or upon detecting a low-latency application. In some embodiments, a low-latency agent or latency controller can be deployed within the network to monitor the status of various low-latency applications or CBR applications on the ONT and report the status to the ONT. In some embodiments, the ONT can receive indications of the application's status from the CBR application, for example, via a low-latency agent. In the context of telecommunications and networking, a CBR application can refer to a data source that generates a continuous, stable stream of data. In some embodiments, an external low-latency controller residing on another device or server within the network can be used to report the status of the CBR application to the ONT.

[0164] At 706, the ONT can determine the current low-latency application state of each client device. The ONT can be configured to maintain a state table to track the current low-latency application state of each connected client device. The state table may contain fields, such as a device identifier identifying each device and the low-latency application state of each connected client device. The state field may have two states: on or off. When the ONT detects an active low-latency application associated with a client device, the state field may be set to on. When the ONT determines that the low-latency application is inactive or not currently generating data, the state field may be set to off. In some embodiments, the state field may contain a flag (e.g., enabled / disabled). For example, when the ONT detects a low-latency application associated with a client device, the state field may be set to enabled. When the ONT detects that the low-latency application is inactive or that the low-latency application is active but not generating data during the specific time period, the state field may be set to disabled. In some embodiments, the ONT may further use information from Layer 2 (L2) flags within data packets. L2 flags can provide granular details about the data, such as indicating the end of a video or audio frame. By incorporating L2 flag information into the status table, the ONT can be configured to achieve finer-grained prioritization within low-latency allocations. The ONT can continuously monitor data packets and dynamically update the status table, for example, switching between enabled and disabled states based on data activity.

[0165] At 708, the ONT can periodically update the OLT using the current low-latency application state of the corresponding client device. For example, the ONT can periodically transmit messages to the OLT containing information about the current low-latency application state of its connected client devices. In some embodiments, the ONT can be configured to provide these state updates every 1 to 3 seconds. For example, when a user starts a video conferencing application, the ONT can activate a low-latency (or CBR) pipeline or queue for the session to allow the OLT to prioritize low-latency applications.

[0166] At 710, the OLT can adjust the CBR bandwidth allocation for the associated ONT. For example, the OLT can dynamically adjust the CBR bandwidth allocation for the associated ONT in response to receiving an update from the ONT indicating an active low-latency application. For example, the OLT can adjust the CBR bandwidth allocation for the ONT in real time based on changing network conditions or application requirements. In some embodiments, if the OLT determines that the low-latency application or CBR application is open, the OLT can increase the CBR bandwidth allocation for the corresponding ONT in the BW mapping via DBA. Increasing the CBR bandwidth allocation can refer to the process of expanding the amount of network capacity dedicated to CBR services. For example, increasing the CBR bandwidth allocation may include adjusting the bandwidth mapping to provide more resources for applications with strict QoS requirements. The OLT can increase the CBR bandwidth allocation for the corresponding ONT in the bandwidth BW mapping via DBA. In some embodiments, the DBA can divide the original one-millisecond frame length into smaller virtual frames. The duration of the virtual frame can be set based on the latency requirements of the ONT for a specific Alloc_ID request. The OLT can be configured to allow frequent allocation of time-sensitive CBR services. In some embodiments, the OLT can switch the allocation scheme for a specific Alloc_ID to a latency-optimized mode, which can reduce latency between allocations. In some embodiments, the OLT can manage other Alloc_IDs (e.g., non-CBR services that do not exhibit the constant bit rate characteristics of CBR services) for bandwidth efficiency by combining virtual time slots used for other service types into a single or larger contiguous allocation.

[0167] In some embodiments, if the OLT determines that a low-latency application or CBR application is inactive (e.g., not active), the OLT may reduce the CBR bandwidth allocation for the corresponding ONT in the BW mapping via DBA. Reducing CBR bandwidth allocation can refer to the process of reducing the amount of network capacity dedicated to CBR services. By reducing the allocation, the OLT can reclaim bandwidth previously reserved for inactive low-latency applications. This configuration can free up bandwidth resources within the network. In some embodiments, the OLT may allocate the freed bandwidth to other service types, such as non-real-time data transmission, based on network demand. In some embodiments, the freed bandwidth can be used to increase bandwidth allocation for other ONTs with active service demands. In some embodiments, the OLT may dynamically monitor network service and application status, such as CBR applications. Based on predefined rules, Quality of Service (QoS) settings, and real-time demands, the OLT may automatically adjust the bandwidth allocation in the BW mapping. In some embodiments, the ONT may request additional bandwidth, which may be triggered when pre-allocated bandwidth limits are exceeded or when unexpected service surges occur. The OLT can process requests via the DBA based on available resources in the BW mapping and update the BW mapping to indicate the increase or decrease of allocation for the connected ONT.

[0168] In some embodiments, method 700 may include actions 712 to 716. At 712, the OLT may receive low-latency application status updates from the connected client devices. At 714, the OLT may determine the current low-latency application status of each client device. At 716, the OLT may adjust the CBR bandwidth allocation for the associated ONT.

[0169] At 712, the OLT can receive low-latency application status updates from connected client devices. For example, a client device can directly communicate an associated low-latency application request to the OLT. The OLT may include a low-latency agent, which can be configured to handle communications from client devices regarding low-latency applications. In some embodiments, the client device can communicate with the OLT via a network configured to facilitate direct communication between the client device and the OLT. In some embodiments, the OLT can receive indications of the status of a CBR application from the CBR application. In some embodiments, the OLT can receive indications of the status of a CBR application from other sources including client devices. In some embodiments, the OLT can receive indications of the status of a CBR application from a low-latency controller on another device. In some embodiments, the OLT can receive indications of the status of a CBR application from a low-latency agent. In some embodiments, the client device can communicate with a low-latency controller residing on a server. The low-latency controller can facilitate direct communication between the client device and the OLT over a network.

[0170] At 714, the OLT can determine the current low-latency application status for each client device. The OLT can be configured with a low-latency agent or low-latency controller to process data packets and identify whether the low-latency application associated with the client device is enabled or disabled. An enabled status indicates that a low-latency application is currently running on the client device. A disabled status indicates that no low-latency application is currently running on the client device, or that any previously running applications have been deactivated.

[0171] At 716, the OLT can adjust the CBR bandwidth allocation for associated ONTs. For example, the OLT can dynamically adjust the CBR bandwidth allocation for associated ONTs in response to indications of active low-latency applications. The OLT can increase or decrease the CBR allocation for associated ONTs via DBA to effectively manage network traffic, as described above. In some embodiments, the OLT can be configured to incorporate data structures, such as tables or database entries, to track the total amount of CBR bandwidth currently allocated to each ONT. In some embodiments, the OLT can be configured to use data structures to map Alloc_IDs to specific low-latency applications associated with the allocated bandwidth. When adjustments are made, the OLT can use the mapping to identify which applications benefit from the increased bandwidth. In some embodiments, the OLT can communicate directly with applications (via the ONT) to notify them of bandwidth requests beyond the home network. This communication can be implemented via standardized signaling, such as messages defined within data packets indicating bandwidth limitations. Applications or client devices can use these messages as notifications to modify their data transmission behavior based on available network bandwidth.

[0172] In some embodiments, method 700 may include actions 718 to 724. At 718, the server may receive low-latency application state updates from connected client devices. At 720, the server may determine the current low-latency application state of each client device. At 722, the server may periodically update the OLT using the current low-latency application state of the corresponding client device. At 724, the OLT may adjust the CBR bandwidth allocation for the associated ONT.

[0173] At point 718, the server can receive low-latency application status updates from connected client devices. For example, the client device can directly communicate associated low-latency application requests to the server. In some embodiments, the client device can communicate with the server via a network that facilitates direct communication between the client device and the server. In some embodiments, the client device can communicate with a low-latency controller residing on the server, which can be configured to handle communication from the client device regarding low-latency applications. The low-latency controller can facilitate direct communication between the client device and the server over the network.

[0174] At point 720, the server can determine the current low-latency application state for each client device. The server may include a low-latency controller to process data packets and identify whether the low-latency application associated with the client device is enabled or disabled. An enabled state indicates that a low-latency application is currently running on the client device. A disabled state indicates that no low-latency application is currently running on the client device, or that any previously running applications have been deactivated.

[0175] At point 722, the server can periodically update the OLT using the current low-latency application state of the corresponding client device. For example, the server can periodically transmit messages to the OLT via the low-latency controller, the messages containing information about the current low-latency application state of the corresponding client device. In some embodiments, the server can be configured to provide these state updates every 1 to 3 seconds. For example, when a user starts a video conferencing application, the server can interact with the OLT to prioritize low-latency applications.

[0176] At point 724, the OLT can adjust the CBR bandwidth allocation for the associated ONT. For example, the OLT can dynamically adjust the CBR bandwidth allocation for a specific ONT associated with a corresponding client device in response to receiving an update from the server indicating an active low-latency application. The OLT can increase or decrease the CBR allocation for a specific ONT via the DBA to effectively manage network traffic, as described above.

[0177] It should be noted that certain paragraphs of this disclosure may use terms such as “first” and “second” in connection with apparatus, mode of operation, transmission chain, etc., for the purpose of identifying or distinguishing one from another or one from others. These terms are not intended to relate entities (e.g., first apparatus and second apparatus) merely in time or in sequence, but in some cases, these entities may contain this relationship. These terms also do not limit the number of possible entities (e.g., apparatuses) that can operate within a system or environment. The term coupling or connection (which may refer to electronic or communication coupling or connection, e.g., for data transmission purposes) includes both indirect and direct coupling and connection.

[0178] While this disclosure has been described with respect to specific embodiments, those skilled in the art will recognize that many modifications are possible. For example, although specific examples of rules (including triggering conditions and / or result actions) and processes for generating recommended rules are described, other rules and processes may be implemented. Embodiments of this disclosure may be implemented using various computer systems and communication technologies, including, but not limited to, the specific examples described herein.

[0179] Embodiments of this disclosure may be implemented using any combination of components and / or programmable processors and / or other programmable devices. The various processes described herein may be implemented on the same or different processors in any combination. Where a component is described as being configured to perform certain operations, this configuration may be implemented, for example, by designing electronic circuitry to perform the operations, by programming programmable electronic circuitry (e.g., a microprocessor) to perform the operations, or any combination thereof. Furthermore, while the embodiments described above may refer to specific hardware and software components, those skilled in the art will understand that different combinations of hardware and / or software components may also be used, and specific operations described as being implemented in hardware may also be implemented in software, or vice versa.

[0180] Computer programs incorporating the various features of this disclosure may be encoded and stored on a variety of computer-readable storage media; suitable media include magnetic disks or magnetic tapes, optical storage media (e.g., optical discs (CDs) or DVDs (Digital Multifunction Disk)), flash memory, and other non-transitory media. Computer-readable media encoding program code may be packaged together with a compatible electronic device, or the program code may be provided separately from the electronic device (e.g., via Internet download or as a separately packaged computer-readable storage media).

[0181] Therefore, although this disclosure has been described with respect to specific embodiments, it will be understood that this disclosure is intended to cover all modifications and equivalents within the scope of the following claims.

[0182] It should be understood that the disclosed embodiments do not represent all claimed innovations. Therefore, certain aspects of this disclosure have not been discussed herein. For specific parts of an innovation, alternative embodiments may not have been proposed, or for a portion, other undescribed alternative embodiments may be available; this should not be construed as abandoning those alternative embodiments. Therefore, it should be understood that other embodiments may be utilized, and functional, logical, operational, organizational, structural, and / or topological modifications may be made without departing from the scope of this disclosure. Thus, throughout this disclosure, all instances and / or embodiments are considered non-limiting.

[0183] Some embodiments described herein relate to methods. It should be understood that such methods can be implemented by a computer (e.g., instructions stored in memory and executed on a processor). Where the methods described above indicate that specific events occur in a particular order, the ordering of those events can be modified. Furthermore, certain events can be performed repeatedly, simultaneously in parallel processes where possible, and sequentially as described above. Additionally, in some embodiments, one or more of the described events may be omitted.

[0184] Some embodiments described herein relate to a computer storage product having a non-transitory computer-readable medium (also referred to as a non-transitory processor-readable medium) having instructions or computer code on which to perform various computer-implemented operations. A computer-readable medium (or processor-readable medium) is non-transitory in the sense that it does not itself contain transient propagation signals (e.g., propagating electromagnetic waves carrying information on a transmission medium such as space or cable). The medium and computer code (also referred to as code) may be code designed and constructed for one or more specific purposes. Examples of non-transitory computer-readable media include, but are not limited to, magnetic storage media such as hard disks, floppy disks, and magnetic tapes; optical storage media such as optical discs / digital video discs (CDs / DVDs), optical disc read-only memories (CD-ROMs), and holographic devices; magneto-optical storage media such as optical discs; carrier signal processing modules; and hardware devices specifically configured to store and execute program code, such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs), read-only memories (ROMs), and random access memories (RAMs). Other embodiments described herein relate to a computer program product that may include, for example, the instructions and / or computer code discussed herein.

[0185] Some of the embodiments and / or methods described herein can be implemented by software (executing on hardware), hardware, or a combination thereof. Hardware modules may include, for example, general-purpose processors, field-programmable gate arrays (FPGAs), and / or application-specific integrated circuits (ASICs). Software modules (executing on hardware) can be expressed in various software languages ​​(e.g., computer code), including C, C++, Java, etc. TM Ruby, Visual Basic TMAnd / or other object-oriented, procedural, or other programming languages ​​and development tools. Instances of computer code include, but are not limited to, microcode or microinstructions, machine instructions (e.g., generated by a compiler), code for generating web page services, and files containing higher-level instructions that a computer executes using an interpreter. For example, embodiments may be implemented using Python, Java, JavaScript, C++, and / or other programming languages ​​and software development tools. For example, embodiments may be implemented using imperative programming languages ​​(e.g., C, Fortran, etc.), functional programming languages ​​(Haskell, Erlang, etc.), logic programming languages ​​(e.g., Prolog), object-oriented programming languages ​​(e.g., Java, C++, etc.) or other suitable programming languages ​​and / or development tools. Additional instances of computer code include, but are not limited to, control signals, encryption code, and compression code.

[0186] The accompanying drawings are primarily for illustrative purposes and are not intended to limit the scope of the subjects described herein. The drawings are not necessarily drawn to scale; in some instances, various aspects of the subjects disclosed herein may be exaggerated or enlarged in the drawings to facilitate understanding of different features. In the drawings, the same element symbols generally refer to the same features (e.g., functionally similar and / or structurally similar elements).

[0187] Actions performed as part of the disclosed method can be ordered in any suitable manner. Therefore, embodiments in which processes or steps are performed in a different order than described can be constructed, which may include the simultaneous execution of some steps or processes, even if shown as sequential actions in the illustrative embodiments. In other words, it should be understood that such features are not necessarily limited to a particular execution order, but can be performed serially, asynchronously, concurrently, in parallel, simultaneously, synchronously, and / or similarly, in a manner consistent with this disclosure. Therefore, some of these features may be contradictory, as they cannot coexist in a single embodiment. Similarly, some features may apply to one aspect of the innovation but not to others.

[0188] Where a range of values ​​is provided, it should be understood that, unless the context explicitly specifies otherwise, every intermediate value (to one-tenth of the lower limit unit) between the upper and lower limits of the range, as well as any other stated or intermediate values ​​within the stated range, is included in this disclosure. The upper and lower limits of these smaller ranges may be independently included in the smaller range and also covered in this disclosure, but are subject to any specifically excluded limits within the stated range. Where a stated range contains one or two limits, the range excluding any or both of those included limits is also included in this disclosure.

[0189] As used herein in the specification and embodiments, the phrase “and / or” should be understood to mean “any one or both” of the elements so combined, that is, elements that exist together in some cases and separately in others. Multiple elements listed with “and / or” should be interpreted in the same way, that is, “one or more” of the elements so combined. In addition to the elements specifically identified by the “and / or” clause, other elements may optionally be present, whether related to or unrelated to those specifically identified. Thus, as a non-limiting example, when used in conjunction with open-ended language such as “including,” a reference to “A and / or B” may in one embodiment refer only to A (optionally including elements other than B); in another embodiment, only to B (optionally including elements other than A); in yet another embodiment, to both A and B (optionally including other elements); and so on.

[0190] As used herein in the specification and embodiments, “or” should be understood to have the same meaning as “and / or” as defined above. For example, when separating items in a list, “or” or “and / or” should be interpreted as inclusive, that is, including multiple elements or at least one of the elements in the list, but also including more than one, and optionally, additional unlisted items. Only terms that explicitly indicate the opposite, such as “only one” or “exact one”, or when used in embodiments, “consisting of…” will refer to including multiple elements or exactly one of the elements in the list. In general, the term “or” as used herein should only be interpreted as indicating an exclusive alternative (i.e., “one or the other but not both”) when preceded by an exclusive term, such as “either one,” “one of them,” “only one of them,” or “exact one of them.” When used in embodiments, “consisting substantially of…” should have its ordinary meaning as used in the field of patent law.

[0191] As used herein in the specification and embodiments, the phrase "at least one" in relation to a list of one or more elements should be understood to mean at least one element selected from any one or more elements in the list of elements, but does not necessarily include at least one of every element specifically listed in the list of elements, and does not exclude any combination of elements in the list of elements. This definition also allows for the optional presence of elements related to or unrelated to those specifically identified elements in the list of elements referred to by the phrase "at least one". Therefore, as a non-limiting example, "at least one of A and B" (or equivalently, "at least one of A or B", or equivalently, "at least one of A and / or B") in one embodiment may refer to at least one, optionally including more than one A, with no B (and optionally including elements other than B); in another embodiment, may refer to at least one, optionally including more than one B, with no A (and optionally including elements other than A); in yet another embodiment, may refer to at least one (optionally including more than one) A and at least one (optionally including more than one) B (and optionally including other elements); and so on.

[0192] In the embodiments and in the above description, all transitional phrases such as “comprising,” “including,” “carrying,” “having,” “containing,” “involving,” “holding,” “consisting of,” and the like should be understood as open-ended, meaning including but not limited to. Only the transitional phrases “consisting of” and “substantially consisting of” should be closed or semi-closed transitional phrases, respectively, as described in Section 2111.03 of the U.S. Patent Examination Procedure Manual.

Claims

1. A system comprising: An optical line terminal (OLT) of a passive optical network (PON) communicates with one or more optical network terminals (ONTs). A dynamic bandwidth allocation (DBA) engine is configured to allocate constant bit rate CBR bandwidth from the upstream bandwidth capacity of the PON to one or more transport containers in response to their registration. Each of the one or more transport containers will be used by the associated ONT for one or more CBR applications. The OLT is configured to receive indications of the status of the CBR application in one or more CBR applications; In response to the instruction, the DBA engine is configured to modify the CBR bandwidth usage of the one or more ONTs in the bandwidth mapping (BW mapping); and The OLT communicates the bandwidth mapping to one or more ONTs.

2. The system of claim 1, wherein the state is at least one of being open or closed.

3. The system of claim 2, wherein the DBA engine is further configured to modify the bandwidth mapping to increase the CBR bandwidth allocation for the one or more ONTs in response to the state of the CBR application being open.

4. The system of claim 2, wherein the DBA engine is further configured to modify the bandwidth mapping to reduce the CBR bandwidth allocation of the one or more ONTs in response to the state of the CBR application being off.

5. The system of claim 1, wherein the OLT is further configured to receive an indication of the status of the CBR application from at least one of the one or more ONTs.

6. The system of claim 5, wherein at least one of the one or more ONTs is further configured to receive the indication of the state of the CBR application from a low-latency agent or a latency controller.

7. The system of claim 1, wherein the OLT is further configured with a low-latency agent for receiving indications of the status of the CBR applications from the one or more CBR applications.

8. The system of claim 1, wherein the OLT is further configured to receive an indication of the state of the CBR application from a low-latency controller on another device.

9. A method comprising: The Dynamic Bandwidth Allocation (DBA) engine identifies one or more transmission containers used by the Optical Line Terminal (OLT) of the Passive Optical Network (PON), which communicate with one or more Optical Network Terminals (ONTs). In response to the registration of the one or more transport containers, the DBA engine allocates constant bit rate CBR bandwidth from the upstream bandwidth capacity of the PON to the one or more transport containers, each of the one or more transport containers will be used by the associated ONT for one or more CBR applications. The OLT receives an indication of the status of the CBR application in one or more CBR applications; In response to the instruction, the DBA engine modifies the CBR bandwidth usage of the one or more ONTs in the bandwidth mapping (BW mapping); and The bandwidth mapping is communicated by the OLT to one or more ONTs.

10. The method of claim 9, wherein the state is either open or closed.

11. The method of claim 10, further comprising, in response to the state of the CBR application being open, modifying the bandwidth mapping by the DBA engine to increase the CBR bandwidth allocation for the one or more ONTs.

12. The method of claim 10, further comprising, in response to the state of the CBR application being off, the DBA engine modifying the bandwidth to reduce the CBR bandwidth allocation for the one or more ONTs.

13. The method of claim 9, further comprising the OLT receiving the indication of the status of the CBR application from at least one of the one or more ONTs.

14. The method of claim 13, further comprising receiving, by the OLT, the indication of the state of the CBR application from a low-latency agent or a latency controller.

15. The method of claim 9, further comprising receiving, by the OLT, the indication of the status of the CBR application from the one or more CBR applications.

16. The method of claim 9, further comprising receiving, by the OLT, the indication of the state of the CBR application from a low-latency controller on another device.

17. An apparatus comprising: One or more processors coupled to memory and configured with: Dynamic bandwidth allocation (DBA) engine is used to identify one or more transmission containers used by the optical line terminal (OLT) of a passive optical network (PON) that communicate with one or more optical network terminals (ONTs). The DBA engine is configured to allocate constant bit rate CBR bandwidth from the upstream bandwidth capacity of the PON to one or more transport containers in response, each of which will be used by the associated ONT for one or more CBR applications. The device is configured to receive an indication that the status of the CBR application in one or more CBR applications is open or closed; In response to the instruction, the DBA engine is configured to modify the CBR bandwidth usage of the one or more ONTs in the bandwidth mapping (BW mapping); and The device thereunder transmits the bandwidth mapping to the one or more ONTs.

18. The apparatus of claim 17, wherein the apparatus is further configured to receive the instruction from one of the one or more ONTs.

19. The apparatus of claim 17, wherein the apparatus is further configured to receive the instruction from the second apparatus.

20. The apparatus of claim 17, wherein the apparatus is further configured to receive the instruction from the CBR application.

Images