WO2014153109A2

WO2014153109A2 - Network bridging with qos

Info

Publication number: WO2014153109A2
Application number: PCT/US2014/029102
Authority: WO
Inventors: Zong Wu
Original assignee: Entropic Communications, Inc.
Priority date: 2013-03-14
Filing date: 2014-03-14
Publication date: 2014-09-25
Also published as: WO2014153109A3

Abstract

Systems and methods of bridging a first access network using a FDD scheme running on a first physical medium, with a second network using a TDD or FDD scheme running on a second physical medium are presented in which a network controller (NC) of the second network is physically connected to the first network, and can generate a virtual node for each network node on the second network, such that the network nodes on the second network can be scheduled by a scheduler of the first network as if they were regular network nodes on the first network. The bridge intercepts the schedule messages intended to the virtual nodes, keeps the schedule for upstream transmission on the first network, and creates a corresponding schedule for the network node on the second network.

Description

NETWORK BRIDGING WITH QoS

Technical Field

[0001] The disclosed technology relates generally to network communications, and more particularly, some embodiments relate to systems and methods for network bridging with QoS considerations.

Description of the Related Art

[0002] A local network typically includes several types of devices configured to share information across the network. For example, one type of local network can be configured to deliver subscriber services throughout a home, office or other like environment. These subscriber services can include delivering multimedia content, such as streaming audio and video, to devices located throughout the location. As the number of available subscriber services has increased and they become more popular, the number of devices being connected in the home network has also increased.

[0003] The network of FIG. 1 is one example of a multimedia network implemented in a home or office. In this example, a wired communications medium 100 is shown. The wired communications medium might be a coaxial cable system, a power line system, a fiber optic cable system, an Ethernet cable system, or other

.. i- similar communications medium. Alternatively, the communications medium might be a wireless transmission system. As one example of a wired communication medium, with a Multimedia over Coax Alliance (MoCA ) network, the communications medium 100 is coaxial cabling deployed within a residence 101 or other environment. The systems and methods described herein are often discussed in terms of this example coaxial network application, however, after reading this description, one of ordinary skill in the art will understand how these systems and methods can b implemented in alternative network applications as well as in environments other than the home.

[0004] The network of FIG. 1 comprises a plurality of network nodes 102, 103, 104, 105, 106 in communication according to a communications protocol. For example, the communications protocol might conform to a networking standard, such as the well-known MoCA standard. Nodes in such a network can be associated with a variety of devices. For example, in a system deployed in a residence 101, a node may be a network communications module associated with one of the computers 109 or 110. Such nodes allow the computers 109, 110 to communicate on the communications medium 100. Alternatively, a node may be a module associated with a television 111 to allow the television to receive and display media streamed from one or more other network nodes. A node might also be associated with a speaker or other media playing devices that plays music. A node might also be associated with a module configured to interface with an internet or cable service provider 112, for example to provide Internet access, digital video recording capabilities, media streaming functions, or network management services to the residence 101. Also, televisions 107, set-top boxes 108 and other devices may be configured to include sufficient functionality integrated therein to communicate directly with the network.

[0005] With the many continued advancements in communications technology, more and more devices are being introduced in both the consumer and commercial sectors with advanced communications capabilities. Many of these devices are equipped with communication modules that can communicate over the wired network (e.g., over a MoCA Coaxial Network) as well as modules that can communicate over fiber or other networks as well. Indeed, in many environments, it is becoming more commonplace for there to be multiple networks, and sometimes multiple different networks, across which a user may wish the network devices to communicate. In such circumstances, network bridges can be used to allow devices to communicate across multiple networks.

[0006] Network bridging is a technique for allowing two or more communication networks or network segments to be aggregated. In some cases, the aggregated segments can be combined to form a virtual network. Bridging typically relies on a network bridge to connect the multiple networks or network segments. The network bridge can be configured to bridge the protocols between the two segments or networks, allowing devices on one network to communicate with devices on the other networks, despite differences that may exist in specifications of their respective MAC or PHY layers. That is, network bridging can be used to aggregate networks of the same type as well as aggregate disparate networks.

[0007] Bridges typically principally operate at Layer 2 of the OSI reference model (the data link layer). Accordingly, bridging can occur at the data link layer and a bridge can be used to control data flow between the networks, and manage access to the physical layer. Accordingly, bridging can be used to provide interface between disparate networks, and to connect separate networks or network segments. More particularly, bridging can be used to allow a network node on one network to communicate with other network nodes on a different network. Conventional bridges analyze incoming data frames and determine how to route those frames based on information within the frames. Typically, the bridge determines the destination of packets by examining network traffic received on the links attached to the bridge.

Brief Summary of Embodiments

[0008] According to various embodiments of the disclosed technology, systems and methods for bridging two networks are provided. In various embodiments, an EPON frequency-division duplexing (FDD) access network may be bridged with a time division duplexing (TDD) coax-based access network, although other networks or network segments can be bridged. [0009] This disclosure describes the particular cases where the two networks to be bridged are both access networks. An access network has a point-to-multipoint topology, which has one headend (Point) and multiple client nodes (Multiple- Points), where the headend can talk to all the client nodes, while each client node is only allowed to talk to the headend, with the headend controlling the access to the comm unication medium. The two example access networks used in this disclosure are the standard fiber-based EPON (including 10G or other speed versions) network and a coax-based access network. The two example networks used are for illustration only, and the methods, bridge and network devices, and the systems described herein can be used for other networks.

[0010] Accordingly, in some embodiments, the two networks may be connected with each other through an optical-to-coax bridge device (OCB. Note that the terms OCU and OCB are used interchangeably), such that each network operates concurrently while the whole network can be provisioned and managed with a unifying system, and the optical line termination's (OLT's) scheduler works as if all the coax nodes in the coax-based system are optical network units (ONUs).

[0011] An EPON access network is an FDD system where downstream traffic (e.g., from an optical line termination (OLT) to an optical network unit (ONU)) is continuous broadcast traffic, and upstream traffic occurs in bursts. The bursts are transmitted by the various ONUs at specified time slots as scheduled by the OLT. On the other hand, a coaxial cable-based access network is a network that can be either an FDD or TDD network. Accordingly, a bridging device, referred to herein as a optical-to-coax Unit (OCU), can be provided to bridge the two networks. I some embodiments, the OCU is configured to include at least one physical ONU port and at least one physical coax port, such that it can connect an EPON network with a coax network. In some embodiments, a large access network can be formed where multiple OCUs are used, each bridging a coax network to the same EPON network.

[0012] In some embodiments, in an EPON FDD network, the OLT is designed to schedule all the upstream traffic for all the ONUs (real and virtual/logic), while the EPON downstream is generally broadcast to all the nodes. The bridge device (e.g., the OCU) can be configured to intercept the FDD schedule from the OLT for the coax nodes, and use the FDD schedule to create a TDD schedule for both the upstream and the downstream traffic of the coax nodes.

[0013] A representative exemplary embodiment of EPON network + Coax network can include an OLT, one or more ONUs, and optionally one or more OCUs. The OCU can be configured to include two types of port: an ONU port and a coax port. Relative to the OLT, each OCU behaves as multiple, standard ONUs, such that if there are M cable network units (CNUs) in the coaxial network, the OCU appears to the OLT as M virtual ONUs in the EPON.

[0014] According to various embodiments of the disclosed technology, a bridged network system and method includes a first network using an FDD scheme, and including a headend and one or more physical network nodes communicatively coupled to the headend, wherein the headend is configured to perform the operation of scheduling node traffic on the first network and send schedule messages to schedule network resources; a second network with a network controller (NC) and one or more physical network nodes communicatively coupled to the C, wherein the NC is configured to schedule node traffic on the second network; and a bridge having a first port communicatively coupled to the first network, a second port comprising the NC of the second network, in which the bridge is configured to perform the operations of: intercepting schedule messages sent by a headend of the first network to designated virtual nodes, wherein each schedule message includes an indication of granted timeslots for upstream packets to be sent by the corresponding designated virtual node on the first network; creating a new schedule messages for the physical nodes on the second network based on the intercepted schedule messages, and sending the new schedule messages to their respective corresponding physical nodes on the second network, wherein when the granted timeslots occur, the physical nodes send corresponding granted packets at the granted time; and receiving the corresponding granted packets from the physical nodes and forwarding the received granted packets to the headend of the first network at the original scheduled time.

[0015] Other features and aspects of the disclosed technology will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate, by way of example, the features in accordance with embodiments of the disclosed technology. The summary is not intended to limit the scope of any inventions described herein, which are defined solely by the claims attached hereto.

Brief Description of the Drawinis

[0016] The technology disclosed herein, in accordance with one or more various embodiments, is described in detail with reference to the following figures. The drawings are provided for purposes of illustration only and merely depict typical or example embodiments of the disclosed technology. These drawings are provided to facilitate the reader's understanding of the disclosed technology and shall not be considered limiting of the breadth, scope, or applicability thereof. It should be noted that for clarity and ease of illustration these drawings are not necessarily made to scale.

[0017] Figure 1 is a diagram illustrating one example of a home network environment with which the systems and methods described herein can be implemented.

[0018] Figure 2 is a diagram illustrating an example of a coax cable-based access network with which embodiments of the technology disclosed herein can be used.

[0019] Figure 3 is a diagram illustrating an example of an EPON system with which embodiments of the technology disclosed herein can be used. [0020] Figure 4 is a diagram illustrating an example using an OCU to bridge the example fiber and coaxial networks illustrated in figures 2 and 3.

[00211 Figure 5 is a diagram illustrating an example of a non-pipelined Gate- Data/Report seq uencing in accordance with one embodiment of the technology disclosed herein.

[0022] Figure 6 is a diagram illustrating an example of a pipelined Gate- Data/Report seq uencing in accordance with one embodiment of the technology disclosed herein.

[0023] Figure 7 is a diagram illustrating an exam ple of non-pipelined sequencing of a Coupled Gate - Data/Report transaction on the aggregated fiber and coax networks in accordance with one embodiment of the technology described herein.

[0024] Figure 8 is a diagram illustrating an example of pipelined sequencing of a Coupled Gate - Data/Report transaction on the aggregated fiber and coax networks in accordance with one embodiment of the technology described herein.

[0025] Figure 9 is an operational flow diagram illustrating an example process for this sequencing in accordance with one embodiment of the technology described herein.

[0026] Figure 10 illustrates an example of time sequences of downstream and upstream packets in an EPON FDD + coax TDD configuration. [0027] Figure 11 is a diagram illustrating time sequences of downstream and upstream packets in an aggregated EPON FDD + coax FDD configuration,

[0028] Figure 12 is a diagram illustrating an example of transmission scheduling on the fiber segment and the coax segment.

[0029] Figure 13 is a diagram illustrating an example of sequencing of a transaction on the aggregated fiber and coax networks in accordance with one embodiment of the technology described herein.

[0030] Figure 14 is an operational flow diagram illustrating an example process for this sequencing in accordance with one embodiment of the technology described herein.

[0031] Figure 15 illustrates an example computing module that may be used in implementing various features of embodiments of the disclosed technology.

[0032] The figures are not intended to be exhaustive or to limit the invention to the precise form disclosed. It should be understood that the invention can be practiced with modification and alteration, and that the disclosed technology be limited only by the claims and the equivalents thereof.

Detailed Description of the Embodiments

[0033] The technology disclosed herein is directed toward systems and methods for bridging various networks or network segments. From time to time, the disclosure provided herein is described in terms of bridging an EPON frequency- division duplexing (FDD) access network with a time division duplexing (TDD) coax- based access network. After reading this description, one of ordinary skill in the art will understand how the technology disclosed herein can be applied to bridging of other networks or network types. Particularly, the technology is disclosed in terms of systems comprising an EPON FDD network, one or multiple coax networks, and one or multiple EPON to coax network bridging units (OCU) that connect the two networks together. In this document, the EPON network is also referred to as an EPON segment (or fiber segment), the coax network is also referred to as a coax segment, and the whole network is referred to as a network or a system.

[0034] Figure 2 is a diagram illustrating an example of a coax-based access network with which embodiments of the technology disclosed herein can b used. The example coaxial cable-based access network 200 shown in figure 2 comprises a head-end (coax access network controller) 204 located at/towards the service provider's office, and M CNUs 206, which may be located at the customers' premises.

[0035] Figure 3 is a diagram illustrating an example of an EPON system with which embodiments of the technology disclosed herein can be used. The EPON network comprises an OLT 302 connected by an optical fiber link 304 to a plurality of N ONUs 308. An optical splitter 306 is provided to allow an optical fiber interface to the N ONUs 308. As illustrated in the example EPON system 300, full duplex communication can be provided by wave division multiplexing such that upstream and downstream traffic can be communicated using different wavelengths. Accordingly, as illustrated in this example, OLT 302 includes a transmitter module Tx, a receive module Rx, and the wave division multiplexer WDM. OLT 302 is also illustrated as including medium access logic module 310 to handle the MAC layer functionalities.

[0036] Given the existence of these two networks (i.e. the coax-based network, and the fiber-based EPON network), there are scenarios in which users may wish to aggregate these networks. For example, consider scenarios in which a multiple service operator (MSO) wants to deploy a standard OLT, and also wants to install ONUs so that the MSO can connect to its customers via optical fiber. However, further consider a scenario in which some of the MSO's customers cannot be reached with or are not connected by optical fiber. In such scenarios, the MSO may want to deploy a converter between the optical fiber and the coax network so that the MSO can use the same standard OLT 302, and use CNUs 206 for those customers attached to the coax network.

[0037] Accordingly, situations may arise in which the network operator (e.g. the MSO) wants to: (1) use the same OLT 302 for both types of customers (those who are reachable through optical fiber, and those who are reachable only through coaxial cable or HFC); and (2) use a pass-through device that will pass data between the OLT 302 and the CNU 206, in which the pass-through device is flexible enough to allow the MSO to use different portions of the RF spectrum on coax, including more and less spectrum as available.

[0038] Additionally, in some applications, it is desirable for the OLT 302 that the behavior of a CN U be functionally equivalent to the ONU 308 so that major changes to the OLT 302 are not required. The OLT 302 is preferably able to manage CN Us 206 in the same way as it manages ON Us 308. Furthermore, in some embodiments, a standard governing how such a pass-through device and the CN Us 206 works to allow interoperability between different vendors.

[0039] These and other bridging scenarios can be accomplished using an optical-to-coax Unit (OCU) 404 as a bridging module between two networks. Figure 4 is a diagram illustrating an example using an OCU 404 to bridge the example fiber and coaxial networks illustrated in figures 2 and 3. Referring now to figure 4, it can be seen in this example that an OCU 404 is provided and connected to one of the ports of optical splitter 306. In this example, OCU 404 includes the functionality of access network controller 204, and also includes an ONU port 406. Accordingly, OCU 404 is configured to be capable of communicating with the optical network's OLT 302 via optical splitter 306 and with the coax network units (CNUs) 206 of the coax network as it is the coax access network controller 204. To enable the network's OLT 302 to address individual CNUs 206, OCU 404 can be configured to provide a mapping between each CNU 206 and a corresponding virtual ONU. As illustrated in figure 4, OCU 404 establishes M virtual ONUs, labeled as vONU-1 through vONU-M 408, In other words, in this example, there is one virtual ONU corresponding to each CNU 206 desired to be connected to or addressed by the OLT. Mapping chart 418 illustrates an example of this mapping.

[0040] Relative to the standard OLT, the OCU's ONU port 406 in this example embodiment behaves as M virtual ON Us 408 (sometimes referred to herein as vON Us 408), each with one or multiple LLIDs (Logical Line Identification ), where M is the number of CN Us 206 to be accommodated in the coaxial cable access network 200. The system can be configured such that ranging between the OLT 302 and each CN U 206 actually terminates at the ONU port 406 of the OCU 404. The ranging between the OCU 404 and each CN U 206 is local to the coax segment, and may be used by the OCU 404 when it performs schedule translation (described below).

[0041] For network provisioning and management, DOCSIS Provisioning of EPON (DPoE) can be used directly. (DOCSIS refers to Data Over Cable Service Interface Specification). The OLT 302 considers the CN Us 206 as if they are standard ONUs 308. For whatever operations that the OLT 302 does on each CNU 206, the OCU 404 will pass them to the CNU 206, and CNU 206 Reports are also passed to the OLT 302.

[0042] As this example illustrates, an OCU 404 configured in this manner can be implemented to dissociate the optical fiber network segment and the coaxial cable network segment, allowing the two disparate networks to be aggregated and operate concurrently. The OLT scheduler (part of the OLT module 302) does not need to distinguish CNUs 206 from standard ONUs 308. Also, with various embodiments there need not be a constraint on wire speed for either of the two- network segments. The queue buffers in the OCU 404 can be implemented in various ways depending on the number of CNUs 206 supported, and the speed, throughput, and latency of the coaxial cable access network. The service flow QoS (Quality of Service) c n be performed by the OLT 302 based on service level agreement (SLA) as in regular access system.

[0043] As described above, the OCU 404 in various embodiments performs transaction translation between fiber and coax, and all MAC control messages to the CNUs 206 are intercepted by the OCU 404. The system can be configured such that all Downstream (DS) and Upstream (US) traffic between the OLT 302 and the CNUs 206 is first scheduled by the OLT 302 as if CNUs 206 are regular EPON ONUs 308. The OCU 404 may be configured to translate the FDD schedule into TDD schedule for the CNUs 206. A CNU 206 can receive all the control messages (e.g. Gate, Register) and data packets targeted to it from the OLT 302. The OLT 302 can receive all the control messages (e.g. Report. Register-Request, Register-Ack) and data packets targeted to it from each CNU 206. However, control messages are preferably translated by the OCU 404.

[0044] In various embodiments, a CNU 206 implements the functionalities of the Multi-Point Control Protocol (MPCP) of the EPON network within a CNU node's Data Link Layer, just above the CNU's technology-specific (i.e. coax network) MAC layer. Examples of a MAC layer for a coaxial network include the oCA MAC and the c.LIN MAC. In an EPON + Coax network in which the CNU 206 supports the functionalities of the M PCP, the translation task on the M PCP control messages by the OCU 404 can be less complex than in the case where the CNU 206 does not support the functionalities of the MPCP, but only its technology-specific (i.e. coax network) MAC layer.

[0045] Each CN U 206 is admitted into the EPON network as if it is a regular ONU 308, through the sequence of Register-Request (CN U 206 to OLT 302), Register (OLT 302 to CN U 206), Register-Ack (CN U 206 to OLT 302). Each CN U 206 is assigned a link-layer identification (LLID) as a regular ONU 308.

[0046] The OLT 302 does FDD scheduling for all traffic between the OLT 302 and ON Us 308 and CNUs 206. The OLT's 302 scheduler can determine the range between it and each ONU 308 and CNU 206. For ranging purposes, the range between the OLT 302 and a given CN U 206 is virtualized as the range between the OLT 302 and the OCU 404. In fact, all CNUs 206 on the same coax network managed by the OCU 404 can be proxied by the OCU 404.

[0047] The OCU 404 in various embodiments uses a buffer for upstream traffic between a CNU 206 and the OLT 302, and the OCU 404 can be configured to make sure that all upstream traffic from a given CNU 206 has a same delay between the OCU 404 and the OLT 302, such that from the OLT 302's viewpoint, each CNU 206 behaves exactly as an ON U 308, and has a constant upstream delay between the CNU 206 and the OLT 302,

[00481 The OLT's 302 US schedule for CNUs 206 can be contained in Gate messages from the OLT 302, The OCU 404 can intercept these messages and translate the schedule for CN Us 206. The same information may also be used by the OCU 404 to schedule DS traffic on the coax segment. The remaining time-slots on the coax segment can be used by the OCU 404 to schedule local coax network specific operations like link control/maintenance to optimize the coax network.

[0049] There is thus two-layered scheduling in various embodiments. For example, the OLT 302 schedules all the traffic on the fiber segment, and when doing this it considers CNUs 206 as regular ONUs 308. The OCU 404 intercepts the schedule for CN Us 206 from the OLT 302, and uses it to generate a TDD schedule for the CNUs 206 on its coax network. There may be a tight coupling in timing between the fiber segment and the coax segment.

[0050] Due to the potential long latency on the coax segment, the OLT 302 schedule can choose to either schedule non-overlapping traffic on the two segments for simplicity, or schedule concurrent/overlapping transmissions on both fiber and coax segments for better performance, by using the Gate to Report/Data turnaround time when making the scheduling.

[0051] The EPON Gate - Report - Gate - Data sequencing may be coupled across the OCU 404, meaning that a control message can be propagated from the OLT 302 to the OCU 404 to the CNU 206, and in the reverse direction. The OLT's 302 polling interval can determine the upstream latency of a given CNU 206.

[0052] Thus, in various embodiments, the system is an end-to-end system in the sense that the OLT 302 communicates all control and data messages with each CN U 206 as if it is an ONU 308, although the OCU 404 change/updates the content and the format of control messages to be compatible with the coax network protocol or specifications.

[0053] In further embodiments, the EPON Gate - Report - Gate - Data sequencing may be decoupled by the OCU 404, meaning the OCU 404 terminates such seq uencing relative to the OLT 302 by being a proxy for each CN U 206, and acts as an OLT 302 for all the CNU 206s on its coax segment. The OCU 404 thus splits an original control transaction into two steps. In some embodiments, the coax segment does not support the MPCP protocol, but only its own technology-specific MAC, such as the MoCA or c.LINK MAC. In such cases, the cGate message can be used to represent the MAP (Medium Access Plan) message, and cReport message is used to represent the Reservation Request message. A cGate message may be equivalent to an aggregate of one or multiple Gate messages for multiple nodes. Thus, cGate and cReport messages are different from the MPCP's Gate and Report messages.

[0054] In such embodiments, a CNU 206 can be configured to receive all the data packets (including all network management messages that are not MPCP, e.g. DPoE or Ethernet Operation, Administration and Management -OAM messages) targeted to the CNU 206s from the OLT 302 through the OCU 404, The OLT 302 receives all the data packets (including all network management messages that are not MPCP) that are targeted to the OLT 302 from each CN U 206 through the OCU 404. All Control messages, including both MPCP and network management messages li ke DPoE and OAM, from the OLT 302 to each CN U 206, may be consumed by the OCU 404 and also updated and then forwarded to the CNU 206. All Control messages, including both M PCP and network management messages like DPoE and OAM, from each CN U 206 to OLT 302, may be consumed by the OCU 404 and also updated and then forwarded to the OLT 302.

[0055] Each CNU 206 is admitted into the EPON network as if it is a regular ONU 308. First a CNU 206 is admitted into its coax network through the admission process used by the coax network and managed by the coax network controller (ANC 204). The OCU 404 then creates a virtual ONU and starts the admission process for this virtual ONU, in the same way as for a regular ONU 308. This can be done through the sequence of Register-Request (virtual ONU vONU-x 408 to OLT 302), Register (OLT 302 to vONU-x 408), Register-Ack (vONU-x 408to OLT 302). Each vONU-x 408 is assigned an LLID as a regular ONU 308.

[0056] The OLT 302 can perform FDD scheduling for all traffic between the OLT 302 and ONUs 308 and CNUs 206. The OLT's 302 scheduler can determine the range between it and each ONU 308 and CNU 206. For ranging purpose, the range between the OLT 302 and a given CNU 206 is virtualized as the range between the OLT 302 and the corresponding virtual ONU in the OCU 404, All CNU 206s on the same coax network managed by the OCU 404 may be proxied by the OCU 404, The OCU 404 has a set of buffers for each CNU 206 for both upstream and downstream traffic.

[0057] The OCU 404 can be configured to use a buffer for upstream traffic between a CN U 206 and the OLT 302 and to ensure that all upstream traffic from a given virtual ON U-x 408 have a same delay between the OCU 404 and the OLT 302, such that from the OLT 302's viewpoint, each vON U-x 408 behaves exactly as an ON U 308, and has a constant upstream delay between the vON U-x 408 and the OLT 302.

[0058] The OLT 302's US schedule for vON U-x 408 is contained in Gate messages from the OLT 302. The OCU 404 intercepts these messages and uses them to generate upstream transmissions as granted in the Gate messages. In the meantime, the OCU 404 aggregates these M PCP Gate messages and uses them to create coax-network-specific schedule information (like the MAP in MoCA) for the corresponding CN Us 206. This new scheduling can be independent of the original schedule from the OLT 302. This gives the OCU 404 flexibility in its scheduling for the CNU 206s. The remaining time-slots on the coax segment can be used by the OCU 404 to schedule local coax network specific operations like link control/maintenance to optimize the coax network. [0059] There is thus two-layered scheduling: the OLT 302 schedules all the traffic on the fiber segment, and when doing this it considers vONUs 408 (e.g., each vONU 408 representing and corresponding to one CNU 206) as regular ONUs 308. The OCU 404 intercepts the schedule for vONUs 408 from the OLT 302, and uses it to generate a TDD schedule for the CNUs 206 on its coax network if the coax network uses TDD. If the coax network uses FDD but with different throughput than the EPON, then the OCU 404 intercepts the schedule for vONUs 408 from the OLT 302, and uses it to generate an updated FDD schedule for the CNUs 206 on its coax network. Accordingly, the OCU 404 can be implemented to effectively isolate the timing between the fiber and the coax, and there may be concurrent /overlapping transmissions on both fiber and coax.

[00601 The OLT's 302 polling interval on EPON on a given vONU-x 408 and the OCU 404 polling interval (or MAP interval) on the coax network on a given CNU 206 together determine the upstream latency of a given CNU 206. The OLT 302 and the OCU 404 may use the same or different polling interval value.

[0061] The system is an end-to-end system in the sense that the OLT 302 can exchange the network management messages (except MPCP-specific) with CNU 206 as if it is an ONU 308, and all data messages (including network management messages like DPoE and OAM) are end-to-end. However, in various embodiments the OCU 404 intercepts the content of MPCP control messages and uses this content to generate coax network specific scheduling, management, and control. [0062] EPON systems, such as the Example EPON system 300, use Gate and Report messages to allow the ONUs 308 to report the packets they have for transmission upstream, and the OLT 302 to grant an appropriate amount of time to the ON Us 308 to transmit these packets. Generally, an ON U 308 accumulates packets over time, generates Report messages and sends them to the OLT 302 when polled by the OLT 302. Depending on the QoS parameters (may be defined through a Service Level Agreement) for a given service flow of an ON U 308, the OLT 302 grants the appropriate amount of transmission time over an appropriate time interval. Note that each Report can be configured to contain the current status of packet queues, regardless of whether some of the packets have already been reported in previous Report messages. The OLT 302 can be configured to keep track of its own version of the current status of packet queues for each ON U 308. The OLT may grant only part of the reported packets for each ONU 308.

[0063] Gate - Report - Gate - Data/Report sequencing can be singled- threaded (non-pipelined) or pipelined. Figure 5 is a diagram illustrating an example of a non-pipelined Gate-Data/rRport sequencing in accordance with one embodiment of the technology disclosed herein. Figure 5 also shows upstream latency from an ONU 308 to an OLT 302 in accordance with various embodiments. In the example illustrated in figure 5, the OLT (e.g., OLT 302) sends the first gate message Gate(Rep) 502. Gate(Rep) 502 includes the scheduled time-slots for the ONU to report its queue status. In response, ONU 308 transmits Rep(PAl) 504, which includes the queue status about the accumulated upstream packets to be sent.

[0064] After a delay time as illustrated by Gate to Data/Rep cycle 503 in figure 5, OLT 302 receives Report Rep(PAl). In response to receipt of Report Rep(PAl), OLT 302 sends the Gate message 506, which contains the scheduled time- slots for upstream packets reported in Report Rep(PAl). With the timeslots scheduled for upstream packets, at the appropriate time, ONU 308 transmits the upstream packets, with Report Rep(PA2) piggybacked). This is illustrated at 508.

[0065] The process can repeat for subsequent packets as illustrated at 510 and 512. In this example, the packets accumulated in the packet accumulation interval PA2 are Reported to the OLT 302 as Piggyback Rep(PA2) on data packet data(PAl), as shown at 508. The OLT 302 schedules these packets for a later time, and the ONU 308 sends the data packet as Data(PA2) with Piggyback Report for PA3 as shown at 512.

[0066] In this example, the minimum latency can be determined as the last packet in a Packet Accumulation interval, which is the Pulling Interval 522 plus the Gate Advance Time (defined as the time interval from when the Gate message is received by the ONU 308 to when the upstream packet transmission is scheduled to start, corresponding to Gate to Data/Rep cycle minus the two wire delays from OLT 302 to ONU 308 and from ONU 308 to OLT 302) plus the fiber wire delay. The maximum latency can be determined as the first packet in a Packet Accumulation Interval, which is equal to twice the Pulling interval 522, plus the Gate Advance Time, plus the fiber wire delay.

[0067] Figure 6 is a diagram illustrating an example of a pipelined Gate- Data/Report sequencing in accordance with one embodiment of the technology disclosed herein. Figure 6 also shows the upstream latency from an ONU 308 to the OLT 302. The pipelining allows the OLT 302 to reduce the Pulling Interval 622 for a given ONU 308 without putting stringent requirements on the internal processing timing and speed of the ONU 308 and OLT 302.

[0068] As seen in the example of figure 6, the OLT (e.g., OLT 302) first sends a Gate message 602 to ONU 308. In this example, Gate message 602 includes a request for the ONU 308 to report its transmit queue status (i.e. what packets it has accumulated for transmission upstream).

[0069] In response, the ONU 308 transmits the upstream packets at the scheduled timeslots, with report I piggybacked or included in the transmission. This is shown at 604. In the meantime, without waiting to receive report I at 604, the OLT 308 sends the gate message 1+1 606 including the scheduled time-slots for upstream packets reported in report 1-1 or earlier. In response, the ONU 308 transmits the upstream packets granted for transmission, with Report Rep(PA2) piggybacked as shown at 608. Again, without waiting for the Report at 608, OLT 308 sends the next gate message at 610. This continues as illustrated in this example at 612-620. [0070] Different packets in an ONU 308 may be available at different times. The ON U 308 accumulates packets to transmit. When they are accumulated in the transmit queues, and are contained in a same Report, they will show a different network latency. The OLT 302 regularly polls the ONU 308 to see what packet data the ON U 308 has to transmit. This is done by having the Gate message's report bit set to ON . The OLT 302 schedules grants to the ON U 308 with Gate messages. For latency-sensitive flows and for purposes of handling QoS scheduling, the OLT 302 can be configured to regularly schedule a gate message to grant requested time and pull for new packets to transmit.

[0071] Figure 7 is a diagram illustrating an example of non-pipelined sequencing of a Coupled Gate - Data/Report transaction on the aggregated fiber and coax networks in accordance with one embodiment of the technology described herein. Figure 8 is a diagram illustrating an example of pipelined sequencing of a Coupled Gate - Data/Report transaction on the aggregated fiber and coax networks in accordance with one embodiment of the technology described herein. Figure 9 is an operational flow diagram illustrating an example process for this sequencing in accordance with one embodiment of the technology described herein. This operation is now described according to various embodiments. For clarity of description, this operation is also described in the context of the example systems illustrated in figure 4. After reading this description, one of ordinary skill in the art will understand how this process can be implemented with other bridged Network Systems. [0072] Referring now to figures 4, 7, 8 and 9. At operation 902, upo power- up, CNU 206 requests admission to the coax network, and gets admitted. In the meantime, CN U 206 synchronizes its clock to the ANC 204 of the OCU 404.

[0073] At operation 904, after the ANC 204 of the OCU 404 has admitted the CN U 206 into the coax network, the OCU 404 creates a virtual ON U vONU-x (e.g., x corresponding to 1 - M, for M vON Us 408, and representing the network id of the CNU 206 within the coax network), and initiates the ON U admission process to admit the vONU-x 408 into the EPON network.

[0074] At operation 906, ranging is done between the OLT 302 and each CNU 206, with each CNU 206 proxied by its corresponding virtual ONU 408 in OCU 404. In some embodiments, this ranging is taken as the sum of: (1) the range between OLT 302 and OCU 404; and (2) the up-bound Gate to Data/Report turn-around time of the coax segment. In various embodiments, OCU 404 defines this up-bound latency as a coax segment system parameter. Variability of this latency within the coax segment can be handled through buffering in OCU 404. This up-bound Gate to Data/Report turn-around time is called cGR for simplicity. cGR is a function of the system architecture of the coax segment, like duplex mechanism (FDD/TDD) and throughput, and the OCU implementation. cGR can be significant relative to the delay from the OCU 404 to the OLT 302.

[0075] In operation 908, the OLT 302 is modified to be aware of the coax network latency, by increasing the Gate advance time to compensate for latency. In some embodiments, the latency is increased by the push out in gate advance time. This push out 722 is otherwise wasted time if using a standard OLT 302, and can be used in some embodiments for other traffic over the fiber segment, if the OLT is configured to accommodate this. Accordingly, at operation 912, OLT 302 can be modified to be aware of the OCU to CN U latency, and the push-out time can be used for other traffic over the fiber segment, concurrently with traffic on the coax segment. This Push-out time can be determined as 2x coax wire-time + Maximum of CN U packet Rx-Tx turn-around time. For TDD coax, this can be ½ of a Media Access Plan (MAP).

[0076] At operation 910, OLT 302 sends a Gate message 702 to a CNU 206 (which is proxied as a virtual ONU 408 by the OCU 404). The Gate message includes an indication of granted timeslots for upstream packets to be sent by the CNU 206. However, OLT 302 is configured for a fiber network and CNU 206 is a coax network unit. Therefore, at operation 912, OCU 404 intercepts the gate message, performs the mapping (e.g. from a virtual ONU 408 to the corresponding CNU 206), updates the message, reformats it into cGate message 704 and sends it to the appropriate CNU 206 over the coax network.

[0077] At operation 914, the receiving CNU 206 determines the granted timeslots for the upstream packets based on the cGate message. This can be in response to a previous request by the CNU 206 (e.g. through a Report message) that was sent either alone or as a piggyback to a data packet to the OLT 302. When the allotted timeslot time arrives, CNU 206 sends the corresponding granted packets 706 at the granted time.

[0078] At operation 916, OCU 404 receives the packets from C U 206 and buffers them. This can be done, for example, in an internal buffer or data store at OCU 404. The OCU waits until the appropriate time to send the packets to OLT 302.

[0079] In some embodiments, where the single thread, non-pipelined sequencing is used, there is not any concurrent activity on the fiber and on the coaxial segment. Therefore, the single thread, non-pipelined sequencing will show relatively large latency. This scheduling method may also be referred to as non- overlapping scheduling. A modified OLT 302, on the other hand, can allow concurrent activity on the fiber and the coaxial segments by taking advantage of this latency time. To achieve this, in some embodiments the OCU 404 communicates its segment's cGR value, so that the OLT allows the overlapping traffic. This scheduling method is also referred to as the overlapping scheduling method.

[0080] As noted above, the media access control on the coax segment can be either TDD or FDD, depending on the actual network technology of the coax network. For FDD, if the fiber segment and coax segment have the same upstream throughput and the same downstream throughput, the coax FDD (cFDD) US (upstream) schedule is simply a time-shifted version of the fiber FDD (fFDD) schedule. The OLT 302 can use either standard OLT scheduling (non-overlapping fiber and coax traffic) or modified OLT scheduling (overlapping fiber and coax traffic) as described above. The cFDD DS (downstream) schedule is just a time-shifted version of fFDD. For TDD, the cTDD US schedule can be mapped from cFDD with one of at least 2 methods. A first method, OLT 302 can do this mapping and contain the mapped TDD schedule in a Gate message. OLT 302 would first create the FDD US schedule, then map the coax network portion to TDD, and convey it in a gate message. This is somewhat inflexible if the coax is to be optimized (e.g. adaptive bit- loading).

[0081] In a second example methodology, the OCU 404 intercepts Gate messages from OLT 302 for original FDD US scheduling, maps it into TDD, and puts it into cGate messages. CNUs 208 can then use the cGate messages for US scheduling. This is generally more flexible for adaptive OFDM and time-varying throughput on coax. Because OCU 404 now has the US schedule on coax, CNU 208 can do its Link Maintenance Operation (LMO) in time-slots not used by OLT-related traffic (both US and DS). This schedule translation relieves OCU 404 from QoS-related management, and SLA is purely managed by OLT 302.

[0082] Note that for cTDD DS scheduling, it is important to realize that there is no MPCP Gate message for DS in EPON. The OCU 404 accumulates DS packets from the fiber, and sends then on coax. OCU 404 snoops Gate messages from OLT 302 to learn the US schedule, in order to know available time-slots for DS traffic on coax. [0083] Note that DPoE and OAM management message are considered as regular Ethernet data packets by the OCU 404, and are passed through the OCU 404, so the end to end network management is realized.

[0084] Figure 10 illustrates an example of time sequences of downstream and upstream packets in an EPON FDD + TDD-coax configuration. This figure illustrates latency in the case of TDD-coax, and is useful to compare the case in which the coax segment uses FDD vs. TDD. Note that Figure 10 assumes that the coax segment's total (Upstream + Downstream) throughput is twice that of either the upstream or downstream throughput of the EPON. Note that this throughput relationship is only one example used to illustrate a special case for discussion purposes. In this example, Gate Advance Time should be >=½ TDD US/DS (i.e. MAP) cycle, so that OCU 404 knows how much DS traffic from the fiber segment it can group into DS traffic on the coax segment. As can be seen by figure 10, upstream data packets PuX are buffered and accumulated at the CNU Tx buffer 1010 until their allotted timeslots on the coax network scheduled in the cGate message, which is created by the OCU 404 using the Gate messages from the OLT. These packets are first received by OCU 404. The OCU 404 temporarily buffers them, and then sends them out at the allotted timeslots on the fiber segment scheduled in the Gate message by the OLT. Accordingly, the latency of uplink packets includes the coax upstream latency 1012 and OCU US latency. Consider the example of uplink packet Pu6. It is buffered in the CNU transmit buffer 1010 as shown on left hand side of figure 10 and, in this example, appears in the upstream of the fiber FDD network after the coax upstream latency 1012 and OCU upstream latency 1022. On the downstream side, it can be seen that downstream packets, designated by PdX, are affected by the MAP cycle in the coax network. Particularly, because in this example the coax network is a TDD network, the downstream packets cannot be put onto the coax network until the downstream portion of the MAP cycle. Note that OCU 404 determines the downstream portion of the MAP cycle in the coax segment in some embodiments, by (1) aggregating all the Gate messages for the CNUs 206 in the OCU's coax segment from the OLT 302, over a time interval of equivalent to a MAP cycle, (2) calculating the time duration needed on the coax segment for transmitting the corresponding granted data packets, (3) determining the needed time on the coax segment for coax network control operations like link maintenance operation, new coax node admission etc., and (4) finding the remaining time in the MAP cycle. The figure 10 shows a coax segment MAP cycle 1046 comprising packets Pdl-Pd2- Pd3-Pd4-Pd5 (Downstream 1042) followed by Pu6-Pu7-Pu8-Pu9 (Upstream 1044) Accordingly, the maximum OCU downstream latency 1032 and the minimum OCU downstream latency 1034 are illustrated in the example of figure 10.

[0085] Figure 11 is a diagram illustrating time sequences of downstream and upstream packets in an aggregated EPON FDD + FDD-coax configuration. This figure helps to illustrate latency in the FDD-coax case, and is useful to compare coax FDD 1102 vs. TDD. Note that Figure 11 assumes that the coax segment's upstream throughput is the same as EPON FFD's 1100 upstream throughput, and coax segment's downstream throughput is the same as EPON's downstream throughput, so that the OCU presents a identical latency for all upstream packets and for all downstream packets. Also note that the example illustrated in figure 11 is provided for ease of illustration, and the coax segment does not need to have the same throughput as the EPON throughput. When the coax segment has a lower throughput than the EPON, the OLT 302 can use the remaining throughput on the fiber segment for other ONUs 308 or OCUs 404. When the coax segment has a higher throughput than the EPON, the OCU 404 can use the remaining time-slots on the coax segment for other purposes like coax network link maintenance, or just remaining idle.

[0086] As with figure 10, figure 11 shows buffering of upstream packets, PuX, in a CNU transmit buffer 1110, as well as the coaxial upstream latency 1112. This is the latency associated with assigning the packets in their respective available timeslots. Because both networks are FDD networks, the OCU upstream latency 1132 is the packet residence time in the OCU 404. In this FDD-coax configuration, the OCU 404 may adopt either a store-and-forward operation or a pass-through operation. With the store-and-forward operation, the OCU 404 first receives a complete packet from the CNU 206, stores it in the OCU 404, then forwards it to the fiber segment. In the pass-through operation, the OCU 404 first receives and store some bytes of packets from the CNU 206, and then starts to forward them onto the fiber segment. [0087] Figure 12 is a diagram illustrating an example of transmission scheduling on the fiber segment and the coax segment. In this example, the OLT 302 schedules upstream traffic for both ONUs 308 and CNUs 206 (as represented by vONUs 408 relative to the OLT 302), and assumes both the fiber segment (fiber FDD 1200) and the coax segment (coax FDD 1204) work with an FDD scheme. Such a schedule may be included in gate messages. Because EPON downstream uses broadcasting, the OCU 404 can be configured to receive all Gate messages. The OCU 404 can further be configured to open the Gate messages destined to CNUs 206 on its coax segment. The OCU 404 can then further get the original grant information for all the upstream packets from all CNUs 206 on its segment, translate this original schedule into TDD, and put the new schedule in corresponding new cGate messages, and send them to the appropriate CNUs 308. Note that depending on the actual technology used for the coax segment (e.g., MoCA or c.LINK etc.), the cGate message may have different functions and formats from the EPON Gate message. For example in the MoCA or c.LINK case, the cGate corresponds to the MAP, and the cReport corresponds to the Reservation Request.

[0088] If the TDD channel (coax TDD 1202) has a burst rate that is approximately twice the corresponding FDD channel burst rate, the TDD schedule for the upstream traffic will be time-compressed relative to the original FDD schedule. As can be seen from the example of figure 12, relative to the coax FDD scheme 1204, the coax TDD scheme 1202 can transmit the same amount of upstream traffic in about half of the time. The end-to-end latency (from a CNU 206 to the OLT 302) is the same in both the coax FDD scheme 1204 and the coax TDD scheme 1202. Generally, the head Gate Advance Time should be >=½ TDD US/DS (i.e. MAP) cycle, so that OCU 404 knows how much DS traffic from the fiber segment it can group into the coax segment downstream. Note that the coax TDD 1 02 upstream schedule 1203 is translated by the OCU 404 from the OLT's FDD schedule.

[0089] The coax TDD 1202 scheme works on a (downstream + upstream) MAP cycle basis, where each cycle starts with downstream traffic (broadcast or unicast), followed by upstream traffic. The proportion of upstream vs. downstream traffic within each MAP cycle is determined by the OCU 404 on real-time basis according to the actual upstream and downstream traffic demands. As described above, the OCU 404 determines the upstream portion of the MAP cycle in the coax segment by aggregating all the Gate messages for the CNUs 206 in the OCU's coax segment from the OLT 302 over a time interval of equivalent to a MAP cycle, and by calculating the time duration needed on the coax segment for transmitting the corresponding granted data packets. The OCU 404 then knows the corresponding downstream portion of the MAP cycle. The OCU 404 sends out downstream packets that it has accumulated until the beginning of this downstream portion.

[0090] The OCU 404 can be configured in some embodiments to reserve some coax segment time for coax network-specific tasks like Link Control, Link Maintenance Operations, channel probing, etc. These tasks are performed locally on the coax network coax network, and are not generally visible to the OLT 302. However, for QoS purposes, the OLT 302 should know the capacity of the coax segment in order to guarantee key QoS performance parameters like latency, throughput, etc. These capacity parameters of the coax network can be communicated to the OLT 302 through various techniques. The first method is through network configuration by the operator. The second method is through realtime messaging between the OCU 404 and the OLT 302.

[0091] In order for the OCU 404 to do upstream traffic schedule translation for CNUs 206, the OLT 302 must provide enough advance time between when the gate message arrives at the OCU 404 that contains a given grant and when the scheduled time for actual upstream packet transmission . This Gate advance time should be >=½ TDD US/DS (i.e. MAP) cycle, so that OCU 404 knows how much DS traffic from the fiber segment it can group into the coaxial downstream

[0092] Comparing the upstream and downstream latencies between coax FFD 1204 and coax TDD 1202 schemes, it can be seen that the two schemes have similar latency between a CNU 206 and the OLT 302. The main difference is that the coax FDD scheme 1204 allows shorter Gate to Data time (Gate advance time), while the coax TDD scheme 1202 needs a Gate advance time that is at least ½ TDD MAP cycle length + OCU processing time for Gate message translation.

[0093] Generally a fiber channel like EPON has a different throughput from the coax segment's throughput. For example the EPON generally has a stable fiber channel, has a 1 Giga-bit/s upstream throughput and a 1 Giga-bit/s downstream throughput. On the other hand, the upstream and downstream throughput on a coax segment may be very different, depending on many parameters. This throughput can also change over time, particularly on the un-engineered high- frequency bands. Consider the case where the coax segment uses FDD like in EPON, but upstream and downstream each have a throughput of approximately 400 Mbits/s, for example. The OLT 302 should be aware of the throughput mismatch, and should not schedule more traffic than the coax segment can handle. Because the burst rate is different on the two segments, buffering in the OCU 404 is needed to accommodate the speed mismatch in both the upstream and downstream directions. In each direction, the latency for different packets is different, making it difficult for the regular OLT scheduler to schedule for both ONUs 308 and CNUs 206.

[0094] As discussed above, there are two different approaches to resolve this variability in latency on the coax segment. The first method, called non-overlapping scheduling (embodiments described above with reference to figures 7, 8 and 9), considers the fiber and coax segment as if they are the same medium, and non- overlapping of activity is scheduled on the two segments. This can be done by using a buffer in the OCU 404 in each direction of traffic, such that all packets on the upstream direction have the same or substantially the same latency from the CNU 206 to the OLT 302. This may be achieved by the OCU 404 delaying different upstream packets with different delays through buffering, such that as far as delay is concerned, the OCU 404 behaves as if it is a wire. This method is relatively less efficient because it does not accommodate overlapping of traffic on both segments. [0095] The second method, which is an overlapping method, divides the CNU-to-OLT delay into two parts; The constant OCU-to-OLT delay, and the up-bound of Gate to Report/Data delay on the coax segment (cGR). This cGR also includes the data path transfer delay inside the OCU 404 from the coax port to the ONU 308 port. This cGR is communicated to the OLT 302 so that the OLT 302 can schedule overlapping activity on the fiber and the coax segment. For example, for some given time-slots, the OLT 302 can schedule one CNU 206 to transmit an upstream packet on the coax segment, and at the same time n ONU 308 to transmit upstream packet to the OLT 302 and/or receive a downstream packet from the OLT 302. The performance variability of the coax segment in term of latency is represented by cGR. Similarly the performance variability in terms of throughput can be represented by a similar parameter.

[0096] Figure 13 is a diagram illustrating an example of sequencing of transactions on the aggregated fiber and coax networks in accordance with one embodiment of the technology described herein. Figure 14 is an operational flow diagram illustrating an example process for this sequencing in accordance with one embodiment of the technology described herein. Particularly, Figure 14 describes a second method of OCU 404 and aggregated network operation with reference to figure 13. For clarity of description, this operation is also described in the context of the example systems illustrated in figure 4. After reading this description, one of ordinary skill in the art will understand how this process can be implemented with other bridged Network Systems. [0097] Referring now to figures 4, 13 and 14, at operation 1402, OLT 302 sends a Gate message to a virtual O U (vONU) 408, which is created by the OCU 404 as corresponding to a CNU 206. At operation 1404, OCU 404 intercepts the Gate message. At operation 1406, OCU 404 checks the status of its queues of the vONU 408 associated with this CN U 206 and builds and sends a Report message to the OLT 302. The Report message can be sent either alone or as a piggyback on a data packet.

[0098] OLT 302 receives the Report message and, based on this message, at step 1408 builds a transmission schedule on the fiber segment for the vONU 408. OLT 302 sends the schedule (grants) in a Gate message to the vONU 408 (CNU 206). At operation 1410, OCU 404 intercepts the Gate message and sends granted packets to OLT 302 at the scheduled time as if the packets are from the vONU 408 (CNU 206).

[0099] In parallel to the above process, OCU 404 intercepts Gate messages from the OLT 302 to all CNUs 206 in its coax segment, accumulates them over a time interval equivalent to the MAP cycle length of the coax segment. The OCU 404 then builds a TDD schedule for the coax segment, and sends the schedule in a MAP (cGate) to CNUs. This is illustrated at operation 1412. It is noted that downstream traffic on the coax segment can be done either as broadcast or unicast. In the case of broadcasting in which all CNU's 206 receive all packets from OCU 404, common modulation and bit loading can be used. In the case of unicasting, each pair of OCU 404 and CN U 206 may use different modulation and bit loading schemes, and a CN U 206 only receives packets destined for it. In this case, a new cGate (MAP) message can be used to inform each C U 206 in advance of the upcoming downstream packets. This new cGate message may be created by OCU 404 and used by each CNU 206 to prepare its receiver. In some embodiments, upstream traffic on the collect segment is always unicast, but the modulation and bit loading for each unicast pair can be the same or different.

[00100] At operation 1414, the OCU 404 receives upstream packets from the CNU 206 and stores them into the set of queues of the vONU corresponding to that CNU 206. Accordingly, these packets will be ready for upstream transmission to the OLT 302 upon the next gate message from the OLT 302.

[00101] The CNU's upstream latency is a function of the EPON pulling interval and coax cGate to cData+cRep latency, which is a function of TDD MAP cycle length. With this method, the only ranging used is ranging from the OLT 302 to OCU 404 which proxies each CNU 206 with a corresponding vONU 408. There is no need to range from the OLT 302 to the CNU 206. The CNU 206 synchronizes its clock to the OCU 404, which is synchronized to the OLT 302.

[00102] In the operation of the aggregated network just described, network management messages like DPoE and OAM are considered as regular Ethernet data packets, and are thus just passed through the OCU, thus allowing end to end network management.

[00103] With the decoupling of Gate - Report+Data sequencing on the fiber and coax segments, the mismatch in throughput between the two segments is inherently handled by the OCU 404 buffering. Traffic on the two segments is inherently overlapping. The OCU 404 effectively throttles the traffic between the OLT 302 and the CNUs 206. The Gate/ eport+Data mechanism between the OLT 302 and the OCU 404 effectively defines how much traffic the OLT 302 can schedule to/from each the OCU 404.

[00104] The coax segment downstream can be either broadcasting or unicasting. When broadcasting is used, GCD bit-loading for all CNUs 206 is used by the OCU 404, and each CN U 206 receives all downstream traffic and filters for packets destined to itself. The potential problem with using GCD is that GCD may be very low because of differing null locations for different CNUs 206. This may become worse in the higher radio frequency. An advantage of this method is that there is no need for a cGate message for downstream packets.

[00105] When downstream transmission uses unicasting, the OCU 404 must be configured to first create and send a MAP (cGate) message for all CNUs 206 before sending a unicasting packet downstream, so that each CNU 206 may prepare its receiver for this unicasting. This adds extra delay between the OCU 404 and the CN U 206. One advantage of this met hod is that unicasting bit -loading can provide better throughput.

[00106] As used herein, the term module might describe a given unit of functionality that can be performed in accordance with one or more embodiments of the technology disclosed herein. As used herein, a module might be implemented utilizing any form of hardware, software, or a combination thereof. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logical components, software routines or other mechanisms might be implemented to make up a module. In implementation, the various modules described herein might be implemented as discrete modules or the functions and features described can be shared in part or in total among one or more modules. In other words, as would be apparent to one of ordinary skill in the art after reading this description, the various features and functionality described herein may be implemented in any given application and can be implemented in one or more separate or shared modules in various combinations and permutations. Even though various features or elements of functionality may be individually described or claimed as separate modules, one of ordinary skill in the art will understand that these features and functionality can be shared among one or more common software and hardware elements, and such description shall not require or imply that separate hardware or software components are used to implement such features or functionality. [00107] Where components or modules of the technology are implemented in whole or in part using software, in one embodiment, these software elements can be implemented to operate with a computing or processing module capable of carrying out the functionality described with respect thereto. One such example computing module is shown in Figure 15. Various embodiments are described in terms of this example-computing module 1500. After reading this description, it will become apparent to a person skilled in the relevant art how to implement the technology using other computing modules or architectures.

[00108] Referring now to Figure 15, computing module 1500 may represent, for example, computing or processing capabilities found within desktop, laptop and notebook computers; hand-held computing devices (PDA's, smart phones, cell phones, palmtops, etc.); mainframes, supercomputers, workstations or servers; or any other type of special-purpose or general-purpose computing devices as may be desirable or appropriate for a given application or environment. Computing module 1500 might also represent computing capabilities embedded within or otherwise available to a given device. For example, a computing module might be found in other electronic devices such as, for example, digital cameras, navigation systems, cellular telephones, portable computing devices, modems, routers, WAPs, terminals and other electronic devices that might include some form of processing capability. [00109] Computing module 1500 might include, for example, one or more processors, controllers, control modules, or other processing devices, such as a processor 1504. Processor 1504 might be implemented using a general-purpose or special-purpose processing engine such as, for example, a microprocessor, controller, or other control logic. In the illustrated example, processor 1504 is connected to a bus 1502, although any communication medium can be used to facilitate interaction with other components of computing module 1500 or to communicate externally.

[00110] Computing module 1500 might also include one or more memory modules, simply referred to herein as main memory 1508. For example, preferably random access memory (RAM) or other dynamic memory, might be used for storing information and instructions to be executed by processor 1504. Main memory 1508 might also be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 1504. Computing module 1500 might likewise include a read only memory ("ROM") or other static storage device coupled to bus 1502 for storing static information and instructions for processor 1504.

[00111] The computing module 1500 might also include one or more various forms of information storage mechanism 1510, which might include, for example, a media drive 1512 and a storage unit interface 1520. The media drive 1512 might include a drive or other mechanism to support fixed or removable storage media 1514. f or example, a hard disk drive, a floppy disk drive, a magnetic tape drive, an optical disk drive, a CD or DVD drive ( or RW), or other removable or fixed media drive might be provided. Accordingly, storage media 1514 might include, for example, a hard disk, a floppy disk, magnetic tape, cartridge, optical disk, a CD or DVD, or other fixed or removable medium that is read by, written to or accessed by media drive 1512. As these examples illustrate, the storage media 1514 can include a computer usable storage medium having stored therein computer software or data.

[00112] In alternative embodiments, information storage mechanism

1510 might include other similar instrumentalities for allowing computer programs or other instructions or data to be loaded into computing module 1500. Such instrumentalities might include, for example, a fixed or removable storage unit 1522 and an interface 1520. Examples of such storage units 1522 and interfaces 1520 can include a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, a PCMCIA slot and card, and other fixed or removable storage units 1522 and interfaces 1520 that allow software and data to be transferred from the storage unit 1522 to computing module 1500.

[00113] Computing module 1500 might also include a communications interface 1524. Communications interface 1524 might be used to allow software and data to be transferred between computing module 1500 and external devices. Examples of communications interface 1524 might include a modem or softmodem, a network interface (such as an Ethernet, network interface card, WiMedia, IEEE 802. X or other interface), a communications port (such as for example, a USB port, IR port, RS232 port Bluetooth* interface, or other port), or other communications interface. Software and data transferred via communications interface 1524 might typically be carried on signals, which can be electronic, electromagnetic (which includes optical) or other signals capable of being exchanged by a given communications interface 1524. These signals might be provided to communications interface 1524 via a channel 1528. This channel 1528 might carry signals and might be implemented using a wired or wireless communication medium. Some examples of a channel might include a phone line, a cellular link, an RF link, an optical link, a network interface, a local or wide area network, and other wired or wireless communications channels.

[00114] In this document, the terms "computer program medium" and "computer usable medium" are used to generally refer to media such as, for example, memory 1508, storage unit 1520, media 1514, and channel 1528. These and other various forms of computer program media or computer usable media may be involved in carrying one or more sequences of one or more instructions to a processing device for execution. Such instructions embodied on the medium, are generally referred to as "computer program code" or a "computer program product" (which may be grouped in the form of computer programs or other groupings). When executed, such instructions might enable the computing module 1500 to perform features or functions of the disclosed technology as discussed herein.

[00115] While various embodiments of the disclosed technology have been described above, it should be understood that they have been presented by way of example only, and not of limitation. Likewise, the various diagrams may depict an example architectural or other configuration for the disclosed technology, which is done to aid in understanding the features and functionality that can be included in the disclosed technology. The disclosed technology is not restricted to the illustrated example architectures or configurations, but the desired features can be implemented using a variety of alternative architectures and configurations. Indeed, it will be apparent to one of skill in the art how alternative functional, logical or physical partitioning and configurations can be implemented to implement the desired features of the technology disclosed herein. Also, a multitude of different constituent module names other than those depicted herein can be applied to the various partitions. Additionally, with regard to flow diagrams, operational descriptions and method claims, the order in which the steps are presented herein shall not mandate that various embodiments be implemented to perform the recited functionality in the same order unless the context dictates otherwise.

[00116] Although the disclosed technology is described above in terms of various exemplary embodiments and implementations, it should be understood that the various features, aspects and functionality described in one or more of the individual embodiments are not limited in their applicability to the particular embodiment with which they are described, but instead can be applied, alone or in various combinations, to one or more of the other embodiments of the disclosed technology, whether or not such embodiments are described and whether or not such features are presented as being a part of a described embodiment. Thus, the breadth and scope of the technology disclosed herein should not be limited by any of the above-described exemplary embodiments.

[00117] Terms and phrases used in this document, and variations thereof, unless otherwise expressly stated, should be construed as open ended as opposed to limiting. As examples of the foregoing: the term "including" should be read as meaning "including, without limitation" or the like; the term "example" is used to provide exemplary instances of the item in discussion, not an exhaustive or limiting list thereof; the terms "a" or "an" should be read as meaning "at least one," "one or more" or the like; and adjectives such as "conventional," "traditional," "normal," "standard," "known" and terms of similar meaning should not be construed as limiting the item described to a given time period or to an item available as of a given time, but instead should be read to encompass conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future. Likewise, where this document refers to technologies that would be apparent or known to one of ordinary skill in the art, such technologies encompass those apparent or known to the skilled artisan now or at any time in the future. [00118] The presence of broadening words and phrases such as "one or more," "at least," "but not limited to" or other like phrases in some instances shall not be read to mean that the narrower case is intended or required in instances where such broadening phrases may be absent. The use of the term "module" does not imply that the components or functionality described or claimed as p rt of the module are all configured in a common package. Indeed, any or all of the various components of a module, whether control logic or other components, can be combined in a single package or separately maintained and can further be distributed in multiple groupings or packages or across multiple locations.

[00119] Additionally, the various embodiments set forth herein are described in terms of exemplary block diagrams, flow charts and other illustrations. As will become apparent to one of ordinary skill in the art after reading this document, the illustrated embodiments and their various alternatives can be implemented without confinement to the illustrated examples. For example, block diagrams and their accompanying description should not be construed as mandating a particular architecture or configuration.

Claims

1. A network bridge comprising one or more processors and a non-transitory computer readable storage medium coupled to the one or more processors, the computer readable storage medium including computer program logic embodied therein, which when executed by the one or more processors causes the network bridge to perform the operations comprising:

creating a plurality of virtual nodes on a first network, wherein each virtual node corresponds to a physical node on a second network;

intercepting schedule messages sent by a headend of the first network to designated virtual nodes, wherein each schedule message includes an indication of granted timeslots for upstream packets to be sent by the corresponding designated virtual node on the first network;

creating a new schedule messages for the physical nodes on the second network based on the intercepted schedule messages, and sending the new schedule messages to their respective corresponding physical nodes on the second network, wherein when the granted timeslots occur, the physical nodes send corresponding granted packets at the granted time;

receiving the corresponding granted packets from the physical nodes and forwarding the received granted packets to the headend of the first network at the original scheduled time.

2. The network bridge of claim 1, wherein the operations further comprise buffering the granted packets received from the physical nodes and wherein forwarding the received packets comprises determining times to send the packets as upstream traffic on the first network and sending the received packets on the first network at the scheduled times specified in the intercepted schedule messages.

3. The network bridge of claim 1, wherein for a granted packet, the time to send the granted packets as upstream traffic on the first network is determined based on the path delay on the first network, the delay in the bridge, and the network latency of the second network.

4. The network bridge of claim 1, wherein the operations further comprise computing a total upstream traffic time requirement on the second network based on the intercepted schedule messages from the headend of the f irst network, and computing available downstream traffic time as a difference between a MAP cycle length of the second network and the upstream traffic time requirement.

5. The network bridge of claim 4, wherein computing upstream and

downstream traffic time on the second network is based on actual channel capacity information for the second network.

6. The network bridge of claim 1, wherein the operations further comprise scheduling time-slots on the second segment for local network specific operations, wherein the local traffic operations include at least one of like node admission, link maintenance, and link security.

7. The network bridge of claim 1, wherein creating new schedule messages comprises scheduling an amount of upstream traffic on the second network as defined in the intercepted schedule messages from the headend of the first network, such that schedule sequences on the first and second networks are coupled.

8. The network bridge of claim 1, wherein creating new schedule messages comprises scheduling traffic on the second network independent of the intercepted schedule messages of the first network, such that the schedule sequences on the first and second networks are decoupled.

9. The network bridge of claim 8, wherein creating new schedule messages further comprises terminating message sequencing relative to the headend of the first network by acting as a virtual node for each physical node on the second network.

10. The network bridge of claim 1, wherein the operations further comprise creating the schedule messages for the second network from the intercepted schedule messages with second network-specific schedule information for the designated physical nodes.

11. The network bridge of claim 10, wherein the second network specific schedule is independent of the grant schedule from the headend of the first network, and allows remaining time slots on the second network to be used by the network bridge to schedule second network system operations.

12. The network bridge of cl im 1, wherein the operations further comprise reserving a predetermined amount of coax segment time for coax network-specific tasks, the coax network-specific task comprising at least one of like Link Control, Link Maintenance Operations, and channel probing.

13. The network bridge of claim 1, wherein the operations of claim 1 are performed such that the headend communicates with the designated physical node on the second network as if it were a physical node on the first network.

14. The network bridge of claim 1, wherein the operations further comprise communicating the second network's network latency, so that the headend can use the latency in the second network to allow concurrent traffic on the first network.

15. The network bridge of claim 1, wherein the operations further comprise buffering to accommodate a wire speed mismatch in the first and second networks, for both upstream and downstream directions.

16. The network bridge of claim 1, wherein the operations further comprise buffering traffic in the upstream and downstream directions such that packets on the upstream direction each have the same or substantially the same latency from a given physical node on the second network to the headend of the first network.

17. The network bridge of claim 16, wherein buffering traffic in the upstream and downstream directions such that packets from a given physical node on the second network on the upstream direction have the same or substantially the same latency comprises delaying different packets with different delays for different physical nodes.

18. The network bridge of claim 1, wherein the first network is a Passive Optical Network (PON, including EPON, 10G EPON) using an FDD scheme, and the second network is a coax-based TDD network.

19. The network bridge of claim 1, wherein the schedule message comprises a Gate message on the first network, and a MAP message on the second network, with a MAP message containing both an upstream and a downstream schedule for one or multiple nodes on the second network; and a report message comprises a Report message on the first network, and a Reservation Request on the second network.

20. The network bridge of claim 1, wherein the schedule message comprises a Gate message on the first network, and an updated Gate message on the second network, with the updated Gate message comprising a schedule for a single node of the second network; and a report message comprises a Report message on the first network, and a Reservation Request on the second network.

21. The network bridge of claim 1, wherein the operations further comprise performing as an access network controller of the second network, including performing the operations of admitting new nodes to the second network, scheduling traffic on the second network.

22. The network bridge of claim 1, wherein the operations further comprise creating a virtual node on the first network for each physical node on the second access network, and admitting the virtual node into the first network .

23. The network bridge of claim 1, wherein the operations further comprise ranging between each virtual node and the headend of the first network, wherein a latency is determined as a sum of the latency between the headend of the first network and a port of the bridge on the first network, and the network latency of the second network.

24. The network bridge of claim 1, wherein the operations further comprise controlling a bridge delay such that the total latency between the physical node on the second network and the headend of the first network is constant.

25. The network bridge of claim 1, wherein creating a new schedule messages for the second network comprises accumulating a plurality of intercepted schedule messages from the headend of the first network over a predetermined time period and using the accumulated schedule messages to create the new messages.

26. A method of bridging networks, comprising:

27. The method of claim 26, further comprising buffering the granted packets received from the physical nodes and wherein forwarding the received packets comprises determining times to send the packets as upstream traffic on the first network and sending the received packets on the first network at the scheduled times specified in the intercepted schedule messages.

28. The method of claim 26, wherein for a granted packet, the time to send the granted packets as upstream traffic on the first network is determined based on the path delay on the first network, the delay in the bridge, and the network latency of the second network.

29. The method of claim 26, further comprising computing a total upstream traffic time requirement on the second network based on the intercepted schedule messages from the headend of the first network, and computing available downstream traffic time as a difference between a MAP cycle length of the second network and the upstream traffic time requirement.

30. The method of claim 29, wherein computing upstream and downstream traffic time on the second network is based on actual channel capacity information for the second network.

31. The method of claim 26, further comprising scheduling time-slots on the second segment for local network specific operations, wherein the local traffic operations include at least one of like node admission, link maintenance, and link security.

32. The method of claim 26, wherein creating new schedule messages comprises scheduling an amount of upstream traffic on the second network as defined in the intercepted schedule messages from the headend of the first network, such that schedule sequences on the first and second networks are coupled.

33. The method of claim 26, wherein creating new schedule messages comprises scheduling traffic on the second network independent of the intercepted schedule messages of the first network, such that the schedule sequences on the first and second networks are decoupled.

34. The method of claim 26, wherein creating new schedule messages further comprises terminating message sequencing relative to the headend of the first network by acting as a virtual node for each physical node on the second network.

35. The method of claim 26, further comprising creating the schedule messages for the second network from the intercepted schedule messages with second network-specific schedule information for the designated physical nodes.

36. The method of claim 35, wherein the second network specific schedule is independent of the grant schedule from the headend of the first network, and allows remaining time-slots on the second network to be used by the network bridge to schedule second network system operations.

37. The method of claim 26, further comprising reserving a predetermined amount of coax segment time for coax network-specific tasks, the coax network- specific task comprising at least one of like Link Control, Link Maintenance

Operations, and channel probing.

38. The method of claim 26, wherein the operations of the bridge are performed such that the headend communicates with the designated physical node on the second network as if it were a physical node on the first network.

39. The method of claim 26, further comprising communicating the second network's network latency, so that the headend can use the latency in the second network to allow concurrent traffic on the first network.

40. The method of claim 26, further comprising buffering to accommodate a wire speed mismatch in the first and second networks, for both upstream and

downstream directions.

41. The method of claim 26, further comprising buffering traffic in the upstream and downstream directions such that packets on the upstream direction each have the same or substantially the same latency from a given physical node on the second network to the headend of the first network.

42. The method of claim 41, wherein buffering traffic in the upstream and downstream directions such that packets from a given physical node on the second network on the upstream direction have the same or substantially the same latency comprises delaying different upstream packets with different delays for different physical nodes.

43. The method of claim 26, wherein the first network is a Passive Optical Network (PON, including EPON, 10G FPON) using an FDD scheme, and the second network is a coax-based TDD network.

44. The method of claim 26, wherein the schedule message comprises a Gate message on the first network, and a MAP message on the second network, with a MAP message containing both an upstream and a downstream schedule for one or multiple nodes on the second network; and a report message comprises a Report message on the first network, and a Reservation Request on the second network.

45. The method of claim 26, wherein the schedule message comprises a Gate message on the first network, and an updated Gate message on the second network, with the updated Gate message comprising a schedule for a single node of the second network; and a report message comprises a Report message on the first network, and a Reservation Request on the second network.

46. The method of claim 26, further comprising performing as an access network controller of the second network, including performing the operations of admitting new nodes to the second network, scheduling traffic on the second network.

47. The method of claim 26, further comprising creating a virtal node on the first network for each physical node on the second access network, and admitting the virtual node into the first network .

48. The method of claim 26, further comprising ranging between each virtual node and the headend of the first network, wherein a latency is determined as a sum of the latency between the headend of the first network and a port of the bridge on the first network, and the network latency of the second network.

49. The method of claim 26, further comprising controlling a bridge delay such that the total latency between the physical node on the second network and the headend of the first network is constant.

50. The method of claim 26, wherein creating new schedule messages comprises accumulating a plurality of intercepted schedule messages over a predetermined time period and using the accumulated schedule messages to create the new messages.

51. A bridged network system, comprising:

a first network using an FDD scheme, the first network comprising a headend and one or more physical network nodes communicatively coupled to the headend, the headend comprising one or more ports, one or more processors, and a non- transitory computer readable storage medium coupled to the one or more processors, the computer readable storage medium including computer program logic embodied therein, which when executed by the one or more processors causes the headend to perform the operation of scheduling node traffic on the first network and send schedule messages to schedule network resources; a second networ k with a network controller (NC) and one or more physical network nodes communicatively coupled to the NC, wherein the NC is configured to schedule node traffic on the second network; and

a bridge comprising a first port communicatively coupled to the first network, a second port comprising the NC of the second network, one or more processors, and a non-transitory computer readable storage medium coupled to the one or more processors, the computer readable storage medium including computer program logic embodied therein, which when executed by the one or more processors causes the bridge to perform the operations of:

creating a new schedule messages for the physical nodes on the second network based on the intercepted schedule messages, and sending the new schedule messages to their respective corresponding physical nodes on the second network, wherein when the granted timeslots occur, the physical nodes send corresponding granted packets at the granted time; and receiving the corresponding granted packets from the physical nodes and forwarding the received granted packets to the headend of the first network at the original scheduled time.

52. The bridged network system of claim 51, wherein the operations of the headend further comprise the headend increasing its schedule advance time to compensate for latency in the second network and in the bridge.

53. The bridged network system of claim 52, wherein the operations of the headend further comprise the headend allocating the increase in schedule advance time to other traffic on the first network.

54. The bridged network system of claim 51, wherein the operations of the bridge further comprise buffering the granted packets received from the physical nodes and wherein forwarding the received packets comprises determining times to send the packets as upstream traffic on the first network and sending the received packets on the first network at the scheduled times specified in the intercepted schedule messages..

55. The bridged network system of claim 51, wherein for a granted packet, the time to send the granted packets as upstream traffic on the first network is determined based on the path delay on the first network, the delay in the bridge, and the network latency of the second network.

56. The bridged network system of claim 51, wherein the operations of the bridge further comprise computing a total upstream traffic time requirement on the second network based on the intercepted schedule messages from the headend of the first network, and computing available downstream traffic time as a difference between a MAP cycle length of the second network and the upstream traffic time requirement.

57. The bridged network system of claim 51, wherein computing upstream and downstream traffic time on the second network is based on actual channel capacity information for the second network.

58. The bridged network system of claim 51, wherein the operations of the bridge further comprise scheduling time-slots on the second segment for local network specific operations, wherein the local traffic operations include at least one of like node admission, link maintenance, and link security.

59. The bridged network system of claim 51, wherein the operations of the headend further comprise performing ranging between the headend and each virtual node on the first network.

60. The bridged network system of claim 59, wherein ranging comprises summing a range between the headend and the bridge, latency in the bridge, and network latency of the second network.

61. The bridged network system of claim 59, wherein the operations of the bridge further comprise controlling bridge internal latency such that each virtual node of the bridge presents a constant range (latency) to the headend.

62. The bridged network system of claim 51, wherein the operations of the headend further comprise accounting for the increased range for the virtual nodes when scheduling upstream packets for said virtual nodes.

63. The bridged network system of claim 51, wherein the operations of the headend further comprise obtaining the capacity information of the second network in order to guarantee end to end QoS performance.

64. The bridged network system of claim 51, wherein creating new schedule messages comprises scheduling an amount of upstream traffic on the second network as defined in the intercepted schedule messages from the headend of the first network, such that schedule sequences on the first and second networks are coupled.

65. The bridged network system of claim 51, wherein creating new schedule messages comprises scheduling traffic on the second network independent of the intercepted schedule messages of the first network, such that the schedule sequences on the first and second networks are decoupled.

66. The bridged network system of claim 65, wherein creating new schedule messages further comprises terminating message sequencing relative to the headend of the first network by acting as a virtual node for each physical node on the second network.

67. The bridged network system of claim 51, wherein the operations of the bridge further comprise creating the schedule messages for the second network from the intercepted schedule messages with second network-specific schedule information for the designated physical nodes.

68. The bridged network system of claim 67, wherein the second network specific schedule is independent of the grant schedule from the headend of the first network, and allows remaining time-slots on the second network to be used by the network bridge to schedule second network system operations.

69. The bridged network system of claim 51, wherein the operations of the bridge further comprise reserving a predetermined amount of coax segment time for coax network-specific tasks, the coax network-specific task comprising at least one of like Link Control, Link Maintenance Operations, and channel probing.

70. The bridged network system of claim 51, wherein the operations of the bridge are performed such that the headend communicates with the designated physical node on the second network as if it were a physical node on the first network.

71. The bridged network system of claim 51, wherein the operations of the bridge further comprise communicating the second network's network latency, so that the headend can use the latency in the second network to allow concurrent traffic on the first network.

72. The bridged network system of claim 51, wherein the operations of the bridge further comprise buffering to accommodate a wire speed mismatch in the first and second networks, for both upstream and downstream directions,

73. The bridged network system of claim 51, wherein the operations of the bridge further comprise buffering traffic in the upstream and downstream directions such that packets on the upstream direction each have the same or substantially the same latency from a given physical node on the second network to the headend of the first network.

74. The method of claim 73, wherein buffering traffic in the upstream and downstream directions such that packets from a given physical node on the second network on the upstream direction have the same or substantially the same latency comprises delaying different packets with different delays for different physical nodes.

75. The bridged network system of claim 51, wherein the first network is a Passive Optical Network (PON, including EPON, 10G EPON) using an FDD scheme, and the second network is a coax-based TDD network.

76. The bridged network system of claim 51, wherein the schedule message comprises a Gate message on the first network, and a MAP message on the second network, with a MAP message containing both an upstream and a downstream schedule for one or multiple nodes on the second network; and a report message comprises a Report message on the first network, and a Reservation Request on the second network.