Method and system for interconnecting time-sensitive network nodes using passive optical network components and links

Abstract

The present patent describes methods and systems for the efficient integration and management of time-sensitive networking (TSN) networks using passive optical network (PON) components. The main focus is the creation of a harmonized interconnection between TSN networks and PON systems, optimizing the performance of time-sensitive communications. The proposed method includes the abstraction of PON links so that they function as TSN bridges, implementing advanced time synchronization and traffic scheduling systems, in accordance with standards IEEE 802.1AS (gPTP) and IEEE 802.1Qbv. The interconnection system is characterized by integrated time synchronization means, suitable processing units and network elements configured to manage quality of service (QoS). In addition, the method includes the dynamic configuration of TSN flow sessions, using a centralized network controller (CNC) for optimized management of TSN traffic and QoS in PON networks. The invention further introduces a new specific management framework for PON networks in TSN environments, ensuring efficiency and compatibility in data transmission. The invention represents a significant advance in the interoperability and performance of TSN and PON networks, offering a robust solution for time-sensitive data communications in a variety of application contexts.

Description

[0001] METHOD AND SYSTEM FOR INTERCONNECTING TIME-SENSITIVE NETWORK NODES USING PASSIVE OPTICAL NETWORK COMPONENTS AND LINKS

[0002] FIELD OF INVENTION

[0003]

[0001] This invention relates to the domain of time-sensitive networks (TSN), specifically to the use of passive optical network (PON) components and links in the ITU-T PON standard to interconnect TSN nodes in order to guarantee time synchronization, scheduling and shaping of the TSN traffic flow and allow the application of specific filters and policies, the use of prioritization and preemption for lower priority traffic and the configuration and management of end-to-end links for TSN traffic. The invention proposes a method and system that allow abstracting a PON network as a TSN bridge, with time synchronization and scheduling guarantees, and that can be used in a TSN network in conjunction with traditional TSN elements, based on already supported standards such as Ethernet networks, Wi-Fi and 5G systems (5GS).

[0004] BASICS OF THE INVENTION AND STATE OF THE TECHNIQUE

[0005]

[0002] The present invention proposes a method for interconnecting time-sensitive network (TSN) nodes through passive optical networks (PON) of the ITU-T PON standard, that is, acting as an IEEE TSN bridge in IEEE TSN systems. To this end, systems and methods will be explored so that such ITU-T PON networks meet the requirements of an IEEE TSN bridge determined by the standardization imposed by the IEEE standards set. Such requirements consist mainly of time synchronization, traffic shaping and scheduling, filtering and policing, and configuration and management. Aspects such as reliability and redundancy and traffic preemption are not explored by the solution proposed in this patent.Considering that the requirements for IEEE TSN bridges are adapted from those for MAC bridges, and that ITU-T PON networks can be implemented as MAC bridges, it is concluded that the present invention is feasible through proposals for new adaptations of existing protocols aiming for the PON network to meet the requirements of an IEEE TSN bridge.

[0003] The current state of the art addresses the use of time-sensitive networks, which are a set of standards that enable deterministic and low-latency data transmission over Ethernet networks.

[0001] The main application of TSN networks is to support industrial automation, where real-time communication and synchronization are essential for the operation and safety of machines and processes. TSN networks can also be applied to other domains, such as automotive, aerospace, healthcare, smart grid, and audio / video streaming, where critical traffic is required.

[0006] ARCHITECTURE OF A TSN NETWORK

[0007]

[0004] The main components of a TSN network are:

[0008] • TSN nodes: devices that participate in the TSN network, such as switches, gateways, controllers, sensors, actuators, etc. TSN nodes must support TSN standards and mechanisms to ensure synchronization, scheduling, reliability and management of traffic flows in the network;

[0009] • TSN flows: Logical connections between TSN nodes that carry time-sensitive data. TSN flows have predefined parameters and requirements, such as bandwidth, latency, priority, redundancy, etc. TSN flows must be reserved and configured in the network using the Stream Reservation Protocol (SRP) and the YANG data model.

[0010] • TSN Domains: Subsets of the TSN network that share the same time reference and clock source. TSN domains are established using the Generalized Precision Time Protocol (gPTP), which enables time synchronization and alignment of TSN nodes and flows. TSN domains can have different time scales and precisions, depending on application needs.

[0011]

[0005] There are different types of TSN nodes depending on their functions and roles in the TSN network. The main types of TSN nodes are:

[0012] • TSN end nodes: devices that generate or consume time-sensitive data, such as sensors, actuators, controllers, etc. TSN end nodes must support time synchronization and traffic shaping mechanisms to ensure data flow alignment and prioritization. TSN end nodes can also support reservation and flow configuration mechanisms to negotiate data flow parameters and requirements with the TSN network;

[0013] • TSN bridges: devices that connect two or more TSN network segments and forward traffic according to TSN standards. TSN bridges must support time synchronization, traffic shaping, reliability, filtering, preemption, and configuration mechanisms to ensure deterministic, low-latency delivery of data flows. TSN bridges can also support reservation and flow management mechanisms to allocate and monitor resources for data flows in the TSN network;

[0014] • TSN Gateways: devices that connect the TSN network to other networks that do not support TSN standards, such as legacy Ethernet networks, wireless networks, etc. TSN gateways must support the conversion and adaptation of data flows between the TSN network and other networks, such as encapsulation, decapsulation, compression, decompression, etc. TSN gateways can also support reservation and flow configuration mechanisms to coordinate the parameters and requirements of data flows with the TSN network and other networks;

[0015] • TSN Controllers: Devices that provide centralized control and management functions for the TSN network, such as topology discovery, path calculation, resource allocation, policy enforcement, fault detection, etc. TSN controllers must support communication and coordination with TSN nodes and gateways using reservation and flow configuration protocols such as SRP, YANG, NETCONF, etc. TSN controllers can also support the software-defined networking (SDN) paradigm to enable flexible and dynamic network configuration and optimization;

[0016]

[0006] After presenting the main components of TSN networks, the centralized configuration of a TSN flow occurs in the following steps: a terminal (Talker) (e.g., a virtual PLC) communicates to the centralized user configuration controller (CUC) that it wants to establish communication for transmitting TSN flows to another end terminal (Listener) (e.g., sensors and actuators). Therefore, the CUC negotiates with the centralized network configuration controller (CNC) to determine the resource allocation. Subsequently, the CNC verifies the topology necessary to meet the resource allocation and sends this information to the TSN bridges, which are responsible for providing the connection between the terminals. Once the connection is successful, the CNC notifies the CUC that the allocation was successful, which communicates to the Talker that the TSN flow was successfully allocated.

[0017] IMPLEMENTATIONS OF STANDARDS FOR IEEE TSN NETWORKS

[0018]

[0007] Originally, the IEEE TSN suite of standards enabled deterministic, low-latency data transmission over Ethernet networks. Ethernet is a networking technology that operates at the data link layer (layer 2 of the OSI model), responsible for delivering frames between nodes on the same network segment. Ethernet uses MAC addresses to identify and address nodes and employs various protocols and mechanisms to regulate data flow, handle transmission errors, and provide a clear interface to the network layer (layer 3 of the OSI model) above. Ethernet is the most widely used networking technology for TSN because it supports several features and enhancements that enable time synchronization, traffic shaping, reliability, filtering, preemption, and configuration of data flows within the network.

[0019]

[0008] However, Ethernet is not the only networking technology that can support TSN. Other networking technologies that operate at the data link layer, such as Wi-Fi and 5G, can also implement the TSN standards and mechanisms to enable time-sensitive networking over wireless media. [2] Wi-Fi is a wireless networking technology that uses radio waves to provide wireless access to devices within a local area network (LAN). Wi-Fi uses the IEEE 802.11 standard, which defines the physical layer (layer 1 of the OSI model) and the data link layer of the wireless network. Wi-Fi can support TSN standards by implementing TSN features in the MAC sublayer of the data link layer, such as time synchronization, traffic shaping, reliability, filtering, preemption, and configuration [3]. Wi-Fi can also use the IEEE 802.11ak standard, which defines the interoperability of Wi-Fi and Ethernet networks, to enable seamless integration of wired and wireless TSN nodes.

[0020]

[0009] 5G is a wireless network technology that provides mobile broadband access to devices within a wide area network (WAN). 5G utilizes the 3GPP standard, which defines the wireless network architecture and protocols. 5G can support TSN standards by implementing TSN features in the radio link control (RLC) sublayer of the data link layer, such as time synchronization, traffic shaping, reliability, filtering, preemption, and configuration [4]. 5G can also utilize the 3GPP TS 23.501 standard, which defines the interoperability of 5G and Ethernet networks, to enable seamless integration of wired and wireless TSN nodes.

[0021]

[0010] In summary, the different types of data link layer technologies used to implement IEEE TSN are Ethernet, Wi-Fi, and 5G, which are network technologies that operate at the data link layer of the OSI model and provide frame delivery between nodes on the same or different network segments. These network technologies can support TSN standards and mechanisms by implementing TSN features in their respective data link layer sublayers, such as the MAC sublayer for Ethernet and Wi-Fi, and the RLC sublayer for 5G. These network technologies can also support the interoperability of wired and wireless TSN nodes using the IEEE 802.11ak standard for Wi-Fi and Ethernet and the 3GPP TS 23.501 standard for 5G and Ethernet.

[0022] REQUIREMENTS FOR A TSN BRIDGE

[0023]

[0011] Regardless of the type of link layer technology used, a TSN bridge requires the following functionalities to connect two or more segments of a TSN network and forward traffic according to TSN standards:

[0024] • Abstraction model: A TSN bridge is composed of two or more ports (externally accessible) interconnected internally and logically by a relay. Each external port has a MAC address, used as port identification addresses;

[0025] • Time Synchronization: A TSN bridge must support the IEEE 802.1AS [5] standard for time synchronization, which allows network devices to have a common notion of time and exchange time-sensitive messages with limited latency and jitter. A TSN bridge must also support the Generalized Precision Time Protocol (gPTP), which is an extension of the standard PTP that allows multiple time domains and clock classes;

[0026] • Traffic Shaping and Scheduling: A TSN bridge must support the IEEE 802.1Qbv and IEEE 802.1Qav standards for traffic shaping and scheduling, which allow the allocation of bandwidth and time slots for different types of traffic on the network. A TSN bridge must implement a time-aware scheduler (TAS) that can enforce the transmission and reception windows for each traffic class, and a credit-based scheduler (CBS) that can regulate the rate of time-insensitive traffic;

[0027] • Reliability and redundancy: A TSN bridge must support the IEEE 802.1CB reliability and redundancy standard, which enables frame replication and deletion for critical network traffic. A TSN bridge must implement a frame replication and deletion for reliability (FRER) function that can duplicate and discard frames at different points in the network to ensure that at least one copy of the frame reaches its destination;

[0028] • Filtering and Policing: A TSN bridge must support the IEEE 802.1 Qci standard for filtering and policing, which allows for the identification and control of traffic flows in the network. A TSN bridge must implement a per-flow filtering and policing function (PSFP) that can match received frames against predefined flow filters and apply corresponding flow gates and flow meters to regulate the access and rate of traffic flows;

[0029] • Preemption: A TSN bridge must support the IEEE 802.1 Qbu and IEEE 802.3br standards for preemption, which allows lower-priority traffic to be interrupted and resumed by higher-priority traffic on the network. A TSN bridge must implement a frame preemption (FPE) function that can split and merge frames of different traffic classes to reduce transmission delay and improve network utilization;

[0030] • Configuration and management: A TSN bridge must support the IEEE 802.1 Qcc standard for configuration and management, which enables discovery and reservation of resources for traffic flows on the network. A TSN bridge must implement a Stream Reservation Protocol (SRP) function that can negotiate traffic flow parameters and requirements with end devices and other bridges on the network, and allocate the necessary resources to the flows. A TSN bridge must also support the YANG data model and the NETCONF protocol for configuration and management, which enable standardized and interoperable methods for configuring and monitoring the TSN bridge and the network.

[0031] PASSIVE OPTICAL NETWORKS AS TSN BRIDGES

[0032]

[0012] The use of Wi-Fi and 5G networks for the implementation of TSN bridges allows interconnecting TSN end nodes and isolated TSN network segments to the rest of the TSN domain through the use of wireless networks. Within these recent advances in the industrial networking domain, the integration of Passive Optical Network (PON) systems, particularly industrial PON, has emerged as a fundamental technology to meet the multifaceted communication requirements of industrial intranets, since optical networks have advantages over radio frequency communications, such as reliability and high data transmission rate. As outlined in [6], industrial PON leverages passive fiber optic communication technology to establish a unified, secure, and reliable factory intranet.This facilitates seamless communication interaction between smart factories and digital workshops, addressing the challenges posed by diverse industrial protocols and heterogeneous network interconnections. A significant innovation lies in PON's ability to offer high-bandwidth access, slicing-based multi-service support, and protection schemes. With the growing interest in TSN networks for deterministic data transfer, the integration of Gigabit PON (GPON) components into a TSN network represents the next frontier. Such integration would combine the bandwidth and reliability advantages of GPON systems with the deterministic real-time data transfer capabilities of TSN, setting a new standard in industrial networking solutions.

[0033]

[0013] However, although the basic architecture and applications of Industrial PON have been defined, there are still gaps in achieving full integration of GPON components in converged TSN networks. As evidenced by the research presented in articles [7], [8], and [9], there is clear exploration of enhancing optical access network systems, such as XGS-PON, to operate according to industrial-grade standards, achieving deterministic scheduling, low latency, and jitter compensation. Additionally, in

[0010] , the authors demonstrate a traffic shaping and dynamic bandwidth allocation interface for PON networks that meets the aforementioned requirements. In

[0011] , machine learning techniques are used for bandwidth allocation to reduce latency and jitter. These studies validate the feasibility of converging PON networks with TSN networks, offering a new approach to serving time-critical applications.However, the current state of the art reveals significant gaps. Precise time synchronization mechanisms, as defined by IEEE 802.1 AS or gPTP, within GPON components are not deeply explored. Furthermore, while deterministic scheduling is discussed, the specifics of implementing core TSN standards such as IEEE 802.1 Qbv, IEEE 802.1 Qav, and others within GPON remain ambiguous. Critical protocols that enable reliability, redundancy, filtering, policing, preemption, and comprehensive configuration and management are not addressed. Furthermore, interoperability and security considerations in a TSN environment using GPON components remain unexplored. In short, GPON network components operate somewhat "transparently" in the end-to-end TSN link, as if they were part of the direct point-to-point link between two TSN nodes, and are therefore not configured as TSN ports.These open problems highlight the early stages of this integration and highlight the vast potential for innovation in this field.

[0034]

[0014] Furthermore, regarding the abstraction model requirement, patent

[0013] proposes a method and system for configuring Ethernet services in an EPON (Ethernet Passive Optical Networks) network. In which the elements of the EPON network are configured by characterizing interconnected ports with MAC addresses, thus behaving as a MAC bridge. In this context, the ITU-T G988 standardization

[0014] presents specifications for the management and control interface (OMCI) for the optical network unit (ONU) for applications involving a local area network (LAN). Thus, since the protocols required for the TSN standards are adaptations of the IEEE 802.3 Ethernet protocol

[0015] , which is used in EPON networks

[0016] , it is concluded that the aforementioned requirements can be implemented in EPON networks. Furthermore, it is already standardized according to the IEEE 802.1 AS, the implementation of the generalized precision timing protocol (gPTP) in an EPON network, aiming for it to be synchronized with other time-sensitive application components

[0017] .

[0035]

[0015] In addition, in

[0018] the design and implementation of an OpenFlow software-defined networking (SDN) agent that manages and configures 10-gigabit-capable symmetric passive optical network (XGS-PON) architectures are described. Acting as an OpenFlow switch, the SDN agent communicates with an SDN controller using OpenFlow, while maintaining direct communication with the optical line termination (OLT) through the manufacturer-specific application programming interface.

[0036]

[0016] The patent described in

[0012] presents a TSN bridge model based on the 5GS architecture for communication with mobile connectivity devices. In this aspect, the 5G TSN bridge integrated into an industrial automation scenario using TSN networks establishes the connection between (communicator) and (listener) through timed flows. The flows originate from a centralized network configuration (CNC), which has an end-to-end view of the TSN network and requests configuration information for the 5G infrastructure. Thus, the 5GS can be used as a TSN bridge that receives TSN information requirements and converts them into 5G QoS requirements, applying the required actions according to the TSN protocols. The conversion occurs through TSN translators that communicate with interfaces of the 5GS and the TSN system, mapping the QoS requirements of the 5G control system (core) and directing them to the TSN network information requirements present in the CNC.In general, a 5G TSN bridge is obtained using TSN translators integrated into the 5GS data and control plane, meeting the 5GS operation capabilities defined by 3GPP and the TSN protocol requirements.

[0037] OBJECTIVES AND ADVANTAGES OF THE INVENTION

[0038]

[0017] This invention aims to propose a method for using passive optical networks (PON) in the ITU-T PON standard as communication systems known as bridges interconnecting terminals of time-sensitive networks in the IEEE TSN standard. To this end, this invention proposes to incorporate new functionalities into the ITU-T PON network so that it can be identified and operated as an IEEE TSN bridge. To achieve this vision, the specific objectives of the invention include:

[0039] • Abstraction of the ITU-T PON Network: Establish a methodology that allows the ITU-T PON network to be recognized and operate effectively as an IEEE TSN bridge, facilitating its integration and interaction with other components of the IEEE TSN network;

[0040] • Time Synchronization in ITU-T PON Components: Formulate and implement advanced time synchronization mechanisms, aligned with IEEE 802.1 AS or gPTP standards, within ITU-T PON components, ensuring data transmissions with minimal latency and determinism;

[0041] • Harmonization of IEEE TSN and ITU-T PON Standards: Integrate and adapt IEEE TSN standards, such as IEEE 802.1AS for time synchronization and IEEE 802.1 Qbv for scheduling at the output of IEEE TSN bridge ports, to the ITU-T PON system, ensuring optimized traffic shaping and scheduling.

[0042]

[0018] Although the literature already explores techniques that meet some time synchronization, traffic shaping, and scheduling criteria, their applications are still limited to point-to-point links between two IEEE TSN terminals. Furthermore, the specifics of the standards used in ITU-T PON networks are not presented, thus making it ambiguous how the IEEE 802.1 AS and IEEE 802.1 Qbv standards are implemented in such networks. Therefore, meeting these objectives provides the following advantages over the state of the art:

[0043] • Enhanced Convergence: The invention promises a more fluid and efficient integration between ITU-T PON and IEEE TSN networks, establishing a new benchmark of excellence for time-sensitive applications;

[0044] • Adaptability and Expandability: The proposed abstraction is intrinsically flexible and scalable, allowing the integration of various network components without sacrificing performance or security;

[0045] • Minimization of Latency and Jitter. The proposed integration of IEEE TSN standards into ITU-T PON components aims to achieve significant reductions in latency and jitter, thus meeting the needs of the most time-sensitive applications.

[0019] In summary, the present invention aims to overcome the restrictions of the prior art, introducing an innovative solution for integrating ITU-T PON components in the form of an IEEE TSN bridge into IEEE TSN networks aiming to support deterministic communication in complex converged industrial network environments and supporting interoperability with IEEE TSN network equipment.

[0046] GENERAL DESCRIPTION OF THE INVENTION

[0047]

[0020] Considering the operation of IEEE TSN systems, it is clear that in order to propose an architecture in which ITU-T PON networks would play the role of the IEEE TSN bridge, a communication interface must be implemented between the CNC controller and a PON network control agent (for example, but not limited to, a controller based on the Open Network Operating System (ONOS)), in order to enable the implementation of the protocols determined by the CNC in such networks. The same must be implemented for the IEEE TSN user plane. Additionally, it is necessary to implement "translators" at the input and output of the ITU-T PON network. These translators are responsible for "translating" the time from the "external" Grandmaster Clock, which considers IEEE TSN standards, to the time considered internally in the PON network. Thus, achieving synchronization between the times in order to allow the PON network to play the role of IEEE TSN bridge.

[0048]

[0021] Therefore, assuming that such communication interface between the controllers is part of the present invention, the other implementations necessary in such interface will be presented and detailed so that the PON networks meet all the requirements of an IEEE TSN bridge mentioned above.

[0049]

[0022] According to the IEEE 802.1AS standard, IEEE TSN network devices must communicate considering a common notion of time and must respect latency and jitter limits according to the application. In this context, considering PON networks, advanced techniques for dynamic bandwidth allocation are proposed, aligned with the required resources determined by the CNC. Furthermore, the use of the IEEE 1588v2 Precision Time Protocol (PTP) is also proposed on the ports that interconnect the PON network components with the IEEE TSN components. The aim is to synchronize the PON network components with the other components of the IEEE TSN system according to the Grandmaster clock, responsible for being a reliable time source.

[0050]

[0023] Regarding traffic shaping and scheduling, the communication interface between the CNC and the optical system control agent must be aligned to ensure the implementation of a time-aware scheduler and a credit-based shaper that can regulate the rate of time-insensitive traffic. Such techniques can be implemented by the optical controller, which determines the dynamic bandwidth allocation algorithms and the scheduler.

[0024] Following the same line of reasoning, considering that optical control agent configurations will be added to the OLT and ONU according to the CNC's requests. Functions that ensure policing and filtering that respect the traffic control policies present in the IEEE 802.1 Qci standard will also be implemented; a flow reservation protocol function supporting the IEEE 802 standard.1 Qcc in the configuration and management of traffic forwarded to the OLTs and an adaptation will be made in the way the ONUs read the received data, considering all the additional functions that will be implemented or adapted from existing functions, including in illustrative but not limiting examples the ITU-T protocols (G.9807.1: W-Gigabit-capable symmetric passive optical network (XGS-PON), G.987: W-Gigabit-capable passive optical network (XG-PON), G.984.1: Gigabit-capable passive optical networks (GPON), among others).

[0051]

[0025] Furthermore, aiming at the interoperability of IEEE TSN bridges with different manufacturers, in an illustrative but non-limiting example, it can be seen that there are optical controllers such as ONOS that have integration with the YANG data model and the NETCONF protocol. Thus, enabling the PON network with the functionality of an IEEE TSN bridge.

[0052]

[0026] The main application of this technology is in the domain of industrial networks, where deterministic and real-time communication is crucial for the operation and safety of machines and processes. By allowing PON components to act as IEEE TSN bridges, the invention facilitates the convergence of industrial networks, providing a robust and efficient solution for time-sensitive applications. In addition to its main application in industrial environments, the technology has the potential to be used in several other domains, including (a) automotive, for real-time communications between vehicles and infrastructure; (b) aerospace, ensuring deterministic communications in air traffic control systems; (c) healthcare, in medical equipment that requires real-time data transmission; (d) smart grids, for monitoring and control of power grids; and (e) audio / video streaming, ensuring content delivery without delays or interruptions.

[0053] DESCRIPTION OF FIGURES

[0054]

[0027] The invention will be described in detail below, and for better understanding, references will be made to the attached drawings, in which the following are represented:

[0055] Figure 1: Representation of how a PON network is inserted as a TSN bridge in a fully centralized IEEE TSN network;

[0056] Figure 2: Process of discovery and identification of PON network devices;

[0057] Figure 3: Process of carrying out the inventory of the XG-PON network topology;

[0058] Figure 4: PON network synchronization process;

[0059] Figure 5: XG-PON network synchronization verification process performed by GrandMaster Clock PTP;

[0060] Figure 6: Illustration showing how the TSN bridge representing the PON network is inserted into the different segments of the TSN network;

[0061] Figure 7: Process of mapping the topology of the TSN network sections represented by the TSN / Ethernet devices external to the PON network elements;

[0062] Figure 8: Periodic update of TSN bridge capabilities;

[0063] Figure 9: IEEE TSN stream session request process;

[0064] Figure 10: Downlink TSN flow session setup process',

[0065] Figure 11: TSN flow session setup process in uplink',

[0066] Figure 12: Diagram referring to the configuration of an XG-PON network acting as a MAC bridge according to the ITU-T G.988 standard;

[0067] Figure 13: Implementation of the scheduler in the downlink flow of the XG-PON network;

[0068] Figure 14: Diagram of the uplink flow scheduling process of the XG-PON network; Figure 15: Example of the 802.1 Qbv processing that each network card implements.

[0069] DETAILED DESCRIPTION OF THE INVENTION

[0070]

[0028] According to the present invention, it is proposed in this patent application the mapping of a PON network as a TSN bridge inserted in a completely centralized IEEE TSN network (i.e., where the control of the TSN bridge data plane is done by the CNC) through the introduction of a new component in the PON network called the TSN Bridge Controller. This new component will be responsible for interacting in the control plane with the CNC and translating the CNC's requests to the PON network both regarding TSN bridge information and resource reservations for the establishment of TSN flow sessions. An illustrative, but non-limiting example of this mapping is represented in Figure 1, where the bridge (105) interacts with the CNC in the control plane through a new proposed element, called the TSN Bridge Controller (106). In an illustrative, but non-limiting example of how this control plane can be implemented, the 802.1 Qcp, 802.1 Qcc and 802.1 Qbv can be used in the interaction between the CNC and the TSN bridge controller. In another illustrative, but not limiting, example, the TSN bridge representing the PON network connects in the data plane with the Speaker (115) and Listener (116) end nodes through the TSN bridge ports (107), (108), (109), (110), which are logically associated with Ethernet interfaces that support the IEEE TSN standard (111), (112), (113), (114) linked to the PON OLT and ONU network elements (101), (102), (103), (104). Although not part of the claims of this invention, in an illustrative but non-limiting example the TSN Bridge Controller can be implemented through software components such as the XG-PON network physical layer virtualization agent (i.e., VOLTHA), which abstracts the physical topology of the network into a decentralized, cloud-based architecture with standardized elements and open interfaces.Still in this example and following the PON network control plane environment, there is the SDN controller with open and standardized APIs (i.e., ONOS) to perform the control of optical infrastructure services and applications and transfer requests from a higher management layer to the implemented PON network. Although also outside the scope of the claims of this patent, we present another illustrative, but non-limiting example represented in Figure 1 of how the Speaker (115) and Listener (116) nodes can connect in the control plane with the CUC (117) through the use of the OPC UA protocol, while the CUC (117) can connect in the control plane (116) through the UNI protocol, specified in the IEEE 802.1Q standard, and its improvements in the form of the IEEE 802.1Qdj standard.

[0071]

[0029] We extend the use of Ethernet interfaces associated with the elements of a PON network as proposed in the ITU-T G.987.1 standard to be Ethernet interfaces adhering to the IEEE TSN standard as specified in the IEEE 802.1 Q-2022 standard. In an illustrative but non-limiting example, this Ethernet interface adhering to the IEEE TSN standard must minimally support the following additional functionalities to a conventional Ethernet card: a) Time synchronization: an IEEE TSN network interface must support time synchronization in accordance with the IEEE 802.1 AS standard ( / .e., gPTP), with an illustrative but non-limiting example of this operation illustrated in Figure 4; b) Traffic Scheduling: The outgoing traffic from the TSN bridge port that this IEEE TSN interface represents must be able to follow the Time-Aware Shaper (TAS) scheduling algorithm of the IEEE 802.1 Qbv standard, with an illustrative but not limiting example of this algorithm illustrated in Figure 15.

[0072]

[0030] Still according to the invention, it is proposed that the TSN Bridge Controller performs the discovery and identification of the PON network devices represented in Figure 2 by means of a request to the OLT. In an illustrative, but non-limiting example, the TSN Bridge Controller connects to the OLT through the gRPC protocol, which sends a request for the discovery of the devices connected in the PON network. In another illustrative, but non-limiting example, the OLT connects to the ONU through the OMCI protocol, described in the ITU-T G. 988 standard, to establish communication with the PON port associated with the OLT and, from there, also establish communication with the PON port associated with the ONU. The purpose of this communication is to verify whether the connected ONUs are reachable.Still part of this illustrative, but not limiting, example is the response of the ONU communication to the OLT, containing the verification of the ONU operational status that is resumed by the OMCI protocol and sent from the OLT to the TSN bridge controller through the gRPC protocol, which contains the information of the devices connected in the PON network.

[0073]

[0031] It is further proposed that the TSN Bridge Controller collect the inventory of the PON network topology represented in Figure 3 by means of a request to the OLT. In an illustrative, but not limiting, example, the TSN Bridge Controller generates a request to prepare the inventory and forwards a request for topology connections to the OLT and connects to the OLT through the gRPC protocol. The OLT identifies the PON ports with connections to the topology elements and returns the addresses of the connected ports to the TSN Bridge Controller. Using the OLT port information, the controller maps the physical and logical connections of the topology, forming a database of the information structure within the TSN Bridge Controller inventory.

[0074]

[0032] It is also proposed that the PON network elements represented by the OLTs and ONUs use the time synchronization protocol based on the PTP standard for their synchronization, with the OLT acting at the same time as a PTP write port to receive synchronization from a GrandMaster Clock and as a PTP master port for the ONUs that act as PTP write ports to receive synchronization from the OLT. In an illustrative, but not limiting, example, a time synchronization protocol such as IEEE 802.1AS can be used, so that periodically a GrandMaster Clock PTP synchronizes the OLT according to steps 401 to 406, and then for each ONU connected to the OLT, the OLT acts as a PTP master port to synchronize each ONU according to steps 407 to 412.

[0075]

[0033] It is also proposed that the TSN bridge centralized network controller performs the PON network synchronization check for QoS, or Quality of Service, purposes, shown in Figure 5. In an illustrative, but not limiting, example, the CNC forwards a device synchronization verification request via the Yang / NETCONF model to the TSN bridge controller. Upon receiving the call, the TSN bridge controller sends the request with the parameterized values ​​within the PON network domain to the OLT, and the request is processed to perform a synchronization test between the OLT terminals. At the user plane, the synchronization test is performed with the GrandMaster Clock and the OLT input ports, and the PON ports with the ONUs, according to the TSN bridge requirements. The synchronization data between the devices is forwarded from the OLT to the TSN bridge controller and processed for the TSN network parameters, which are returned to the CNC.

[0076]

[0034] It is proposed that the TSN Bridge Controller maps the topology of the external IEEE TSN devices connected to the PON network elements (OLTs and ONUs). In an illustrative but non-limiting example, represented in Figure 6, each PON network element has an IEEE TSN network interface (a special type of Ethernet interface) with which this PON network element connects to other IEEE TSN network devices. The topology discovery process expressed in steps 701 to 708 in Figure 7 can be done using different existing protocols. In an illustrative but non-limiting example, the Spanning Tree Protocol (STP), defined in the IEEE 802.1D standard and IETF RFC 4361, is implemented in switches to monitor the topology of the Ethernet network and can be used by sending Bridge Protocol Data Unit (BPDU) messages between the IEEE TSN network devices.These messages contain information about the network topology, including the device's MAC address, bridge ID, and the cost of each link. In this example, STP uses a blocking and forwarding algorithm to ensure there is only one route to each node in the TSN network. Another illustrative, but not limiting, example is the Link Layer Discovery Protocol (LLDP), defined in the IEEE 802.1AB standard and IETF RFC 3046. LLDP can be used as a component in the management and monitoring of Ethernet networks, and is also used in data center bridging requirements. In this example, LLDP is a data link layer protocol that allows devices to send and receive information about themselves and their adjacent links. LLDP sends LLDP frames periodically to all adjacent devices. These frames contain information about the device's MAC address, device name, device type, and the cost of each link.In general, LLDP is a good choice for small and medium-sized networks that need a simple and efficient way to discover network topology. STP, on the other hand, is a good choice for large or complex networks that require a more reliable and secure protocol. Both STP and LLDP can be used by OLTs and ONUs, as well as by the CNC to query the topology from the TSN bridge controller.

[0077]

[0035] The process of periodically updating the capabilities of the TSN bridge described in Figure 8 is served by the TSN bridge controller. In an illustrative, but not limiting, example, both the request for capabilities in step 801 and the response with the compiled capability information in step 803 may be implemented through the IEEE 802.1 Qcc protocol. Step 802 corresponding to the retrieval of capability information from the TSN bridge and compilation of the response returned to the CNC may be performed to determine the specific capabilities, resources, and characteristics available on the TSN bridge. This request is part of the broader network configuration and management process in a Time-Sensitive Network (TSN) environment.When the CNC submits a TSN bridge capability request, it typically seeks information about the following: a) Queuing Mechanisms: The CNC needs to understand the types of queuing mechanisms supported by the TSN bridge, such as Credit Based Shaper (CBS), Asynchronous Traffic Shaping (ATS), or Time-Aware Shaper (TAS). Each of these has specific characteristics and use cases; b) Traffic Class Handling: Information about how the bridge handles different traffic classes, as defined in the IEEE 802.1Q standard, is crucial.This includes the number of queues per traffic class and the priority levels; c) Frame Preemption Support: The bridge's ability to support frame preemption, which allows high-priority frames to preempt low-priority frames, is important for managing traffic with strict latency requirements; d) Redundancy and Reliability Features: The CNC may inquire about the bridge's support for features such as Frame Replication and Erasure for Reliability (FRER), as defined in IEEE 802.1 CB, which increases the reliability of data transmission; e) Synchronization Capabilities: Because TSN relies on precise timing, the CNC needs to know the bridge's capabilities in supporting time synchronization protocols such as IEEE 802.1AS; f) Resource Allocation Protocol (RAP) support: Understanding how the bridge manages and allocates network resources is crucial for efficient network operation; g) YANG Model support: The CNC may also inquire about the bridge's compatibility with specific YANG models for configuration and management, as defined in standards such as IEEE 802.1 Qcp; h) Port and Link Attributes: Information about physical and logical ports, including their speeds, types, and status, is vital for network planning and optimization.

[0078]

[0036] In an illustrative but non-limiting example, the TSN bridge controller indicates support for Time-Aware Shaper (TAS), which is a queuing mechanism that utilizes a timer to control the transmission rate of a data stream. In another illustrative but non-limiting example, the TSN bridge controller maps the 8 QoS classes established by the IEEE TSN standard into the 8 QoS classes supported by the ITU-T G.988 standard. In another illustrative but non-limiting example, the TSN bridge controller indicates that it supports neither frame preemption nor redundancy and reliability nor RAP. In another illustrative but non-limiting example, the TSN bridge controller indicates that it supports the IEEE 802.1AS time synchronization protocol.And finally, in an illustrative but non-limiting example, the TSN bridge controller uses its mapping of OLTs and ONUs to map the physical and logical ports, following the following logic: a) Physical ports: each OLT and ONU represents a physical port of the TSN bridge; b) Logical ports: the logical ports are reported, one for each physical port; c) Links: the PON links between the OLTs and ONUs are mapped to links between the physical ports.

[0079]

[0037] Illustrative but non-limiting examples of TSN flow configuration information between the different components of the TSN network are proposed, listed below: a) Speaker — CUC (step 901 of Figure 9): Interval, max. frames per interval, max. frame size, initial transmission offset, final transmission offset, jitter, minimum latency, source and destination MAC addresses; b) CUC — CNC (step 902 of Figure 9): Interval, max. frames per interval, max. frame size, initial transmission offset, final transmission offset, jitter, minimum latency, source and destination MAC addresses;of frames, initial transmit offset, final transmit offset, jitter, minimum latency, source and destination MAC addresses; c) CNC — TSN Bridge Controller (step 907 in Figure 9): Transmission selection, gate control list, time slot, cycle start; d) CNC — CUC (step 910 in Figure 9): Speaker Configuration, Listener Configuration; e) CUC — Listener (step 911 in Figure 9): Flow ID, end station interface, accumulated latency, source MAC address, VLAN ID; f) CUC — Speaker (step 912 in Figure 9): End station interface, MAC address, VLAN ID, slot, transmission offset, transmission selection.

[0080]

[0038] It is proposed that the configuration of the TSN bridge, shown in Figure 9 in step 908, in the downlink flow be performed by configuring XG-PON network parameters, such as traffic classes and identifiers of the GPON encapsulation methods (XGEM-Ports) by the TSN Bridge Controller, which, by way of example, may be an SDN controller. In an illustrative, but not limiting, example, such parameters are defined based on the traffic class described in the IEEE 802.1 Qbv standard and sent by the CNC of the TSN network, as described in step 1001 of Figure 10. Therefore, in step 1002, the TSN Bridge Controller configures the OLT parameters to adopt the MAC bridge service, as detailed in Figure 12, and defines the VLAN and MAC addresses of the ports and the priority traffic of the 802.1p mapping according to the Gate Control List sent by the CNC.Therefore, optical transmission is performed over the XG-PON network, adapting its scheduling configuration to accommodate priority traffic, as detailed in Figure 13. The OLT classifies and assigns XGEM port identifiers so that higher-priority traffic is directed to the corresponding traffic containers on the ONU (step 1308 in Figure 13). All ONUs receive the same signal from the OLT and perform filtering and association of their corresponding XGEM ports (step 1315 in Figure 13). Furthermore, each XGEM port is directed to a queue and sent to the ONU's communication interface with the terminal according to its priority in the output scheduler (step 1319 in Figure 13). If flows have the same priority, a Weighted Round Robin scheduler is applied. This completes the transmission of control traffic, focusing on scheduling the XG-PON network.After processing the traffic received by the ONU, it sends it to the ONU's IEEE TSN Board so that it can implement the scheduling rules defined in the IEEE 802.1 Qbv standardization, according to the configurations sent by the TSN Bridge Controller through the PON network in step 1008 of Figure 10.

[0081]

[0039] The TSN traffic configuration, shown in Figure 9 in step 908, is proposed in the uplink flow, detailed in Figure 11 of this document. Therefore, in the proposed architecture, the TSN network controller, CNC, sends to the TSN Bridge Controller (as a non-limiting example, an SDN controller) the TSN deterministic traffic parameters following the IEEE 802.1 Qbv protocol, as per step 1101. The TSN Bridge Controller, in turn, configures the uplink traffic of the PON network, which is transmitted using the Time Division Multiple Access (TDMA) technique. Thus, acting in the mapping of bandwidth allocation for the transmission of traffic containers (T-CONTs) identified by their respective Alloc-IDs. Therefore, the TSN Bridge Controller sends the allocation mapping to the OLT in step 1102, after configuring the PON network as a MAC bridge, as described in detail in Figure 12.In PON networks, the Dynamic Bandwidth Allocation (DBA) algorithm is typically used for efficient bandwidth allocation, considering the capacity demands of each traffic stream. For the TSN scenario, this allocation must be deterministic, and it may be necessary to use DBA adaptations proposed in the literature. In the proposed invention, the priority and scheduling of traffic classes represented by their traffic containers are imposed by the TSN controller. Figure 14 details the PON network scheduling diagram. For each 125-ps PON frame, the OLT sends the bandwidth mapping (BWmap) to the ONUs. In the case of deterministic DBA, if critical traffic requires more than one PON allocation frame, the DBA allocates traffic in the quantity resulting from the least common multiple of the PON frames. In step 1103, the ONUs are configured to send the priority traffic class (T-CONT) at the time determined by the OLT.As shown in Figure 14, different ONUs may have traffic classes with the same priority. In this situation, Weighted Round Robin scheduling will be considered. After ONU processing, the traffic is sent and the uplink flow is received by the OLT, where it processes and reads the signal and sends it to the OLT's IEEE TSN Board, which receives the scheduling algorithm parameters according to the IEEE 802.1Qbv standard, such as the cycle's Gate Control List and the VLAN addresses sent by the OLT in step 1107 of Figure 11.

[0082]

[0040] A new OMCI management framework is proposed, as a vendor-specific specification for sending the scheduling algorithm parameters, in accordance with the IEEE 802.1 Qbv standard, sent by the CNC to the TSN Bridge Controller (step 1001 in Figure 10 for downlink and step 1101 in Figure 11 for uplink), which in turn sends them to the OLT (step 1002 in Figure 10 for downlink and step 1102 in Figure 11 for uplink). The OLT then sends the scheduling configurations to the ONU IEEE TSN Board for downlink (step 1008 in Figure 10) and to the OLT for uplink (step 1107 in Figure 11). The main parameters sent are: VLAN address, Gate Control List, guard band and clock synchronization. The traffic class identifiers (Alloc-IDs) of the PON networks are also sent so that the connection with the TSN traffic classes can be made.

[0083]

[0041] Detailed descriptions of the Figures shown in this patent application now follow.

[0084]

[0042] In Figure 1 , we illustrate a representation of how a PON network (100) inserts itself as a TSN bridge (106) into a fully centralized IEEE TSN network. The PON network (100) in question is composed of an OLT (101 ) and more than one ONU (102), (103), (104). This PON network receives additional components to insert itself as a TSN bridge (105) with the addition of a TSN bridge controller (106), the TSN bridge ports associated with the OLT (107) and the ONUs (108), (109), (110) and the IEEE TSN network cards of the OLT (111 ) and the ONUs (112), (113), (114) that physically connect to the OLT and ONUs and logically to the TSN bridge ports. This TSN bridge (105) is then physically connected to the Speaker (115) and Listener (116) end nodes in the data plane, and in the control plane to the centralized network controller - CNC (116), which is in turn connected to the centralized user controller - CUC (117), which connects in the control plane to both the CNC and the Speaker and Listener end nodes.

[0085]

[0043] In Figure 2, we illustrate the process of discovering and identifying devices in the PON network. Initially, the TSN bridge controller discovers the OLT and ONUs in the PON network through a request from the controller to the OLT and ONUs. Then, information about specific network devices and resources is sent and collected from the OLT to the TSN bridge controller. In step 201, the TSN bridge controller begins the process of identifying connections with devices in the XG-PON network. In step 202, a request is forwarded to the connected OLT to discover network devices, and the mapping of ports with OLT connections is performed in step 203. In step 204, the OLT checks whether the connected ONUs are reachable, and in step 205, the mapping of ONU ports is performed and the operational status of each ONU is returned to the OLT in step 206.Finally, in step 207, the information and specifications of the devices present in the XG-PON network are sent to the TSN Bridge controller.

[0086]

[0044] In Figure 3, we describe the process of performing the topology inventory of the XG-PON network. In this process, the TSN bridge controller maps the logical and physical connections of the XG-PON network, including the ODN topology implemented in the TSN bridge controller environment. In step 301, the TSN bridge controller releases a request to assemble the inventory of the connected network and a request for the topology connections to the OLT in step 302, obtaining a return of the physical and logical connection information of the PON network specified in step 303. According to step 304, the physical and logical connections are received and mapped by the controller to form the ODN topology of the implemented XG-PON network. In step 305, the formed topology is described and visualized in the network inventory.

[0087]

[0045] In Figure 4, we describe the PON network synchronization process. In this process, the TSN bridge controller forwards an authentication flow to the OLT that ensures the synchronization of all connected devices for dynamic bandwidth allocation, or DBA, and QoS parameters, and receives the flow containing the process execution from the OLT. Periodically, the previously configured GrandMaster Clock PTP sends a PTP Synch message to the OLT in step 401 and internally stores the time t1 equivalent to the moment of sending. Receiving this message then triggers the OLT to collect the time T2 equivalent to the moment of receipt of the PTP Synch message. Then, the GrandMaster Clock sends a PTP Follow_Up message to the OLT in step 402 containing the time t1 of the previous PTP Synch message, at which point the OLT will have both the time t1 and the time t2 in hand.Then, in step 403, the OLT sends a PTP Delay_Req message to the GrandMaster Clock and stores the time t3 corresponding to the sending of the PTP Delay_Req message. Upon receiving this message, the GrandMaster Clock collects the time t4 corresponding to the time at the moment of receipt of the PTP Delay_Req message. Finally, in step 404, the GrandMaster Clock sends a PTP Delay_Resp message to the OLT containing the time t4 corresponding to the time at the moment of receipt of the PTP Delay_Req message. At this moment, the OLT has the times t1 , t2, t3 and t4 necessary both for calculating the link delay via e.g. formula [(t4 - t1 ) - (t3 - 12)] / 2 (405) and for the time synchronization offset via e.g. formula [(t2 - 11 ) - (t4 - 13)] / 2 (406). Similarly, once synchronized, the OLT acts as a reference clock for synchronizing the ONUs via a similar process in steps 407 to 412.

[0088]

[0046] In Figure 5, we describe the XG-PON network synchronization verification process performed by the GrandMaster Clock PTP to provide synchronization between devices and meet the TSN bridge requirements. In step 501, the centralized network controller (CNC) of the TSN network sends a request to verify the met synchronization requirements and is translated to the TSN bridge controller domain, transferring the verification request to the OLT in step 502. The OLT receives the request and establishes the synchronized port paths between devices according to step 503. Next, the OLT contacts the synchronized port of the ONU to verify the synchronization requirements according to step 504 and obtains the synchronization response from the ONU according to the configurations implemented for the TSN bridge in step 505.The synchronization data is sent to the TSN bridge controller and processed into the CNC request format as per steps 506 and 507, respectively. To finalize the verification request, in step 508 the information containing the synchronization data is sent to the CNC.

[0089]

[0047] In Figure 6, we illustrate how the TSN bridge representing the PON network, formed by the OLT (601) and ONUs (602), (603), (604) as well as the TSN bridge controller (608), is inserted in the different segments of the TSN network through the IEEE TSN interfaces (606), (608) linked to the OLT and the ONUs. These interfaces, consequently, are connected via the Ethernet / IEEE TSN network to other IEEE TSN devices (607), (608).

[0090]

[0048] In Figure 7, we describe how the topology mapping process of the TSN network sections represented by the external TSN / Ethernet devices to the PON network elements (i.e., TSN / Ethernet devices connected to the OLTs and ONUs) occurs. Independently, each PON network element connected to the IEEE TSN network (i.e., OLTs and ONUs) executes at regular intervals a procedure for the periodic discovery of the physical topology of the external IEEE TSN devices connected to the OLTs through the IEEE TSN cards of the GPON network elements. In an illustrative example, in step 701 the OLT triggers the physical topology mapping update procedure, and for each external device connected to the OLT, the OLT sends a topology request 702 to the external device, and the latter returns the topology 703 to the OLT.The OLT then compiles all external topology responses received from external devices and stores the information in an external topology table in 704. Similarly, the same procedure occurs independently for the ONUs in steps 705, 706, 707, and 708. When the TSN bridge controller needs to update the external topology (e.g., due to an external request from the CNC in step 709), the controller will issue a topology request for each OLT 710. The OLT will then perform step 711 to query its own IEEE TSN external topology information table and, for each ONU, will issue an IEEE TSN external topology request in step 712. The ONU will then perform an internal query of its IEEE TSN external topology information table in step 713 and return this information to the OLT in step 714.The OLT will then compile its own topology data along with the topology data received from the ONUs and then return this set of topology data to the TSN bridge controller in step 715. Finally, in step 716 the TSN bridge controller returns the external IEEE TSN topology information related to this TSN bridge to the CNC.

[0091]

[0049] In Figure 8, the CNC sends in step 801 a request for the capabilities (i.e., capacities) of the TSN bridge to the TSN bridge controller. This request triggers an internal process in step 802 for retrieving capability information from the TSN bridge, which compiles the information and returns it to the CNC in step 803.

[0092]

[0050] In Figure 9, we illustrate the IEEE TSN stream session request process. In step 901, an IEEE TSN end node, or speaker, requests a TSN streaming session from the CUC, which then forwards this request to the CNC in step 902. Upon receiving this request, the CNC performs the TSN domain configuration in step 903, and for each TSN bridge in the TSN network, it performs in step 904 a physical topology check of the TSN network as observed by that specific TSN bridge, which corresponds to the process in Figure 7 between steps 709 and 716. Also, for each TSN bridge, the CNC performs a validation of support for the TSN streaming session requirements by the TSN bridges in step 905, which corresponds to the process in Figure 8 in steps 801 to 803. In step 906, the CNC performs the path computation (end-to-end link) between the TSN end nodes (Speaker and Listener) for the TSN streaming session, as well as such as scheduling the flows required for each node of the end-to-end link (i.e., TSN bridges) between the TSN end nodes. Then, for each TSN bridge in the defined link path, the CNC sends the TSN functionality configuration to the TSN bridge controller in step 907, including information such as the bridges to be allocated, the VLAN IDs associated with the TSN flow session, and the specific scheduling for the VLAN IDs. With this information, the TSN bridge controller configures the TSN bridge in step 908, described in greater detail in Figures 10 and 11. Once the TSN bridge configuration is complete, the TSN bridge controller returns the configuration data to the CNC in step 909. Once the configuration of all TSN bridges in the defined link path is complete, the CNC sends the flow and interface configuration for each end station in step 910 to the CUC, which consequently sends the specific configuration of the TSN flow session to the TSN end nodes (Listener and Speaker) in steps 911 and 912, respectively.

[0093]

[0051] In Figure 10 we present an illustration of the downlink TSN flow session setup process (i.e., of TSN traffic flowing from the OLT to the ONU). In step 907 of Figure 9, the TSN flow session configuration request is sent by the CNC to the TSN bridge controller, which executes a sequence of steps to configure the TSN flow session equivalent to step 908 of Figure 9. This sequence of steps includes steps for configuring the QoS of the downlink flow, which are steps 1001, 1002, 1003, 1004 and 1005, and for configuring IEEE 802.1 Qbv scheduling on the IEEE TSN board of the OLT, which are steps 1006, 1007, 1008, 1009 and 1010. Finally, step 909, equivalent to the same step in Figure 9, resumes the TSN flow session configuration.In more detail, step 908 of Figure 9 begins with step 1001, in which the TSN Bridge controller determines the parameters related to the XG-PON network, such as traffic class identifiers (Alloc-ID) and GPON encapsulation method identifiers (XGEM-Ports), based on the quality of service (QoS) attributes determined for each traffic class by the CNC. Then, in step 1002, the OLT is configured using the TSN Bridge Controller, which, as an illustrative but non-limiting example, can be an SDN controller. The configuration of the XG-PON network to adopt MAC port functions is further detailed in Figure 12. With the OLT configured with the determined scheduling parameters, in step 1003 the optical signal is transmitted to the ONUs, which are connected to the corresponding IEEE TSN Boards. After the ONU reads the signal, confirmation messages are sent in steps 1004 and 1005.The IEEE TSN Boards of the ONUs are responsible for implementing the scheduler based on the IEEE 802.1 Qbv standard, since, in step 1006, the TSN Bridge Controller also sends to the OLT through a new protocol added in the OMCI as a manufacturer's specification the QoS requirements that must be implemented in the scheduling algorithm to meet the IEEE 802.1 Qbv standard. And the OLT, in turn, in step 1007, sends the configurations to the ONU, which completes the flow by sending such information to the IEEE TSN Board in step 1008. Finally, the ONU and OLT send confirmation messages (1009 and 1010), thus finalizing the configuration of the TSN port in step 909.

[0094]

[0052] In Figure 11, we present an illustration of the process of configuring a TSN flow session in the uplink (i.e., of TSN traffic that flows from the ONU to the OLT). In step 907 of Figure 9, the TSN flow session configuration request is sent by the CNC to the TSN bridge controller, which executes a sequence of steps to configure the TSN flow session equivalent to step 908 of Figure 9. This sequence of steps includes steps for configuring the QoS of the uplink flow, which are steps 1001, 1002, 1003, 1004 and 1005, and for configuring IEEE 802.1 Qbv scheduling on the IEEE TSN board of the OLT, which are steps 1006, 1007, 1008, 1009, 1010 and 1011. Finally, step 909, equivalent to the same step in Figure 9, resumes the TSN flow session configuration.Detailing the aforementioned steps, the flow session setup process begins with step 1101, in which the parameters related to the TDMA scheduling of the XG-PON network are determined to meet the QoS requirements of the TSN traffic received from the CNC. Therefore, in step 1102, these parameters are sent to the OLT to implement the identification of traffic classes (Alloc-ID) and determine their configuration according to the QoS requirements. In step 1103, the bandwidth allocation mapping (BWmap) for the Alloc-IDs is sent from the OLT to the ONU, aiming at implementing the deterministic dynamic bandwidth allocation algorithm (detDBA) previously proposed in the literature; concluding with the confirmation messages (steps 1104 and 1105). Additionally, the scheduling algorithm is configured according to the IEEE 802 standard.1 Qbv is sent from the TSN Bridge controller to the OLT in step 1106. In this way, the traffic class identifiers configured for the optical transmission of the XG-PON network in step 1102 are considered in the implementation of the scheduling algorithm. In step 1107, the final algorithm configuration is sent to the OLT's IEEE TSN board for implementation. The step ends with the confirmation messages from steps 1108 and 1109.

[0053] Figure 12 presents the diagram referring to the configuration of an XG-PON network acting as a MAC bridge in accordance with the ITU-T G.988 standard. From the request to configure the TSN bridge by the CNC in step 907 of Figure 9, the configuration of the XG-PON network begins acting as a MAC bridge, aiming to meet the requirements of a MAC bridge described in the IEEE 802.1 Q standardization. In step 1201, the TSN Bridge Controller sends the network attributes to the OLT, such as MAC addresses, VLAN identifiers, among others.Next, in step 1202, the OLT creates a Managed Entity (ME) associating the addresses and identifiers with the GPON encapsulation method (XGEM-Port), receiving an acknowledgment from the ONU after each step. Subsequently, in step 1204, an ME is created that describes the adaptation processing functions of the XG-PON transmission convergence layer for Ethernet services (GEM Adaptation Layer). Next, in step 1206, a MAC Bridge Service Management Entity (ME), described in the ITU-T G.988 standard, is created for each user interface. With this ME activated, in step 1208, it is possible to create an uplink flow mapping based on IEEE 802.1p traffic prioritization. Next, the Access Node Interface (ANI) is configured, initially in step 1210. iThe MAC bridge configuration management entity is created. In step 1211, the ONU instantly creates its respective ME, allowing the OLT to create the VLAN filtering ME in step 1212. With knowledge of the VLAN, in step 1214, the OLT creates the XGEM-Port management entity for interconnection (IW) with an Ethernet terminal (TP), allowing the PON network's XGEM-Port to be related to the Ethernet protocol identifiers. Thus, in step 1216, the mapping defined in step 1208 is implemented, defining the XGEM-Port IW priority. Finally, the last step consists of the OLT configuring the user network interface on the ONU. To do this, in step 1218, the OLT creates the UNI's MAC port configuration ME; then, in step 1219, the ONU automatically creates its MAC port configuration MEs. Finally, the OLT creates the management entity for configuration and tagging of the VLAN configured in step 1220, receiving the response from the ONU in step 1221.Thus, in step 1222 the OLT sends the configuration confirmation to the TSN Bridge Controller, which in turn finalizes the configuration in step 909.

[0095]

[0054] In Figure 13, we detail the implementation of the scheduler in the downlink flow of the XG-PON network, considering a non-limiting example of an application with two ONUs. Initially, at 1301, there is the communication interface between the OLT (1307) and the management layer. The received data is classified according to traffic class (1311), (1312), (1313), following the IEEE 802.1 Qbv scheduling algorithm, considering 8 traffic classes. Subsequently, the scheduling of the traffic classes is performed according to their priorities (1310). Taking into account the algorithm described in IEEE 802. Qbv, which is detailed in Figure 15, such a scheduler must fulfill the Gate Control List requirements determined by the CNC, which in turn forwards it to the TSN Bridge Controller, which acts as the management layer over SDN.At 1302, the data is multiplexed considering its XGEM-Ports ID and sent to the ONUs (1314), (1315), which, upon receiving the data flow, perform filtering and queue assignment according to their respective XGEM-Ports ID at 1316. Thus, the queues (1320), (1321), (1322) are implemented for each terminal (1317), (1318) that is connected to the ONU considering the traffic classes. If possible, apply the scheduling at 1319 again to such traffic considering the TSN flow requirements to finalize the data transmission at the ONU and terminal communication interface (1304), (1305), (1306). If there are flows belonging to the same traffic class, scheduling algorithms such as Weighted Round Robin (WRR) are implemented to send only one flow at a time.

[0096]

[0055] In Figure 14, we describe in a simplified way a diagram of the uplink flow scheduling process of the XG-PON network. In this scenario, the transmission from the ONUs to the OLT is performed through the Time Division Multiple Access technique, or TDMA, which is implemented by a bandwidth allocation algorithm, which can be fixed (FBA - Fixed Bandwidth Allocation) or dynamic (DBA - Dynamic Bandwidth Allocation). Since the second provides greater efficiency, it is commonly used. Thus, considering that the data transmission starts from the network communication interface with the terminals (1410), (1411), which are connected to the ONUs (1413), (1414). It can be seen that each ONU, for example 1413, can receive flows of different traffic classes, therefore, the received flows pass through a classifier 1429, which generates different queues (1425), (1426), (1427), (1428) corresponding to different traffic classes.Therefore, a band will be allocated in the time domain for data transmission from the ONU to the OLT for each traffic class, represented by T-CONTS (1402), (1403), (1404), (1405) for ONU 1 (1413); and other T-CONT (1406), (1407), (1408), (1409) for ONU n (1414), which have logical port identifiers represented by Alloc-ID. This bandwidth allocation mapping is sent in the downlink as described in Figure 10. It is also considered that for flows from different ONUs that are part of the same traffic class (for example 1402 and 1406), the DBA algorithm will consider a scheduling adopting the Weighted Round Robin algorithm (1420), (1421), (1422), (1423) and it must be deterministic addressing implementations proposed in the literature.Furthermore, the algorithm also takes into account the scheduling of priority traffic determined by the UL scheduler (1415), which in the invention proposed in this document, follows the rules forwarded by the TSN Bridge Controller, which in turn receives the requirements from the TSN network CNC. Thus, returning the communication interface between the OLT and the management layer, or TSN Bridge Controller (1401), a flow resulting from the optical transmission of the PON network following the scheduling rules proposed in the IEEE 802.1 Qbv standard.

[0097]

[0056] Figure 15 presents an example of the 802.1 Qbv processing that each network card implements. The objective of the IEEE 802.1 Qbv scheduler is to separate communication in the Ethernet network into repeating, fixed-length time cycles (1504). Within these cycles, different time intervals can be configured and assigned to one or more of the eight Ethernet priorities (1505). This makes it possible to grant exclusive, but time-limited, use of the Ethernet transmission medium to those classes of traffic that require transmission guarantees and cannot be interrupted (1508), (1509). To this end, IEEE 802.1 Qbv requires that all clocks in all network devices (Ethernet switches and end devices) be synchronized (1503).By establishing virtual communication channels, or VLANs, for specific time periods, time-critical communication can be separated from non-critical background traffic according to the ID (1501), (1502). When an Ethernet interface initiates transmission of a frame onto the transmission medium, this transmission must be completely completed before another transmission can occur (1510). Therefore, the priority ID of the traffic queues is checked (1506), and whether the traffic ID is a priority ID (1507) is verified. If the ID is a priority ID, the traffic is queued (1511). If the ID is a priority ID, the traffic is put on hold (1512). If the scheduler is active (1512), after the end of a traffic stream, it returns to checking the priority ID of the traffic queues (1506). If the scheduler is not active or the traffic ends, resources are cleaned up and released (1513).

[0098] BIBLIOGRAPHICAL REFERENCES

[0099] [1] Norman Finn, “Introduction to Time-Sensitive Networking" , IEEE Communications Standards Magazine, Dez / 2022

[0100] [2] Atiq et al., “When IEEE 802.11 and 5G Meet Time-Sensitive Networking", IEEE Open Journal on Industrial Electronics Society, Jan / 2022

[0101] [3] Adame et al., “Time-Sensitive Networking in IEEE 802. 11 be: On theWay to Low- LatencyWiFi 7”, MDPI Sensors, Jul / 2021

[0102] [4] Gódor et al. , “A Look Inside 5G Standards to Support Time Synchronization for Smart Manufacturing" , IEEE Communications Standards Magazine, Set / 2020

[0103] [5] Kevin B. Stanton, “Distributing Deterministic, Accurate Time for Tightly Coordinated Network and Software Applications: IEEE 802. 1AS, the TSN profile of PTP’, IEEE Communications Standards Magazine, Jun / 2018

[0104] [6] Yu et al., “Industrial PON System Architecture and Applications", 2023 32nd Wireless and Optical Communications Conference (WOCC), IEEE, Mai / 2023

[0105] [7] K. Christodoulopoulos, et al., "Demonstration of Industrial-grade Passive Optical Network,” 2022 Optical Fiber Communications Conference and Exhibition (OFC), Mar / 2022 [8] K. Christodoulopoulos, et al., "Deterministically Scheduled PON for Industrial Applications," 2023 Optical Fiber Communications Conference and Exhibition Mar / 2023

[0106] [9] K. Christodoulopoulos, et al., “ Proof-of-Concept Demonstration of Time Critical Periodic Traffic in Industry-grade Passive Optical Networks", 2022 Optical Fiber Communication Conference (OFC), Mar / 2022

[0107]

[0010] C. Su, J. Zhang and Y. Ji, "Time-aware deterministic bandwidth allocation scheme in TDM-PON for time-sensitive industrial flows," Journal of Optical Communications and Networking, Maio / 2023

[0108]

[0011] X. Li, H. Yang, Q. Yao, B. Bao, J. Zhang and M. Cheriet, "Enhancing Time-Critical Communication for Industrial Applications with Deep Q-Network and Policy Reuse based TDM-PON," 2023 Opto-Electronics and Communications Conference (OECC), Jul / 2023

[0109]

[0012] Talebi Fard et al., “DEVICE CONFIGURATION FOR TIME SENSITVE NETWORK BRIDGE”, USPTO Patent Application (US 2022 / 0046513 A1 )

[0110]

[0013] Sulin Yang, “ETHERNET SERVICE CONFIGURATION DEVICE, METHOD, AND SYSTEM IN PASSIVE OPTICAL NETWORK”, USPTO Patent Application (US 2009 / 0154920 A1 )

[0111]

[0014] David de Pintos, et al., "Software defined networking agent demonstration to enable configuration and management of XGS-PON architectures," J. Opt. Commun. Netw. 2023

[0112]

[0015] "\EEE Standard for Ethernet," in IEEE Std 802.3-2015 (Revision of IEEE Std 802.3- 2012) Mar / 2016

[0113]

[0016] "IEEE Standard for Service Interoperability in Ethernet Passive Optical Networks (SIEPON)," in IEEE Std 1904.1-2013 Set / 2013

[0114]

[0017] "IEEE Standard for Local and Metropolitan Area Networks-Timing and Synchronization for Time-Sensitive Applications," in IEEE Std 802.1AS-2020 (Revision of IEEE Std 802.1AS-2011 ) Ju / 2020

[0115]

[0018] TU-T, R. G.988. ONU management and control interface (OMCI) specification, Nov / 2017

Claims

CLAIMS 1) METHOD for configuring bridge in time-sensitive networks, or TSN, using passive optical network components, or PON (100), characterized by: a) Abstracting PON components, among these OLT (101) and ONU (102), (103), (104) to function as TSN bridge ports (107), (108), (109), (110), including time synchronization and traffic scheduling functionalities; b) Implementing time synchronization of the components (101), (102), (103), (104) of the PON network (100) using IEEE 802.1 AS or gPTP, and outgoing traffic scheduling of the components of the PON network (100) following the YANG data model of the IEEE 802.1 Qbv protocol; and c) Configure TSN network filters and policies on outgoing traffic in PON components (101), (102), (103), (104), for access management and traffic priority in TSN flow sessions. 2) Interconnection SYSTEM for TSN networks using PON network components (100) for implementing the method of claim 1, characterized by: a) Incorporating time synchronization means into the ITU-T PON components (101 ), (102), (103), (104), based on IEEE 802.1AS or gPTP, for alignment of TSN data transmissions; b) Processing units to adapt IEEE TSN standards to ITU-T PON systems, ensuring harmonized operation and optimized traffic shaping; c) Communication interfaces between the TSN network controller and PON components (101 ), (102), (103), (104), to allow dynamic configuration and management of TSN traffic; and d) Implement a real-time monitoring system to evaluate the efficiency of traffic scheduling and the quality of time synchronization. 3) TSN network management system for interconnection with PON network components (100) according to claim 2, characterized by: a) A TSN bridge control module (106) integrated with a centralized network controller (CNC), for the management of TSN flow sessions and dynamic configuration of the PON network (100); and b) Programmable communication interfaces between the TSN bridge controller (106) and the PON components (101), (102), (103), (104), ensuring automatic adaptations to TSN traffic demands and time synchronization. 4) METHOD for integrating PON components (101), (102), (103), (104) in a TSN network environment, according to claim 1, characterized by: a) Establishing a control plane communication interface between PON components (101), (102), (103), (104) and the TSN network controller (106), including the centralized network controller (CNC); b) Implementing an abstraction system for treating PON links and components (101), (102), (103), (104) as elements of a TSN bridge (107), (108), (109), (110), with abstracted logical port configurations; and c) Establishing advanced time synchronization mechanisms in the PON components, in compliance with IEEE 802.1 AS or gPTP 5) METHOD for configuring components (101), (102), (103), (104) of PON networks (100) as ports of a TSN Network, according to claims 1 and 4, characterized by: a) Establishing an abstraction of PON components (101), (102), (103), (104) as TSN bridge ports (107), (108), (109), (110), including logical and physical adaptation to support TSN functionalities; b) Implementing a time synchronization system in PON components (101), (102), (103), (104) according to IEEE 802.1 AS or gPTP standards; and c) Configuring and managing TSN traffic over the PON network (100), using specific protocols for traffic scheduling and QoS management. 6) METHOD for configuring TSN flow sessions in TSN networks, according to claim 1, characterized by: a) Receiving configuration commands at the control plane interface between a centralized network controller (CNC) and a TSN bridge controller (106); b) Translate the TSN bridge configuration requests (106) received from the centralized network controller (CNC) into network configurations applicable to the PON components (101), (102), (103), (104), establishing the basis for the detailed configuration of the TSN flow sessions; c) Establish and manage TSN flow sessions in the network, coordinating the resource reservation and link configuration, which are fundamental for the detailing and effective implementation of the downlink and uplink flow strategies. 7) METHOD for configuring TSN flow sessions, according to claim 6, characterized by: a) Receiving TSN flow configuration requests from a TSN terminal node (115), (116), in the centralized user controller (CUC), and transmitting them to the centralized network controller (CNC); b) Processing the TSN flow requests in the centralized network controller (CNC) to determine the feasibility and the necessary parameters for the flow session; c) Configuring the TSN bridges in the network (105), including those that integrate passive optical network components, to establish the TSN flow session according to the received parameters, to ensure cohesion in the TSN flow configuration. 8) METHOD for configuring TSN flow sessions traveling in downlink in PON networks (100), according to claim 7, characterized by: a) Establishing specific QoS parameters for TSN traffic and associating them with traffic classes in the PON network (100); b) Implementing, through a TSN bridge controller (106), the traffic configuration in the PON network (100), adapting the parameters of the PON network (100) to meet the TSN traffic requirements; and c) Transmitting TSN traffic over the PON network (100), respecting the QoS configurations and ensuring delivery according to the parameters established by the TSN traffic. 9) METHOD for configuring TSN flow sessions traveling in uplink in PON networks (100), according to claim 7, characterized by: a) Receive TSN traffic parameters from the centralized network controller (CNC) for uplink data flow transmission, b) Configure TSN traffic parameters on the OLT (101) of the PON network (100), adapting the PON network (100) to support TSN traffic requirements, including dynamic and deterministic bandwidth allocation; and c) Transmit uplink data flow from the ONU (102), (103), (104) to the OLT (101), following the QoS and traffic scheduling configurations established to meet the needs of the TSN flow session. 10) METHOD for transmitting TSN port configuration information (107), (108), (109), (110) in PON networks (100), according to claim 1, characterized by: a) Creating and integrating an OMCI management framework for controlling PON networks (100) within a TSN network; and b) Transmitting and implementing scheduling and clock synchronization parameters from the centralized network controller (CNC) to the TSN bridge controller (106), ensuring compatibility in TSN data transmission. 11) METHOD for periodically updating the capabilities of TSN bridges (105) in TSN networks, according to claim 1, characterized by: a) Receiving requests for information about capabilities of the TSN bridge in the TSN bridge controller (106) in the control plane, originating for example, but not limited to, a centralized network controller (CNC); and b) Compiling and returning information about capabilities of the TSN bridge (106) to the centralized network controller (CNC), providing an updated database for continuous optimization and dynamic adjustments in the configuration of the TSN network.

Images