Systems and methods for providing a MoCA power management strategy

Information

  • Patent Grant
  • 9112717
  • Patent Number
    9,112,717
  • Date Filed
    Wednesday, July 29, 2009
    14 years ago
  • Date Issued
    Tuesday, August 18, 2015
    8 years ago
Abstract
Systems and methods for performing a method for reducing power consumption in MoCA devices that are connected via a coax network are provided. One method according to the invention includes, in a home network having a plurality of network modules, one of said plurality of network modules being a network controller, each of said plurality of network modules being connected to a coax backbone, communicating over the coax backbone between the plurality of network modules. The method further includes using the master module to receive requests sent over the coax backbone from the plurality of network modules for bandwidth to transmit bursts. The master module may establish an order of transmission opportunities for the plurality of network modules to follow when transmitting bursts directly to other network modules via the coax backbone. The method may also include using the master module to toggle each of the networked modules between a running power state and a standby power state. The standby power state may include an active mode and an idle mode. In the active mode, a networked node is configured to transmit and/or receive packets of information. In the idle mode, the networked node is configured to maintain a link to the network while powering down a portion of the circuit blocks, thereby reducing power consumption of the networked node.
Description
FIELD OF TECHNOLOGY

The present invention relates generally to information networks and specifically to transmitting information such as media information over communication lines such as coaxial cable (hereinafter “coax”), thereby to form a communications network.


BACKGROUND OF THE INVENTION

Home network technologies using coax are known generally. The Multimedia over Coax Alliance (MoCA™), at its website mocalliance.org, provides an example of a suitable specification (MoCA 1.1) for networking of digital video and entertainment through existing coaxial cable in the home which has been distributed to an open membership. The MoCA 1.1 specification is incorporated by reference herein in its entirety.


Home networking over coax taps into the vast amounts of unused bandwidth available on the in-home coax. More than 70% of homes in the United States have coax already installed in the home infrastructure. Many have existing coax in one or more primary entertainment consumption locations such as family rooms, media rooms and master bedrooms—ideal for deploying networks. Home networking technology allows homeowners to utilize this infrastructure as a networking system and to deliver other entertainment and information programming with high QoS (Quality of Service).


The technology underlying home networking over coax provides high speed (270 mbps), high QoS, and the innate security of a shielded, wired connection combined with state of the art packet-level encryption. Coax is designed for carrying high bandwidth video. Today, it is regularly used to securely deliver millions of dollars of pay per view and premium video content on a daily basis. Home networking over coax can also be used as a backbone for multiple wireless access points used to extend the reach of wireless network throughout a consumer's entire home.


Home networking over coax provides a consistent, high throughput, high quality connection through the existing coaxial cables to the places where the video devices currently reside in the home. Home networking over coax provides a primary link for digital entertainment, and may also act in concert with other wired and wireless networks to extend the entertainment experience throughout the home.


Currently, home networking over coax works with access technologies such as ADSL and VDSL services or Fiber to the Home (FTTH), that typically enter the home on a twisted pair or on an optical fiber, operating in a frequency band from a few hundred kilohertz to 8.5 MHz for ADSL and 12 Mhz for VDSL. As services reach the home via xDSL or FTTH, they may be routed via home networking over coax technology and the in-home coax to the video devices. Cable functionalities, such as video, voice and Internet access, may be provided to homes, via coaxial cable, by cable operators, and use coaxial cables running within the homes to reach individual cable service consuming devices locating in various rooms within the home. Typically, home networking over coax type functionalities run in parallel with the cable functionalities, on different frequencies.


It would be desirable to achieve maximum power savings with MoCA devices connected by a MoCA home network.


SUMMARY OF THE INVENTION

A system and/or method for achieving maximum power savings with MoCA devices connected by a MoCA home network, substantially as shown in and/or described in connection with at least one of the figures, as set forth more completely in the claims.





BRIEF DESCRIPTION OF THE DRAWINGS

The objects and advantages of the invention will be apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout, and in which:



FIG. 1 shows a schematic diagram of MoCA Core blocks; and



FIG. 2 shows a schematic diagram of an operational sequence of an existing MoCA node (“EN”) entering standby state;



FIG. 3 shows a schematic diagram of an operational sequence of an EN re-entering running state;



FIG. 4 shows a schematic diagram of another embodiment of an operational sequence of a transmission to an EN in standby state;



FIG. 5 shows an exemplary embodiment of a system that may use the methods described herein to reduce power consumption in a MoCA network;



FIG. 6 shows a schematic diagram of the operation of a standby state according to the invention;



FIG. 7 showing a schematic diagram of an operational sequence of a standby node according to the invention;



FIG. 8 shows a schematic diagram of power dependence for a network device in a system according to the invention;



FIG. 9 shows a schematic diagram of a power state transition sequence according to the invention;



FIG. 10 shows a schematic diagram of active standby/idle standby mode transition for a MoCA node participating in a periodic Link Maintenance Operation (LMO) according to the invention; and



FIG. 11 is a schematic diagram of an illustrative single or multi-chip module of the invention in a data processing system.





DETAILED DESCRIPTION OF THE INVENTION

In the following description of the various embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration various embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope and spirit of the present invention.


As will be appreciated by one of skill in the art upon reading the following disclosure, various aspects described herein may be embodied as a method, a data processing system, or a computer program product. Accordingly, those aspects may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, such aspects may take the form of a computer program product stored by one or more computer-readable storage media having computer-readable program code, or instructions, embodied in or on the storage media. Any suitable computer readable storage media may be utilized, including hard disks, CD-ROMs, optical storage devices, magnetic storage devices, and/or any combination thereof.


In addition, various signals representing data or events as described herein may be transferred between a source and a destination in the form of electromagnetic waves traveling through signal-conducting media such as metal wires, optical fibers, and/or wireless transmission media (e.g., air and/or space).


The specification describes a method to achieve a power saving mode of MoCA devices that can work together with the current MoCA 1.1 specifications and a suitable power-out saving MoCA protocol. The invention may provide a protocol whereby a MoCA-based device may be placed in standby state. The standby state can reduce power consumption of the device while allowing the device to be substantially instantaneously reactivated either locally—i.e., on the front panel of the set top box or remote IR—or remotely—i.e., from a different networked device within the home. The remote reactivation may occur over the MoCA network.


For ease of reference, the following glossary provides definitions for the various abbreviations and notations used in this patent application:

  • ARP Address Resolution Protocol
  • digital PHY Includes port of the MoCA integrated circuit that forms a conduit for signals to and from a receiver and/or transceiver integrated circuit
  • EN MoCA Existing Node (the term “node” may be referred to alternatively herein as a “module”)
  • IE Information Element
  • IPV4 IP Version 4
  • IPV6 IP Version 6
  • MAC Media Access Controller—includes logic for MoCA integrated circuit that schedules opening and closing of the digital PHY as needed for transmission and/or receiving signals from the receiver and/or transceiver integrated circuit
  • MAP Media Access Plan
  • NC MoCA Network Controller
  • NN MoCA New Node
  • PD Power Down
  • PHY Physical Layer of MoCA Network
  • PS Power Saving
  • PU Power Up
  • RO Reservation Request Opportunity
  • RR Reservation Request Message
  • STB Set Top Box
  • SV Standby Vector
  • WoM Wake on MoCA


Several organizations, among them the EC (European Commission) and Energy Star organization in the US, provide recommendations to reduce total energy consumption in homes. Among other devices, STBs, digital TVs and other video/networking devices are considered in the recommendations.


Networked devices, like networked STBs, should preferably maintain their network in a “live” state even when in a power saving mode in order to enable waking up of remote nodes. This is commonly referred to as Wake on LAN. Both Energy Star and the EC provide recommendations for networked devices that are in standby state but need to maintain their network connection ON.


Currently Wake on LAN (WoL) is specified for Ethernet and is being considered for WiFi. As MoCA becomes a prevailing home network platform that connects consumer electronics devices, a Wake on MoCA feature is much desired. While the current MoCA 1.1 specifications lack any definition of power saving, it is possible to achieve significant power saving according to the invention while maintaining MoCA network connectivity ON in standby state.


The following overview relates to power saving mode requirements related to MoCA, current power consumption of the MoCA core, and systems and techniques for power saving operating modes that are associated with EC CoC and Energy Star recommended standby states. Techniques according to the invention for power saving comply with MoCA 1.1. Techniques according to the invention are applicable to a network where nodes are configurable in standby states according to the invention. Such configurable nodes may coexist with other MoCA 1.1 nodes. Such networks, according to the invention, may also include networks comprising only nodes according to the invention. Efficient power saving modes according to the invention that may operate on top of the current MoCA specifications; and wake on MoCA protocol considerations according to the invention are also set forth herein.


A summary of preferable requirements for a MoCA standby state according to the invention may include the following:

  • 1. Significant power reduction as compared to running—i.e., active, non-standby—state;
  • 2. Maintaining network connectivity with remote MoCA nodes in power saving modes;
  • 3. Node in standby state should remain a MoCA “Active” node, as defined later in the portion of the specification relating to Wake on MoCA implementations;
  • 4. Supporting coexistence of running and standby nodes on a MoCA network;
  • 5. Configuring a node to be in standby state when coexisting with other MoCA manufacturer implementations; and
  • 6. Allocating active and idle times to increase power consumption savings (as discussed in more detail below in the portion of the specification corresponding to FIG. 6).


The following section outlines power saving states and their corresponding power consumption specifications for the MoCA core.


Power Management Specifications


This section summarizes power requirements. See also, MoCA & Power management—by Olivier Harel, which is available http://twiki-01.broadcom.com/bin/view/Chiparch/MoCAPowerManagement, which is incorporated by reference hererin in its entirety, for a more detailed description of EC CoC and Energy Star requirements.


Standby States and Power Targets


The EC recommends two standby states for consumer electronics devices and their corresponding power goals: 1) Passive standby state—currently allows 2 Watts (“W”) Alternating Current (“AC”) per set top box, but plans to reduce power to 1W AC in the near future (“Aggressive standby state”). EC CoC does not require network connectivity in passive standby state but some European countries do require maintaining it. 2) Active standby state—Requires maintaining network connectivity between the networked devices. The power requirement is 3W AC per set top box.


Energy Star defines a single standby state. Energy Star recommendations are directed to total annual energy consumption of the box, assuming that more than 50% of the time it is on standby state. There are no specific recommendations for the power consumption on standby. However, larger power consumption is allowed for the running mode. Harel assumes 3W AC per box for Energy Star standby state.


Certain assumptions regarding selected power consumption states may be as follows:


European aggressive passive standby at 1W AC allows 300 mW for the BRCM 7420 manufactured by Broadcom Corporation of Irvine, Calif. The only consumption allowed to the MoCA Core consumption is standard cell leakage. The standard cell leakage may be kept low by limiting use of (“LVT”) (Low Voltage Threshold) cells. Preferably all analog components should be powered down (<1mW) and no activity of any sort is acceptable.


European passive standby state allows 2W AC, which translates to about 1W DC for a Set-top box.


Energy Star (USA) ES assumes that a set top box would achieve 3W (AC) in standby; and this translates to just over 1.5W DC (with OK or other suitable converters) for the entire set-top box.


MoCA Standby Power Requirements in Harel


The allowed overall BRCM 7420 standby power consumption and the implied allowed power consumption for a MoCA chip (when working together with the BRCM 3450, manufactured by Broadcom Corporation of Irvine, Calif., the companion LNA/PA RF (Low Noise Amplifier/Power Amplifier) (Radio Frequency transmission chip)), are depicted in Table 1 below.


The analysis set forth in Table 1 assumes that apart from MoCA, refresh DDR (Double Data Rate) and the Ethernet subsystem interfacing with the MoCA core are ON, the latter consuming between 500 to 600 mW. In the standby state set forth in Table 1, MoCA is linked up to the Ethernet subsystem but is mostly in idle mode. Some embodiments of the invention may include reducing the power consumption of the Ethernet subsystem by awakening it only in response to an interrupt signal generated by the MoCA core applying the filtering according to the invention, described in more detail below.









TABLE 1







RF Block Power Consumption











Recommended
7420 inc.
MoCA core +


Power State
AC target (W)
MoCA (W)
3450 (mW)













Active standby
3
1.5
800-900


Passive standby
2
1
300-400


Aggressive passive
1
0.3
Only leakage


standby (EC CoC)









Table 2 shows MoCA Network Status Standby configurations according to the invention.


In standby state, active mode, the MoCA network should typically stay ON although no data are transmitted—but the link should be maintained. In idle standby mode, keeping the network ON is not mandatory but it is desirable. In aggressive idle mode, the network is OFF and the MoCA core is powered down.


Typically, the MoCA node is toggled between running state and standby state in response to a signal external to the node. The MoCA node is toggled between different standby modes in response to a trigger signal internal to the node.









TABLE 2







MoCA Network Status in Power States








Standby Power State
MoCA Network





Active mode
Link up, no transmit data -



Required


Passive mode
Link up, no transmit data -



Preferable


Aggressive passive mode (EC CoC)
Link down, MoCA is powered


(also referred to herein, in the
down


alternative, as powered-down)









In some embodiments, wake up time (time to resume data transmission/reception operation from MoCA standby state in idle mode) should preferably be kept under 20 milliseconds and most preferably under about 10 milliseconds.


Required wakeup time from power down is typically longer than wake up time from standby state. Wakeup time from power down typically requires the node to be re-admitted to the network. Assuming no channel search is required, the readmission should not take longer than 2 seconds.


As only leakage power is allowed on aggressive passive standby, rebooting the MoCA core may be required. Rebooting typically adds 75 milliseconds to the power-up time.


MoCA Core Power Consumption


This section relates to power consumption of the main power consuming blocks of the MoCA core. Overall power consumption reduction according to the invention in several operating modes is analyzed.


The section illustrates the amount of power saving that can be obtained by improving power consumption and (Power Up/Power Down) “PU/PD” times of the various blocks.



FIG. 1 shows a schematic diagram of circuitry blocks that consume power in a MoCA integrated circuit (“chip”). The circuit shown in FIG. 1 may or may not be integrated with another integrated circuit. Block 102 shows that an exemplary Broadcom 3450 chip, manufactured by Broadcom Corporation of Irvine, Calif. may be used in conjunction with the MoCA integrated circuit described herein. In some embodiments, the Broadcom 3450 chip may receive a clock signal and/or receive a power control line signal for powering down. Block 104 shows transmitting a local oscillator signal from a direct digital frequency synthesizer 120. Direct digital frequency synthesizer 120 receives a MoCA_REF PLL 118 (MoCA Reference Phase Lock Loop Signal) from an external clock signal generator 116.


External clock signal generator 116 also provides a clock signal to MoCA Core 122 that preferably runs continuously as it generates the MoCA network clock.


MoCA Core 122 provides a PHY sysclk (system clock) to the digital PHY 110 (Physical Layer of the MoCA device), a network clock to System/MAC 112 and a SYS clk to the CPU 114 (which is the processor for the MoCA core.) CPU 114 may be implemented as a MIPS or other suitable processor.


MoCA Core 122 may also provide a signal to USDS_PLL (PHY_PLL) 124 (the PHY phase lock loop) which, in turn, may provide clock signals to an analog-to-digital converter circuit 126 and a digital-to-analog converter circuit 128. While legacy MoCA specifications did not allow analog-to-digital converter circuit 126 and digital-to-analog converter circuit 128 to toggle because of shut-down times, shortened ADC/DAC power up/power down times in MoCA 2.0 preferably allows for the toggling of analog-to-digital converter circuit 126 and digital-to-analog converter circuit 128 in order to save power, as necessary.


In certain embodiments according to the invention, in order to save power but maintain the MoCA module connected to the network, the network clock generated by chip 122 and a network timer located in system/MAC 112 may be maintained in an ON state. However, the gated clock to digital PHY 110 and the gated clock to System/MAC 112 may be selectively turned OFF, which, in turn, powers down digital PHY 110 and System/MAC 112. Accordingly, substantial power may be saved by only selectively providing the network clock to digital PHY 110 and to System/MAC 112.


The network timer (typically programmed by software) provides a signal to CPU 114. The timer receives the network clock signal from chip 122. When the timer expires, the timer can reactivate CPU 114 by waking up the CPU 114 with an interrupt signal.


Preferably, because MoCA is a coordinated network, the timing of future events is deterministic—i.e., the timing of at least one MAP cycle into the future and at least one Beacon (ten MAP cycles) into the future may be known. Therefore, different blocks can be activated ahead of time so that they can be ready to transmit at known points in time.


For example, if a MoCA core is aware that it will receive a transmission at time t, it can reactivate the necessary blocks at time t minus delta, where the delta is the time needed to resynchronize to the network clock.


Table 3 depicts the RF power consumption of a selection of the blocks shown in FIG. 1 according to the invention in various modes.









TABLE 3







RF Block Power Consumption












RF
LO
REF PLL
3450















Power (mW)






TX mode
420
300
120
1000


RX mode
450
300
120
600


Power Down mode
<1
<1
<1
<1


Timing (microseconds)


Power Up
0.5
40
4
0.5


Power Down
0.5
40
4
0.5









Switching times of LO and PLL in Table 3 assume that the PLL has already been synchronized; otherwise PLL acquisition typically adds another 1 millisecond.


In running state, power consumption of transmission/receiving (“TX/RX”) depends on the actual data transmissions. When no data is transmitted or received, the RF parts can preferably be maintained in Power Down mode. However, due to the long LO switching times, PLL/LO should be kept ON during normal operations.


In standby state, switch transmission/receptions are adapted for intervals that are preferably long enough to enable the LO/PLL to be powered down.


Table 4 depicts the Analog-to-Digital Converter/Digital-to-Analog Converter (“ADC/DAC”) power estimations in various modes.









TABLE 4





Converters Block Power Consumption





















USDS PLL [NEED


Power m(W)
RX (ADC)
TX (DAC)
DEFINITION]





TX mode
226
153
120


RX mode
426
<1
120


Power-down mode
0.7
<1
TBD













Timing (microseconds)
RX (ADC)
TX (DAC)
USDS PLL





Power Up
0.5 (from standby)
.05
40



1000 (from PD)


Power Down
Application
.05
40



Dependent









In certain embodiments, setting the ADC and/or the DAC in Power Down mode may be prevented by their relatively long Power Up time. In other embodiments, when the ADC/DAC has relatively shortened (toggle) power transition time, the ADC and/or DAC may be toggled to save power.


Table 5 depicts the ADC digital power estimations in various modes









TABLE 5







MoCA digital Block Power Consumption











CPU
System/MAC
PHY
















Power m(W)






Normal Mode
100
400
400



Clock Only
50
200
200



Clock Gated
10
10
10



Timing (microseconds)



Power Up
<1
<1
<1










In running state, MoCA logic is active. In a clock only node—logic is not active but clock is not gated. In a gated clock node—power consumption is mainly due to leakage power. To estimate the CPU power consumption in gated clock mode, it is assumed that the CPU enters a WAIT state when the node is idle. The gated clock may preferably be implemented for the PHY and the System/MAC blocks. It is assumed that during a standby state according to the invention, even in active mode, PHY and MAC will not be active so their clocks can be gated. The CPU may exit its WAIT state in response to receiving a timer interrupt.


MoCA Core Estimated Power Consumption in Normal Operation


Table 6 depicts the estimated power consumption for an existing MoCA node (EN) for two cases:

  • 1) When no data are transmitted: When a MoCA node is in standby state, in idle mode (neither transmitting nor receiving), its expected power consumption is about 1.4W, and could be reduced to about 1.0W if a gated clock is applied according to the invention.
  • 2) Maximal traffic load: MoCA is expected to consume an average 2.7 W.









TABLE 6







MoCA node power consumption no gated clocks













with gated clk and reduced



without gated clk
with gated clk
ADC current on idle













Power
EN No
EN Full
EN No
EN Full
EN No
EN Full


(mW)
TX Data
Traffic Load
Data
Traffic Load
Data
Traffic Load
















RF
614
1532
614
1532
614
1532


ADC/
236
283
236
283
45
261


DAC


Digital
462
760
142
722
142
722


MIPS
58
95
24
91
24
91


Total
1370
2670
1016
2628
825
2605









The estimated power consumption is based on the following assumptions: a single MAP and a single control message are transmitted per MAP cycle; five RR messages are transmitted per MAP cycle (worst case); MAP cycle is 1 millisecond long; MAP, RR and Control non-data frames (MOCA network control frames) LMO, SEC, PROBE, KEY (security) all are about 52 microseconds long; when active, a node is transmitting and receiving 50% of the time; when idle, RF is powered down and clock is gated wherever it is applicable; and, in full MoCA traffic load, the node is active 90% of the time.


The MoCA 1.1 protocol allows significant power reduction when the network is ON but no data is transmitted over the network. In methods according to the invention, the Network Controller (NC) could increase the MAP cycle duration up to 2.5 ms, while allowing a single Reservation Request opportunity per MAP cycle. In one embodiment, preferably all nodes would be required to either receive or transmit during less than 10% of the time, while for the other 90% of the time, the RF/ADC and PHY blocks would be idle.


Power Saving Schemes According to the Invention (MoCA 1.1 Compliant)


In this section, power consumption of a MoCA EN is estimated when it is in a standby state. Three levels of power saving modes are identified, according to the invention. Implementation of the modes may depend on interoperability requirements:

  • 1. A MoCA 1.1 network where the NC is not a node according to the invention


In this mode the MoCA Core acts as a node in the running state with no data to transmit or receive. The core can be on its PHY/RF idle mode about 85% of the time. When idle, the clock is gated and RF is powered down. PLLs and ADC cannot be powered down due to longer power up times.


In such a mode, the MAP cycle is assumed to be about 1 millisecond on average.

  • 2. A MoCA network where the NC is a node according to the invention—in one embodiment that may be configurable in standby states according to the invention—but ENs can be either nodes according to the invention or other conventional nodes


In this mode the NC can adapt the MAP cycle to network activity by increasing MAP cycle duration (up to 2.5 milliseconds allowed by the MoCA specifications) and lowering the periodicity of the ROs to a single RO per MAP CYCLE for nodes according to the invention that are in standby state (can be even lower when only nodes according to the invention are on the network). When the NC discovers activity on the network it can return to level 1.


In this mode, when no data is transmitted over the network, ENs could leave idle mode once in 2.5 milliseconds, PLLs and RFs are powered down in addition to gating the clock. The ADC cannot be powered down except when its power up time has improved significantly.


This mode is preferably fully compliant with the MoCA 1.1 and can interoperate with conventional nodes. However, when conventional nodes are admitted on the network, the NC according to the invention may require more power to support them.

  • 3. A MoCA 1.1 protocol where the NC and all nodes are nodes according to the invention


In one embodiment of the invention, this mode enables the nodes according to the invention to be awakened only once in a predetermined time—e.g., 10 milliseconds—to further reduce power consumption. Both PLLs and ADC may preferably be powered down in this mode. A message passing method according to the invention, preferably compliant with MoCA 1.1 specification may be applied (see description below for more detail).


Thus, power saving can be improved by switching the RF/ADC/PHY/MAC blocks efficiently between running and standby states, and by significantly reducing power consumption of these blocks when in standby state.


Table 7 depicts estimated power consumption on each of the power saving modes, wherein “proprietary” denotes a node that may be configured according to the standby state and modes set forth in Table 2:









TABLE 7







EN Power Savings Modes









Power Consumption (mW)















Current
w/gated
w/improved


Mode
NC
ENs
design
clock
ADC PD















1
Non-
Proprietary &
1370
1000
850



Proprietary
Non-Proprietary


2
Proprietary
Proprietary &
1210
420
210




Non-Proprietary


3
Proprietary
Proprietary only
1120
80
80









To simplify the discussion of the integration of the MoCA power saving, this application defines below in Table 8 four MoCA Core Power Saving states M0 to M3 that correspond to the open Advanced Configuration & Power Interface (“ACPI”) specifications [4] [www.acpi.info], which is hereby incorporated by reference herein in its entirety.











TABLE 8







Suitable




to receive


MoCA Core

Wakeup


Power State
Descriptions
Interrupt







M0 -
MoCA Core is running.
No


Running
Full network capabilities.



Analog parts could be powered up/down on schedule.


3M1 -
MoCA Core timers only are always on.
Yes


Standby
The other blocks of the MoCA Core wake up on timer



interrupts to handle MoCA Control traffic only (e.g.,



Beacons, MAPS and RRs), to keep the MoCA Core



“virtually” connected.



MoCA Core filters ingress MoCA frames and asserts a



Wake-up interrupt for Wake-up frames.



Maximum power saving if the NC node is a Broadcom node.



Minimum power saving if the node is not a Broadcom node.


M3 - Down
MoCA core is powered down. No network connection.
No



Full reboot is required to reenter the running state.









Table 9 below sets forth the possible transitions from Power Saving modes and their associated commands:














TABLE 9







From
M0 Running
M1 Standby
M3 Power



To
State
(Active or Idle)
Down









M0

Host Request
Host Reboot



M1
Host Request




M3
Host Request











This section details the embodiment for power saving techniques, according to the invention, in the case where the entire MoCA network includes nodes according to the invention. This mode is preferably MoCA 1.1 compliant; however, it may rely on proprietary messaging that runs over the MoCA 1.1 protocol.



FIG. 2 shows a schematic diagram of an operational sequence of an EN entering standby state.


Step 201 shows the EN sending a request to the NC to enter standby state by asserting the bit associated with its node_ID into the Standby Vector (SV) Information Element of its Null (i.e. no transmission opportunity is requested) Reservation Request Frame.


Step 202 shows the NC acknowledging the EN's standby transition request by asserting the bit associated with the node_ID of the requester EN into the Standby Vector (SV) Information Element of the MAP frame. This is shown by the ACK message along the curved, hatched line that is adjacent the running NC line.


The NC preferably reduces the periodicity of the scheduled ROs for the suspended node to one RO per Beacon period.


Step 203 shows that, in the last MAP frame before the Beacon, the NC asserts in the Next MAP Vector (NV) Information Element all the bits associated with standby nodes. This assertion indicates to the running nodes that a transmission request to a standby node can be made in the next scheduled Request Opportunities. These transmissions can be made because Standby Nodes will preferably receive and parse the MAP frame in the next MAP cycle. The EN toggles to active mode on the next scheduled Beacon to get the scheduled time of the next MAP frame and re-enters its idle mode. Thereafter, Step 204 shows the standby node receiving the Beacon. The Beacon indicates where the first MAP will be. The standby node can receive the 1st MAP frame (Step 205) scheduled by the beacon and can parse the MAP frame.


The repeat of steps 203 and 204 shows that, if the EN misses the MAP frame, it can retry on the next Beacon cycle.


Step 206 shows that the EN may send an RR (in MoCA 2.0) after the 1st MAP after the Beacon even if it has no pending frame to transmit.


In step 205, the MAP parsing generates two possible scenarios: If the bit associated with the next MAP Vector (NV) is asserted, the standby node should receive the next MAP (step 207). This scenario can repeat itself until the bit associated with the Next MAP Vector (NV) is de-asserted (step 208). Once the bit associated with the next MAP Vector (NV) is de-asserted, the standby node re-enters idle mode until the next scheduled Beacon (step 204) and ignore any remaining subsequent MAPs within the current Beacon period (steps 209). The curved, hatched lines along the left side of the Node S line indicate the various points at which the standby node has been instructed to be in active standby mode.



FIG. 3 shows a schematic diagram of an operational sequence of an EN re-entering running state. When the system elects to send a packet over the MoCA network, the system may indicate to the MoCA Node a Standby (M1) to Running (M0) State transition.


The following description corresponds to the exemplary steps shown in FIG. 3. Step 301 shows the EN getting an M1 standing to M0 running request from an external source (the upper layer of the host entity), i.e., the system on which the node is located.


Step 302 shows the EN sending a request to the NC that the node to re-enter Running State by de-asserting the bit associated with its node_ID into the Standby Vector (SV) Information Element of its Reservation Request Frame.


Step 303 shows the NC acknowledges the EN's transition by de-asserting the bit associated with the node_ID of the requester EN into the Standby Vector (SV) Information Element of the MAP frame.



FIG. 4 shows a schematic diagram of another embodiment of an EN/NC that wants to transfer a frame to EN(s) in standby state, as shown in step 401. The following description corresponds to the exemplary steps shown in FIG. 4.


The running EN/NC is typically aware: a) which destination nodes are in Standby State (from the Standby Node Vector (SV) in MAP Frames), and b) the nature of the 802.3 frame to be transmitted—e.g., Unicast (single node recipient), Multicast (plurality of preferably selected recipients) or Broadcast (send to all nodes).


Step 402 shows that, for a MAC Unicast and/or a MAC Broadcast frame, the requesting EN(s) await(s) the assertion of the bit associated with the destination node ID in the Next MAP Vector (NV) in the MAP frame to send a Reservation Request for the pending transmission in its next scheduled RR 403.


For MAC Multicast frame, the EN can ignore standby nodes, as standby nodes are typically not members of any Multicast groups. Generally, in methods according to the invention, nodes de-register from any Multicast group upon transitioning to standby state.


Step 404 shows that the NC can grant the RRs in the MAP following the Beacon. If the NC cannot grant a request in the next MAP cycle, the NC may grant a request in the subsequent MAP cycle(s) by indicating to a node to receive the subsequent MAP frame(s). In one embodiment of the invention, the NC may provide an indication by keeping the bit associated with the destination node ID asserted in the Next MAP Vector (NV) in the MAP frame.


Step 405 shows the transmission to the node in standby node. The Standby node can toggle to active/idle modes within standby to receive any scheduled event and toggle to idle mode before scheduled events. The Beacon indicates when the MAP frame is scheduled. The standby nodes can then receive the MAP frame and parse it.


If more transmissions are pending, the NC may schedule transmissions in the MAP cycles subsequent to the first MAP following the Beacon transmission by keeping the bit associated with the recipient standby nodes asserted in the Next MAP Vector (NV) of the MAP frames.


Certain aspects of the invention relate to transmit and NC MoCA Node handling in a mixed MOCA network of nodes in Standby and Running states.


A running node can transmit 3 types of MAC frames: Unicast, Multicast, and Broadcast.


It should be noted that the extraction of the MAC address type of the IEEE 802.3 ingress frames is supported by the device hardware and software readable to the requester


The table below lists all possible transmission cases and one embodiment according to the invention of their respective TX and NC handling.











TABLE 10





Transmission




Possibilities
Type
Handling







Unicast
MAC Unicast
Normal Tx


Broadcast
MAC Broadcast
Delayed Rx: (wait for Standby nodes




to be active)




Wait for IE NM = 1 in MAP before




requesting RR for Tx


Multicast/
MAC Multicast
Ignore Standby Nodes


Broadcast
(MoCA Broadcast)
(No Multicast Members on Standby




Nodes)




Normal Tx









Another aspect of the invention relates to an NC entering Standby State. An NC that is entering standby state should preferably initiate an NC handoff with one of the running ENs of the network. If the NC is the last running node of the network, it could enter its standby state and:

  • (1) extend its MAP cycle to send only one (or two to compensate time) MAP per beacon period (of every 10 ms, nominal, or of other suitable duration); and/or
  • (2) whenever a node on the network indicates that it re-entered its Running State, the NC can also re-enter its Running State.


Yet another aspect of the invention relates to a system referred to herein as “Wakeup on MoCA (‘WoM’).”


Table 11 describes the WoM pattern filtering of a MoCA node.









TABLE 11







Wake on MOCA Frame Filtering Patterns








Frame type
WoM filtering pattern













MAC address
IPV4
ARP
Broadcast MAC DA + ARP ETH TYPE


resolution

(Broadcast)
(0x0806){(+TARGET PROTOCOL





ADDRESS)}



IPV6
Neighbor Discovery
MULTICAST MAC DA BIT




PROTOCOL MESSAGES
+IPV6 ETH TYPE (0X86DD)




(Multicast)
+IPV6 HEADER PARSING TO 1PV6





ICMP HEADER





+ICMP TYPE [133..137]




NEIGHBOR
{(+TARGET PROTOCOL ADDRESS)}




SOLICITATION




ROUTER




SOLICITATION




ROUTER




ADVERTISEMENT




REDIRECT




MSG




MULTICAST


Directed Frame


Unicast MAC DA bit


Magic Packet ™


Broadcast MAC DA (destination address) +





0xFFFFFFFFFFFf









The MAC Address Resolution preferably provides translation of an IP address to a MAC address. Using IPV6, the Multicast MAC DA (Destination Address) allows the node to be virtually connected even though the node is in standby state. This protocol may be implemented by signaling the reception of a few specific network protocol frames to a system in standby state. Such signaling allows the system to wake up and answer these frames, thereby preventing their respective network or transport protocols from timing out. Such IP specific frames may include 802.3 Unicast frames, IPv4 ARP frames, and/or IPV6 IGMPv6 Network Discovery Neighbor/Router Solicitation and Update Message frames. Such a technique, according to the invention, preferably precludes the need for a power management proxy and/or a special protocol.



FIG. 5 shows an exemplary embodiment of a system that may use the methods described herein to reduce power consumption in a MoCA network. FIG. 5 preferably includes a first TV display 502, a set top box 504, a second TV display 506 and second set top box 508. First set top box 504 and second set top box 506 may be connected by a coax network 510.


First set top box 504 includes a local storage 512. Such local storage may store movies on a hard disk or other suitable storage medium. Each of set top boxes 504 and 508 (or just first set top box 504) may be capable of a soft OFF which would place the set top box in a standby state according to the invention. A soft OFF button may be mounted on the front panel of the set top box or the IR remote.


In one embodiment of the invention, first set top box 504 may be in standby state. In this embodiment, second set top box 508 can access the hard drive on first set top box 504, for example, to play the movie stored on hard disk 512 of first set top box 504 on second TV display 506—even though first set top box 504 is in standby state.



FIG. 6 shows a schematic diagram of the operation of a standby state according to the invention. FIG. 6 shows that a standby node 602 according to the invention may be characterized such that the set top box stays active by listening to beacons 604 and the first MAP 606 following a Beacon. The relative time of the next MAP may be indicated in the beacons which are sent by the Network Controller in absolute time.


The rules, according to the invention, associated with a standby node may be as follows. The standby node may always be listed in a predetermined MAP—e.g., the first MAP frame after a beacon—and continue to listen to subsequent MAPs, as shown at 608, as the NV vector in the MAP frames indicate. When the NV vector indicates otherwise, the standby node 602 may not listen to MAPs in the current beacon period, or other predetermined beacon period, until the first MAP of the next beacon period.



FIG. 7 shows another schematic diagram of an operation of a node in standby state. In FIG. 7, following the first beacon 701, the standby node listens to only the first MAP 702 of the beacon period. Thereafter, the standby node returns to idle mode in response to the deasserted bit in the NM vector.


Following the second beacon 701, the standby node listens to the first MAP 703 and the second MAP 704 in response to the asserted bit in the NM vector of the first MAP 703 of the second beacon period. Thereafter, the standby node returns to idle mode in response to the deasserted bit in the NM vector of the second MAP 704.


Beacon 705 is shown as well. It should be noted that every MAP before the beacon typically has the bit in the NM vector asserted in order to cause the standby node to listen to the first MAP following the vector.


The foregoing analysis assumes that, apart from MoCA, refresh DDR and the Ethernet subsystem interfacing the MoCA core are ON, the latter consuming between 500 to 600 mW. MoCA is linked up but is mostly idle. Other embodiments of the invention reduce the power consumption of the Ethernet subsystem by waking it in response to an interrupt generated by the MoCA core applying the filtering described above.


Preferably, the invention could provide for remote access over the network while in standby state without any sideband method or protocol other than TCP/IP. Systems and methods according to the invention may adapt MoCA-based products to be Energy Star and EC Compliant, may provide for remote management capabilities of MoCA-based products while the products are in standby state, and may provide the products with substantially instantaneous return to full functional mode from standby state.


In the MoCA 1.1 specification, a non-active node to the network is either left fully active even in case of no activity or shut down to save energy. Re-entering the network requires the full admission process which lasts several seconds.


Several organizations, among them the EC (European Commission) and Energy Star organization in the US, are writing recommendations to reduce total energy consumptions in homes. Among others, STBs, digital TVs and other Video/networking devices are considered. In particular, they include recommendations for power efficient standby states for STBs, as these devices are expected to be in a non operating state most of the time.


Networked devices, like networked STBs, should desirably maintain their network alive even when in a power saving mode, to enable waking up remote nodes. Both Energy Star and the EC provide recommendations for networked devices that are in Standby state but need to maintain their network on.



FIG. 8 shows a schematic diagram of power dependence for a network device in a system according to the invention. Specifically, FIG. 8 shows the coupling of a memory module 802, a bus 804, a conventional NIC (Network Interface Controller) 806 and a MoCA NIC 808 according to the invention. In order for the NICs 806 and/or 808 to function, the NICs need to be able to save into memory module 802 and pull from memory module 802. In addition, bus 804 should be powered in order to facilitate communication between NICs 806 and/or 808 and memory 802.


When a NIC transitions to a running state, it typically immediately begins transmitting data. Therefore, in order to transition from a standby state to a running state, memory 802 and bus 804 must first be powered up prior to the powering up of NICs 806 and/or 808.


Step 902 shows an M1 Power State request directed from a host to the MoCA adapter of the MoCA node 902. Thereafter, the WoM filtering is implemented to determine whether a wakeup signal from the host internal control is included in the Power State Request, as shown at step 904. The wakeup signal is used to indicate to the system the reception of a frame of interest for the system (a frame upper layer network protocol should handle and answer to prevent protocol time out). As a result of the wakeup signal, the system may first power the system modules needed to receive the frame retained by the MoCA device (such powering the memory, then the data bus connected to the MoCA device in order to transition from B1 to B0 state), as shown as 906 and 908. At step 910, upon completion of this sequence (based on the exemplary power dependency described in FIG. 8.), the MoCA device may be requested to re-enter from M1 to M0 power state. At step 912, the MoCA device has re-entered M0 state and could deliver the received frame to the system memory for handling by the higher layer entities.


Yet another aspect of the invention relates to Power Management Messages. Power Management MoCA Management Protocol (“MMP”) messages according to the invention may be sent by the host to request the MoCA Node to transition from one Power Mode State to another. Such messages may include the following:

    • Running State (M0) to Sleeping State (M1);
    • Running State (M0) to Down State (M3); and
    • Sleeping State (M1) to Running State (M0).


The MoCA Core response to the transition request indicates the status of the transition. If the transition was successful within the MoCA processing core—i.e., the processing module associated with MoCA functions—the response returns a success status. Otherwise, the response can return a rejection status and the reason for the rejection.


A MoCA Wakeup frame from a host system may trigger a transition request at the MoCA core from Standby State (M1) to Running State (M0).



FIG. 10 shows a schematic diagram of active standby/idle standby mode transition for a MoCA node participating in a periodic Link Maintenance Operation (“LMO”) according to the invention. Lines 1002, 1004 show the transitioning of a node in standby state as it participates in an LMO. Time line 1006 shows that, when another node has assumed the position of LMO node, the standby node only has to be in active mode for durations 1010 and 1012. It should be noted that during duration 1010, which is expanded in greater detail at 1008, standby node only has to be active for the probe periods and to provide a probe report. Putting the standby node in idle state during the latency periods can provide added power savings. The time between each probe is typically 20-350 milliseconds plus a latency of about 10 milliseconds (for beacon synchronization). Finally, the standby node should remain active during LMO GCD (the determination of Greatest Common Density period), in which scheduling the active/idle time of the standby node becomes too complex.


When the M1 node assumes the position of LMO node, then the LMO stays in active mode for the entire LMO process (toggling to idle mode may produce insignificant power saving in regard to the active/idle mode ratio during LMO node sequence).


The distance between each probe is typically 20-350 milliseconds+a latency of about 10 milliseconds (for beacon synchronization).


In certain embodiments of the invention, an NC can select an M1 Node to be the LMO node at reduced periodicity. For example, in a network of only two nodes, the NC can select an M1 Node at the same periodicity that exists in a full 16 node network. The Period for the LMO=(16×LMO sequence (˜0.5 sec per node)+T6 (1 sec))=9 sec. When the M1 node is selected as the LMO Node, the M1 node can stay ON for the whole LMO sequence. When the M1 node is selected as an “Other Node”, the M1 node can fully participate in the LMO in ON/IDLE mode to minimize power consumption. Such limited selection of the M1 node can preferably save power consumption.


Yet another aspect of the invention relates to Power Management Protocol Information Elements. The Standby Vector (SV) Protocol Information Element can be added to:


1. a Reservation Request frame by an EN as a request to transition to a standby state or a request to transition to a running state. This request may be initiated by the host requesting the node to transition from Running State (M0) to Standby State (M1) or vice-versa from standby state (M1) to running state (M0). In order to trigger such a request, the node can assert the bit associated with its node ID in the Standby Vector.


2. a MAP frame by the NC to indicate to all the nodes of the MoCA network the Power State of each node. An asserted bit in the Standby Vector indicates that the node with the associated node_ID is in Standby State. A de-asserted bit indicates that the node with the associated node_ID is in Running State.


[0163] The Next MAP Vector (NV) Protocol Information Element can be added to: a MAP frame by the NC to indicate:


1. to all the running nodes of the MoCA network if reservation requests to transmit to standby nodes could be made in the next scheduled RRs. An asserted bit in the Next MAP Vector indicates that reservation to transmit to the node with the associated node_ID could be made in the next scheduled RR. A de-asserted bit indicates that reservation to transmit to the node with the associated node_ID could not be made.


2. to selected standby nodes that they should reactivate themselves in time to receive the next scheduled MAP frame. An asserted bit in the Standby Vector indicates that the node with the associated node_ID should receive the next MAP frame. A de-asserted bit indicates that the node with the associated node_ID that no more MAP frames should be received within the current Beacon Period.


Table 12 sets forth an embodiment of the Standby Vector Protocol Information Element and Next MAP Vector Protocol according to the invention.









TABLE 12







Standby Vector Protocol Information Element









Field
Length
Usage





Protocol IE Header
4 bits
Pre-determined value to determine which frame type










4 bits
Pre-determined value to determine which frame type



6 bits
1



2 bits
Type III









Protocol IE Payload
16 bits 
Bitmask. Each bit of the bitmask is associated with a











node_ID - LSB is node 0.




Bit_i=1: in MAP: Node_i is in standby state











in RR: transition to standby state request











Bit_i=0:in MAP: Node_i is in running state











in RR: transition to running state request










16 bits 
For Running State: Indicates sending an RR in the next




MAP cycle




For Standby: Indicates where to stay awake for the next




MAP




Bitmask. Each bit of the bitmask is associated with a




node_ID - LSB is node 0.




This Vector is meaningful only for the nodes set in




Standby Node Vector




Bit_i=1: Indicates that RR allocated to Node i may be




requested in the next MAP cycle




Bit_i=0: Indicates that RR allocated to Node i should




not be requested in the next MAP cycle










Network Management for Node in Standby State


Link Management Operation (LMO)


The NC should reduce the frequency in which it selects a node in Standby State NC to be the “LMO node.” The LMN node is typically used to determine GCD (Greatest Common Density period). Link management protocol in general may be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks.


The node in standby state, according to the invention, can participate as a node in running state in all the MoCA Network Management Protocol (LMO, topology update, privacy, etc.). There is a difference within standby state. A node in standby state is not required to be selected as an LMO node (master or the LMO) at the same frequency as a node in running state. Rather, a node in standby state can stay in active mode during the whole interval that it is the selected LMO node and can toggle between active and idle mode when it is a slave to “another” LMO mode. The details of the operation of an LMO node according to the invention are shown below in the portion of the specification corresponding to FIG. 10.



FIG. 11 shows a single or multi-chip module 1102 according to the invention, which can be one or more integrated circuits, in an illustrative data processing system 1100 according to the invention. Data processing system 1100 may include one or more of the following components: I/O circuitry 1104, peripheral devices 1106, a processor 1108 and memory 1110. These components are coupled together by a system bus or other interconnections 1112 and are populated on a circuit board 1120 which is contained in an end-user system 1130. System 1100 may be configured for use in a cable television tuner according to the invention. It should be noted that system 1100 is only exemplary, and that the true scope and spirit of the invention should be indicated by the following claims.


Thus, systems and methods for providing a MoCA power management strategy have been described.


Aspects of the invention have been described in terms of illustrative embodiments thereof. A person having ordinary skill in the art will appreciate that numerous additional embodiments, modifications, and variations may exist that remain within the scope and spirit of the appended claims. For example, one of ordinary skill in the art will appreciate that the steps illustrated in the figures may be performed in other than the recited order and that one or more steps illustrated may be optional. The methods and systems of the above-referenced embodiments may also include other additional elements, steps, computer-executable instructions, or computer-readable data structures. In this regard, other embodiments are disclosed herein as well that can be partially or wholly implemented on a computer-readable medium, for example, by storing computer-executable instructions or modules or by utilizing computer-readable data structures.

Claims
  • 1. A network over coaxial cable, the network comprising: a network controller;a plurality of networked nodes, each of the networked nodes comprising an integrated circuit, each of the integrated circuits comprising a plurality of circuit blocks;wherein each of the networked nodes has a power state and is configurable to change the power state between:a running power state; anda standby power state, the standby power state including an active mode and an idle mode,wherein:the running power state is associated with higher power consumption than the active mode and the idle mode;the active mode is associated with higher power consumption than the idle mode;in the active mode, a networked node is configured to transmit and/or receive packets of Information, wherein the packets of information include at least one Media Access Plan (MAP), and the networked node is configured to receive the at least one MAP;in the idle mode, the networked node is configured to maintain a link to the network while powering down a portion of the circuit blocks, thereby reducing power consumption of the networked node, and the networked node is configured to ignore MAPs; andat least one of the networked nodes is configurable to: send a request to the network controller to change the power state of the at least one of the networked nodes,receive a grant from the network controller in response to the request, andchange the power state of the at least one of the networked nodes in response to receiving the grant.
  • 2. The network of claim 1 wherein each of the networked nodes is configurable to: switch from the idle mode to the active mode after a pre-determined number of MAPs, andreceive an interrupt signal via the link to the network.
  • 3. The network of claim 1 wherein each of the networked nodes is configurable to switch from the idle mode to the active mode following a network beacon signal.
  • 4. The network of claim 1 wherein the portion of the circuit blocks includes a clock portion that provides a clock signal to a digital physical layer.
  • 5. The network of claim 1 wherein the portion of the circuit blocks includes a clock portion that provides a clock signal to a Media Access Controller layer.
  • 6. The network of claim 1, wherein, in the active mode and the idle mode, the networked node is configured to receive a network beacon signal.
  • 7. The network of claim 1, wherein the networked node is configured to participate in a link maintenance operation (LMO).
  • 8. The network of claim 1, wherein, during a link maintenance operation (LMO), in the active mode, the networked node is configured to receive at least one probe from an LMO node.
  • 9. In a home network having a plurality of network modules each of said plurality of network modules having a power state, one of said plurality of network modules being a network controller, each of said plurality of network modules being connected to a coax backbone, a method for communicating over the coax backbone between the plurality of network modules, the method comprising: using the network controller to receive at least one request, said request being sent over the coax backbone from the plurality of network modules, said request for changing the power state of at least one of the network modules and for requesting bandwidth to transmit bursts;using the network controller to establish an order of transmission opportunities for the plurality of network modules to follow when transmitting bursts directly to other network modules via the coax backbone; andusing the network controller to respond to the request to change the power state of at least one of the network modules between a running power state and a standby power state, the standby power state including an active mode and an idle mode;wherein:the running power state is associated with higher power consumption than the active mode and the idle mode;the active mode is associated with higher power consumption than the idle mode;in the active mode, a networked node is configured to transmit and/or receive packets of information, wherein the packets of information include at least one Media Access Plan (MAP), and the networked node is configured to receive the at least one MAP; andin the idle mode, the networked node is configured to maintain a link to the network while powering down a portion of the networked node, thereby reducing power consumption of the networked node, and the networked node is configured to ignore MAPs.
  • 10. The method of claim 9 further comprising: switching a network module from the idle mode to the active mode after a pre-determined number of MAPs, andswitching the network module from the idle mode to the active mode following a network beacon signal.
  • 11. The method of claim 9 further comprising configuring a network module to receive an interrupt signal via the link to the network.
  • 12. The method of claim 9 further comprising gating a clock signal that is provided to a digital physical layer.
  • 13. The method of claim 9 further comprising gating a clock signal that is provided to a Media Access Controller (MAC) layer clock signal.
  • 14. The method of claim 9, further comprising using the network controller to send a network beacon signal to the at least one of the networked modules.
  • 15. A method for operating a networked node on a network over coaxial cable, the network comprising a network controller and a plurality of networked nodes, each of the networked nodes comprising an integrated circuit, each of the integrated circuits comprising a plurality of circuit blocks, the networked node having a power state, the method comprising: configuring a power state of a first networked node to be in a running power state; andchanging the power state to a standby power state or changing the power state to a sleep power state,wherein the changing the power state or the standby power state comprises: using the first networked node to request from the network controller a change in the power state to the standby power state, wherein the standby power state includes an active state and an idle state;in response to the request to change to the standby power state from the running power state, receiving a first signal from the network controller, and in response to receiving the first signal from the network controller, switching the first networked node to the standby power state;wherein the changing the power state to the sleep power state comprises: using the first networked node to request from the network controller a change in the power state to the sleep power state; andin response to the request to change to the sleep power state from the running power state, receiving a second signal from the network controller, and, in response to receiving the second signal from the network controller, switching the first networked node to the sleep power state from the running power state after receiving the second signal from the network controller,wherein:the running power state is associated with higher power consumption than the active state and the idle state;the active state is associated with higher power consumption than the idle state;in the active state, the first networked node is configured to receive at least one Media Access Plan (MAP); andin the idle state, the first networked node is configured to maintain a link to the network and is configured to ignore MAPs.
  • 16. The method of claim 15 wherein at least one of the networked nodes is configurable to: switch from the idle state to the running power state after a pre-determined number of MAPs, andswitch from the idle state to the running power state following a network beacon signal.
  • 17. The method of claim 15 wherein the first networked node is configurable to receive an interrupt signal via a link to the network.
  • 18. The method of claim 15 wherein: the plurality of circuit blocks comprises a clock portion, andin the idle state, the first networked node powers down the clock portion that provides a clock signal to a digital physical layer.
  • 19. The method of claim 15: the plurality of circuit blocks comprises a clock portion, andin the idle state, the first networked node powers down the clock portion that provides a clock signal to a Media Access Controller layer.
  • 20. A method for operating a networked node on a network over coaxial cable, the network comprising a network controller and a plurality of networked nodes, each of the networked nodes comprising an integrated circuit, each of the integrated circuits comprising a plurality of circuit blocks having a power state, the method comprising: configuring a power state of a first networked node to be in a running power state;changing the power state to a standby power state or changing the power state to an idle power state,wherein the changing the power state to the standby power state comprises: using the first networked node to request from the network controller a change in the power state to the standby power state;in response to the request to change to the standby power state from the running power state, receiving a first signal from the network controller, and, in response to receiving the first signal from the network controller, switching the first networked node to the standby power state from the running power state after receiving the first signal from the network controller;wherein the changing the power state to the idle power state comprises: using the first networked node to request from the network controller a change in the power state to the idle power state; andin response to the request to change to the idle power state from the running power state, receiving a second signal from the network controller, and, in response to receiving the second signal from the network controller, switching the first networked node to the idle power state from the running power state after receiving the second signal from the network controller,wherein:the running power state is associated with higher power consumption than the standby power state and the idle power state;the standby power state is associated with higher power consumption than the idle power state;in the standby power state, the first networked node is configured to receive at least one Media Access Plan (MAP); andin the idle power state, the first networked node is configured to maintain a link to the network and is configured to ignore MAPs.
CROSS-REFERENCED TO RELATED APPLICATIONS

This application claims priority from U.S. Provisional Patent No. 61/085,096, filed Jul. 31, 2008, entitled “MoCA Power Management” and U.S. Provisional Patent Application No. 61/187,616, filed on Jun. 16, 2009, entitled “Systems and Methods for Providing a MoCA Power Management Strategy.”

US Referenced Citations (236)
Number Name Date Kind
3836888 Boenke et al. Sep 1974 A
4413229 Grant Nov 1983 A
4536875 Kume et al. Aug 1985 A
4608685 Jain et al. Aug 1986 A
4893326 Duran et al. Jan 1990 A
5052029 James et al. Sep 1991 A
5170415 Yoshida et al. Dec 1992 A
5343240 Yu Aug 1994 A
5421030 Baran May 1995 A
5440335 Beveridge Aug 1995 A
5570355 Dail et al. Oct 1996 A
5638374 Heath Jun 1997 A
5671220 Tonomura Sep 1997 A
5796739 Kim et al. Aug 1998 A
5802173 Hamilton-Piercy et al. Sep 1998 A
5805591 Naboulsi et al. Sep 1998 A
5805806 McArthur Sep 1998 A
5815662 Ong Sep 1998 A
5822677 Peyrovian Oct 1998 A
5822678 Evanyk Oct 1998 A
5845190 Bushue et al. Dec 1998 A
5850400 Eames et al. Dec 1998 A
5854887 Kindell et al. Dec 1998 A
5856975 Rostoker et al. Jan 1999 A
5877821 Newlin et al. Mar 1999 A
5886732 Humpleman Mar 1999 A
5896556 Moreland et al. Apr 1999 A
5917624 Wagner Jun 1999 A
5930493 Ottesen et al. Jul 1999 A
5963844 Dail Oct 1999 A
5982784 Bell Nov 1999 A
6009465 Decker et al. Dec 1999 A
6028860 Laubach et al. Feb 2000 A
6055242 Doshi et al. Apr 2000 A
6069588 O'Neill, Jr. May 2000 A
6081519 Petler Jun 2000 A
6081533 Laubach et al. Jun 2000 A
6111911 Sanderford et al. Aug 2000 A
6118762 Nomura et al. Sep 2000 A
6157645 Shobatake Dec 2000 A
6167120 Kikinis Dec 2000 A
6192070 Poon et al. Feb 2001 B1
6219409 Smith et al. Apr 2001 B1
6229818 Bell May 2001 B1
6243413 Beukema Jun 2001 B1
6304552 Chapman et al. Oct 2001 B1
6307862 Silverman Oct 2001 B1
6434151 Caves et al. Aug 2002 B1
6466651 Dailey Oct 2002 B1
6481013 Dinwiddie et al. Nov 2002 B1
6526070 Bernath Feb 2003 B1
6553568 Fijolek et al. Apr 2003 B1
6563829 Lyles et al. May 2003 B1
6567654 Coronel Arredondo et al. May 2003 B1
6611537 Edens et al. Aug 2003 B1
6622304 Carhart Sep 2003 B1
6637030 Klein Oct 2003 B1
6650624 Quigley et al. Nov 2003 B1
6745392 Basawapatna et al. Jun 2004 B1
6763032 Rabenko et al. Jul 2004 B1
6785296 Bell Aug 2004 B1
6816500 Mannette et al. Nov 2004 B1
6831899 Roy Dec 2004 B1
6836515 Kay et al. Dec 2004 B1
6859899 Shalvi et al. Feb 2005 B2
6862270 Ho Mar 2005 B1
6877043 Mallory et al. Apr 2005 B2
6877166 Roeck et al. Apr 2005 B1
6898210 Cheng et al. May 2005 B1
6930989 Jones, IV et al. Aug 2005 B1
6940833 Jonas et al. Sep 2005 B2
6950399 Bushmitch et al. Sep 2005 B1
6961314 Quigley et al. Nov 2005 B1
6985437 Vogel Jan 2006 B1
6996198 Cvetkovic Feb 2006 B2
7035270 Moore et al. Apr 2006 B2
7065779 Crocker et al. Jun 2006 B1
7079571 Chen Jul 2006 B1
7089580 Vogel et al. Aug 2006 B1
7116685 Brown et al. Oct 2006 B2
7127734 Amit Oct 2006 B1
7133697 Judd et al. Nov 2006 B2
7142553 Ojard et al. Nov 2006 B1
7146632 Miller Dec 2006 B2
7149220 Beukema et al. Dec 2006 B2
7194041 Kadous Mar 2007 B2
7292527 Zhou et al. Nov 2007 B2
7296083 Barham et al. Nov 2007 B2
7327754 Mills et al. Feb 2008 B2
7372853 Sharma et al. May 2008 B2
7460543 Malik et al. Dec 2008 B2
7487532 Robertson et al. Feb 2009 B2
7532642 Peacock May 2009 B1
7532693 Narasimhan May 2009 B1
7555064 Beadle Jun 2009 B2
7574615 Weng et al. Aug 2009 B2
7606256 Vitebsky et al. Oct 2009 B2
7652527 Ido et al. Jan 2010 B2
7653164 Lin et al. Jan 2010 B2
7664065 Lu Feb 2010 B2
7675970 Nemiroff et al. Mar 2010 B2
7822060 Sterenson et al. Oct 2010 B2
7860092 Yoon et al. Dec 2010 B2
7916756 Atsumi et al. Mar 2011 B2
8160490 Min et al. Apr 2012 B2
8174999 Kliger et al. May 2012 B2
8184550 Beck et al. May 2012 B2
8266265 Liu et al. Sep 2012 B2
20010039660 Vasilevsky Nov 2001 A1
20020010562 Schleiss et al. Jan 2002 A1
20020021465 Moore et al. Feb 2002 A1
20020041199 Ekelund Apr 2002 A1
20020059623 Rodriguez et al. May 2002 A1
20020059634 Terry et al. May 2002 A1
20020069417 Kliger Jun 2002 A1
20020078247 Lu et al. Jun 2002 A1
20020078249 Lu et al. Jun 2002 A1
20020097821 Hebron et al. Jul 2002 A1
20020105970 Shvodian Aug 2002 A1
20020136231 Leatherbury Sep 2002 A1
20020141347 Harp et al. Oct 2002 A1
20020150155 Florentin et al. Oct 2002 A1
20020166124 Gurantz et al. Nov 2002 A1
20020174423 Fifield et al. Nov 2002 A1
20020194605 Cohen et al. Dec 2002 A1
20030013453 Lavaud et al. Jan 2003 A1
20030016751 Vetro et al. Jan 2003 A1
20030022683 Beckmann et al. Jan 2003 A1
20030060207 Sugaya et al. Mar 2003 A1
20030063563 Kowalski Apr 2003 A1
20030066082 Kliger Apr 2003 A1
20030073438 Fukushima et al. Apr 2003 A1
20030099253 Kim May 2003 A1
20030152059 Odman Aug 2003 A1
20030165142 Mills et al. Sep 2003 A1
20030169769 Ho et al. Sep 2003 A1
20030193619 Farrand Oct 2003 A1
20030198244 Ho et al. Oct 2003 A1
20040004934 Zhu et al. Jan 2004 A1
20040037366 Crawford Feb 2004 A1
20040047284 Eidson Mar 2004 A1
20040107445 Amit Jun 2004 A1
20040163120 Rabenko et al. Aug 2004 A1
20040172658 Rakib et al. Sep 2004 A1
20040177381 Kliger Sep 2004 A1
20040224715 Rosenlof et al. Nov 2004 A1
20040258062 Narvaez Dec 2004 A1
20050015703 Terry et al. Jan 2005 A1
20050097196 Wronski et al. May 2005 A1
20050152350 Sung et al. Jul 2005 A1
20050152359 Giesberts et al. Jul 2005 A1
20050175027 Miller et al. Aug 2005 A1
20050204066 Cohen et al. Sep 2005 A9
20050213405 Stopler Sep 2005 A1
20060059400 Clark et al. Mar 2006 A1
20060062250 Payne, III Mar 2006 A1
20060068708 Dessert et al. Mar 2006 A1
20060078001 Chandra et al. Apr 2006 A1
20060104201 Sundberg et al. May 2006 A1
20060256799 Eng Nov 2006 A1
20060256818 Shvodian et al. Nov 2006 A1
20060268934 Shimizu et al. Nov 2006 A1
20060280194 Jang et al. Dec 2006 A1
20070025317 Bolinth et al. Feb 2007 A1
20070040947 Koga Feb 2007 A1
20070064720 Sterenson et al. Mar 2007 A1
20070127373 Ho et al. Jun 2007 A1
20070160213 Un et al. Jul 2007 A1
20070171919 Godman et al. Jul 2007 A1
20070183786 Hinosugi et al. Aug 2007 A1
20070206551 Moorti et al. Sep 2007 A1
20070217436 Markley et al. Sep 2007 A1
20070253379 Kumar et al. Nov 2007 A1
20070286121 Kolakowski et al. Dec 2007 A1
20080037487 Li et al. Feb 2008 A1
20080037589 Kliger Feb 2008 A1
20080080369 Sumioka et al. Apr 2008 A1
20080089268 Kinder et al. Apr 2008 A1
20080117919 Kliger May 2008 A1
20080117929 Kliger May 2008 A1
20080130779 Levi Jun 2008 A1
20080162770 Titiano et al. Jul 2008 A1
20080178229 Kliger Jul 2008 A1
20080189431 Hyslop et al. Aug 2008 A1
20080225832 Kaplan et al. Sep 2008 A1
20080238016 Chen et al. Oct 2008 A1
20080250133 Lee et al. Oct 2008 A1
20080259957 Kliger Oct 2008 A1
20080271094 Kliger Oct 2008 A1
20080273591 Brooks et al. Nov 2008 A1
20080279219 Wu et al. Nov 2008 A1
20080298241 Ohana Dec 2008 A1
20090010263 Ma et al. Jan 2009 A1
20090063878 Schmidt et al. Mar 2009 A1
20090092154 Malik et al. Apr 2009 A1
20090106801 Horii Apr 2009 A1
20090122901 Choi et al. May 2009 A1
20090165070 McMullin Jun 2009 A1
20090204837 Raval et al. Aug 2009 A1
20090217325 Kliger Aug 2009 A1
20090252172 Hare Oct 2009 A1
20090254794 Malik et al. Oct 2009 A1
20090257483 French et al. Oct 2009 A1
20090279643 Shusterman Nov 2009 A1
20090285212 Chu et al. Nov 2009 A1
20090296578 Bernard et al. Dec 2009 A1
20090316589 Shafeeu Dec 2009 A1
20100080312 Moffatt et al. Apr 2010 A1
20100142378 Matheney et al. Jun 2010 A1
20100142540 Matheney et al. Jun 2010 A1
20100146616 Garrett et al. Jun 2010 A1
20100150016 Barr Jun 2010 A1
20100158013 Kliger Jun 2010 A1
20100158015 Wu Jun 2010 A1
20100158021 Kliger Jun 2010 A1
20100158022 Kliger Jun 2010 A1
20100162329 Ford et al. Jun 2010 A1
20100174824 Aloni et al. Jul 2010 A1
20100180171 Liu et al. Jul 2010 A1
20100185731 Wu Jul 2010 A1
20100185759 Wu Jul 2010 A1
20100214916 Wu et al. Aug 2010 A1
20100238932 Kliger Sep 2010 A1
20100246586 Ohana Sep 2010 A1
20100254278 Kliger Oct 2010 A1
20100254402 Kliger Oct 2010 A1
20100281195 Daniel et al. Nov 2010 A1
20100284474 Kliger Nov 2010 A1
20100290461 Kliger et al. Nov 2010 A1
20100322134 Wu Dec 2010 A1
20110001833 Grinkemeyer et al. Jan 2011 A1
20110013633 Klein et al. Jan 2011 A1
20110080850 Klein et al. Apr 2011 A1
20110205891 Kliger et al. Aug 2011 A1
20110206042 Tarrab et al. Aug 2011 A1
20110310907 Klein et al. Dec 2011 A1
Foreign Referenced Citations (16)
Number Date Country
1422043 Jun 2003 CN
1588827 Aug 2004 CN
1703871 Nov 2005 CN
0 385695 Sep 1990 EP
0 622926 Nov 1994 EP
1501326 Jan 2005 EP
60160231 Aug 1985 JP
200824326 Jun 2008 TW
WO 9827748 Jun 1998 WO
WO 9831133 Jul 1998 WO
WO 9935753 Jul 1999 WO
WO 9946734 Sep 1999 WO
WO 0031725 Jun 2000 WO
WO 0055843 Sep 2000 WO
WO 0180030 Oct 2001 WO
WO 0219623 Mar 2002 WO
Non-Patent Literature Citations (7)
Entry
Ovadia S., “MoCA: Ubiquitous Multimedia Networking in the Home,” Proceedings of the SPIE—The International Society for Opitcal Engineering SPIE—The International Society for Optical Engineering USA, [Online] 2007, XP002584642 ISSN: 0277-786X; Retrieved on Jul. 28, 2010 from the Internet: URL: http://spiedl.aip.org/getpdf/servlet/getPDFServlet?filetype=pdf&id=PSISDG00677600000167760C0000&idtype=cvips&prog=normal>, as cited in European Search Report.
International Search Report for International Application No. PCT/US03/27253 dated Dec. 30, 2003 (4 pgs.).
International Search Report for International Application No. PCT/US03/27254 dated Feb. 3, 2004 (5 pgs.).
Multichannel News , MoCA Brewing Up Bigger Bandwidth, Dec. 15, 2008 Interview with CTO Anton Monk, http://www.multichannel.com/article/160876-MoCa—Brewing—Up—bigger—Bandwidth.php downloaded on Mar. 29, 2009.
European Search Report for Application No. EP 09 00 9926 mailed Aug. 6, 2010.
“Home Networking on Coax for Video and Multimedia, Overview for IEEE 802.1AVB”, Shlomo Ovadia, San Ramon/California, May 30, 2007.
“Microtune Introduces Industry's First 1-GHZ Cable Tuners Compatible with MoCA—Home Networking Standard”, Business Wire, San Francisco, California, Mar. 19, 2007.
Related Publications (1)
Number Date Country
20100031297 A1 Feb 2010 US
Provisional Applications (2)
Number Date Country
61085096 Jul 2008 US
61187616 Jun 2009 US