WO2002078242A1 - Mechanism to strip larq header and regenerate fcs to support sleep mode wake up - Google Patents

Mechanism to strip larq header and regenerate fcs to support sleep mode wake up Download PDF

Info

Publication number
WO2002078242A1
WO2002078242A1 PCT/US2001/031298 US0131298W WO02078242A1 WO 2002078242 A1 WO2002078242 A1 WO 2002078242A1 US 0131298 W US0131298 W US 0131298W WO 02078242 A1 WO02078242 A1 WO 02078242A1
Authority
WO
WIPO (PCT)
Prior art keywords
frame
fcs
stripped
larq
logic block
Prior art date
Application number
PCT/US2001/031298
Other languages
French (fr)
Inventor
Peter Ka-Fai Chow
Original Assignee
Advanced Micro Devices, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Advanced Micro Devices, Inc. filed Critical Advanced Micro Devices, Inc.
Priority to JP2002576355A priority Critical patent/JP3908667B2/en
Priority to KR1020037012403A priority patent/KR100804288B1/en
Priority to EP01977552A priority patent/EP1391071A1/en
Publication of WO2002078242A1 publication Critical patent/WO2002078242A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056—Systems characterized by the type of code used
    • H04L1/0061—Error detection codes
    • H04L1/0063—Single parity check
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5603—Access techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC

Definitions

  • the present invention relates to received data packets in a network, and more particularly to the removing unwanted header information to from received data packets in the network.
  • Home networks are becoming more common and desirable for connecting computers within a home.
  • One type of home network is the home phone line network which uses telephone lines typically installed in residence homes for communication between computers in the home.
  • the Home Phone Line Networking Alliance (HPNA) has published a specification to standardize the behavior of home phone line networks.
  • FIG. 1 illustrates a home phone line network in accordance with the present invention.
  • the preferred embodiment of the network complies with the Home Phoneline Networking Alliance specification version 2.0 (HPNA 2.0).
  • HPNA 2.0 Home Phoneline Networking Alliance specification version 2.0
  • the network allows multiple computers to communicate through telephone wires typically installed in residential homes.
  • the network comprises a control chip 100.
  • the chip 100 further comprises a Media Independent Interface (MS) 106, a Media Access Control (MAC) 108, and a Physical Layer (PHY) 110.
  • the chip 100 implements the HPNA 2.0 specification.
  • the chip 100 receives a signal containing data packets through the telephone wires via a phone jack 102.
  • There is an analog front end (AFE) 104 which processes the signal between the chip 100 and the telephone wires.
  • AFE analog front end
  • the Ethernet controller 112 can be configured to power down, or "sleep", when not used.
  • a system administration on a remote site may "wake up” the Ethernet controller 112 by sending a frame through the chip 100 and to the
  • the frame has a particular bit pattern, the "wake pattern", at a set byte location in the frame. To determine if it should wake, the Ethernet controller 112 counts the bytes in the frame until it reaches the set byte location. The Ethernet controller 112 then attempts to match the bit pattern at the set byte location with the wake pattern. If there is a match, then the Ethernet controller 112 wakes and powers up.
  • Ethernet controller 112 continues to sleep.
  • the frame may contain an additional 8-byte Limited Automatic Repeat Request (LARQ) in its header.
  • LARQ Automatic Repeat Request
  • the LARQ 110 conveys link layer priority information and provides a negative acknowledgment protocol to increase the speed of frame retransmission.
  • the Ethernet protocol used by the Ethernet controller 112 does not recognize or expect the LARQ header.
  • the Ethernet controller 112 counts the bytes to the set byte location and attempts to match the bit pattern with the wake pattern.
  • the LARQ header since the LARQ header has added 8 bytes to the frame, the location at which the Ethernet controller 112 attempts to match the bit pattern is not where the wake pattern is actually located. The Ethernet controller 112 thus does not wake up.
  • the present invention provides a method for supporting sleep mode wake up in a home phone line network.
  • the method includes: detecting a limited automatic repeat request (LARQ) header in a frame; stripping the LARQ header and a frame check sequence (FCS) in the frame; recalculating the FCS for the stripped frame; and adding the recalculated FCS to the stripped frame.
  • LARQ limited automatic repeat request
  • FCS frame check sequence
  • the method strips the LARQ header from a HPNA frame before it is sent to an Ethernet controller. By stripping the LARQ header, the Ethernet controller will correctly find the set byte location for the wake pattern and attempts to match the bit pattern with the wake pattern. In this manner, sleep mode wake up is supported.
  • Figure 1 illustrates a home phone line network in accordance with the present invention.
  • FIG. 2 illustrates a preferred embodiment of a MAC in accordance with the present invention.
  • Figure 3 is a flowchart illustrating a preferred embodiment of a method to strip the LARQ header to support remote wake up in accordance with the present invention.
  • Figure 4 illustrates a preferred embodiment of a Receive Data Path which strips the LARQ header to support remote wake up in accordance with the present invention.
  • the present invention provides a mechanism to strip the LARQ header to support remote wake up.
  • the following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. Thus, the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest scope consistent with the principles and features described herein.
  • Figure 2 illustrates a preferred embodiment of a MAC in accordance with the present invention.
  • the MAC comprises a Receive Data Path 202, a Transmit Data Path 204, a Distributed Fair Priority Queuing (DFPQ) 206, a Binary Exponential Backoff (BEB) 208, a Link Integrity 210, a Network State 212, a Rate Request Control Frame (RRCF) 214, a plurality of registers and Management Information Base (MOB) counters 216.
  • DFPQ Distributed Fair Priority Queuing
  • BEB Binary Exponential Backoff
  • RRCF Rate Request Control Frame
  • MOB Management Information Base
  • the Receive Data Path 202 receives data packets from the PHY 110 and sends data packets either to the Mil 106.
  • another packet referred to herein as a "frame status frame"
  • the frame status frame contains certain status information required by subsequent processes.
  • the Transmit Data Path 204 which receives data packets from the Mil 106 and transmits them to the PHY 110.
  • the DFPQ 206 and the BEB 208 provide collision resolution.
  • the HPNA 2.0 specification supports both a 10 megabyte per second (mbps) data rate and a 1 mbps data rate.
  • the DFPQ 206 provides collision resolution for the 10 mbps data rate
  • the BEB 208 provides collision resolution for the 1 mbps data rate.
  • the PHY 110 will provide a collision detect signal. Either the DFPQ 206 or the BEB 208 will then attempt to resolve the collision.
  • the Link Integrity 210 monitors the physical network conditions. In the preferred embodiment, the Link Integrity 210 updates a link status bit in a link register.
  • the Link Integrity 210 also sends link packets in accordance with HPNA 2.0.
  • the Network State 212 monitors the current mode of the MAC 108, i.e., whether the MAC 108 is operating in the 10 mbps data rate mode ("10M8") or the 1 mbps data rate mode (“1M8").
  • the RRCF block (214) sends a RRCF whenever the MAC 108 transitions between data rates.
  • the RRCF is used to perform the rate negotiation function, i.e., to determine what is the data rate to communicate between different stations in a home phone line network.
  • the registers and MIB counters 216 provides programmability to the MAC 108 and handles error event counting.
  • Figure 3 is a flowchart illustrating a preferred embodiment of a method to strip the LARQ header to support remote wake up in accordance with the present invention.
  • the method is provided as part of the Receive Data Path 202.
  • the Receive Data Path detects the LARQ header in a frame, via step 302.
  • the LARQ header and the frame check sequence (FCS) of the frame are stripped, via step 304.
  • the FCS is the last four bytes of a frame which is used to determine whether or not the frame contains errors.
  • the information in the stripped LARQ header is placed into the frame status frame which will immediately follow the stripped frame. In this way, the LARQ header information is still available to other processes.
  • the Receive Data Path 202 then recalculates the FCS for the stripped frame and adds it to the stripped frame, via step 306. This recalculation is necessary because otherwise, the Ethernet controller 112 would erroneous determine that the stripped frame has errors because the LARQ is missing.
  • the stripped frame with the recalculated FCS is sent to the Ethernet controller 112, via step 308.
  • this stripping of the LARQ header may be user programmable.
  • the setting of a register is used to activate the stripping of the LARQ header as described above.
  • the user may program the MAC such that whenever the Ethernet controller 112 goes into a sleep mode, the register is set and the
  • the method to strip the LARQ header is implemented in hardware.
  • the method may be implemented in software, or a combination of hardware and software, without departing from the spirit and scope of the present invention.
  • FIG. 4 illustrates a preferred embodiment of a Receive Data Path which strips the LARQ header to support remote wake up in accordance with the present invention.
  • the Receive Data Path 202 comprises a PM_RXDEC logic block 402, a PM_RXFCON logic block 404, a PMJRXNTB logic block 406, and a PM_RXFCSGEN logic block 408.
  • the registers in the Registers and MTB Counters 216 asserts a signal, strip LARQ, to the PM_RXDEC 402 to indicate that the LARQ header stripping is enabled.
  • a frame with a LARQ header is received via data buses RM)BYTE to the PM_RXDEC 402
  • the LARQ header is tripped from the frame, via step 302.
  • the PM_RXDEC 402 then asserts the rm_sfcs signal and the rm_slarq signal to the PM_RXFCON 404.
  • the asserted rm_sfcs signal indicates that the FCS in the frame is to be stripped.
  • the asserted rm slarq signal indicates that the LARQ in the frame is to be stripped.
  • the PM_RXFCON 404 then strips the FCS and the LARQ, via step 304.
  • the PM_RXFCON 404 asserts a rb_str_larq signal to the PM_RXNIB 406.
  • the asserted rb_str_larq signal indicates that the LARQ has been stripped from the frame.
  • the PM RXNIB 406 generates the frame control frame accordingly.
  • the PM_RXNIB 406 asserts an enfcs signal to the PM_RXFCSGEN 408.
  • the asserted enfcs signal enables FCS recalculation for the stripped frame.
  • the PM_RXFCSGEN 408 then recalculates the FCS for the stripped frame, via step 306.
  • the recalculated FCS is added to the stripped frame, and this frame is sent to the Ethernet controller 112,
  • a method to strip the LARQ header to support remote wake has been disclosed.
  • the method strips the LARQ header from a HPNA frame before it is sent to an Ethernet controller.
  • the Ethernet controller will correctly find the set byte location for the wake pattern and attempts to match the bit pattern with the wake pattern. In this manner, sleep mode wake up is supported.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The present invention provides a method for supporting sleep mode wake up in a home phone line network. The method includes: detecting a limited automatic repeat request (LARQ) header in a frame; stripping the LARQ header and a frame check sequence (FCS) in the frame; recalculating the FCS for the stripped frame; and adding the recalculated FCS to the stripped frame. The method strips the LARQ header from a HPNA frame before it is sent to an Ethernet controller. By stripping the LARQ header, the Ethernet controller will correctly find the set byte location for the wake pattern and attempts to match the bit pattern with the wake pattern. In this manner, sleep mode wake up is supported.

Description

MECHANISM TO STRIP LARQ HEADER AND REGENERATE FCS TO SUPPORT SLEEP MODE WAKE UP
FIELD OF THE INVENTION
The present invention relates to received data packets in a network, and more particularly to the removing unwanted header information to from received data packets in the network.
BACKGROUND OF THE INVENTION
Home networks are becoming more common and desirable for connecting computers within a home. One type of home network is the home phone line network which uses telephone lines typically installed in residence homes for communication between computers in the home. The Home Phone Line Networking Alliance (HPNA) has published a specification to standardize the behavior of home phone line networks.
Figure 1 illustrates a home phone line network in accordance with the present invention. The preferred embodiment of the network complies with the Home Phoneline Networking Alliance specification version 2.0 (HPNA 2.0). The network allows multiple computers to communicate through telephone wires typically installed in residential homes. The network comprises a control chip 100. The chip 100 further comprises a Media Independent Interface (MS) 106, a Media Access Control (MAC) 108, and a Physical Layer (PHY) 110. The chip 100 implements the HPNA 2.0 specification. The chip 100 receives a signal containing data packets through the telephone wires via a phone jack 102. There is an analog front end (AFE) 104 which processes the signal between the chip 100 and the telephone wires. The chip 100 then
-i- processes the packets received in the signal from the AFE 104, and outputs a signal to the Host MAC 112 or to an Ethernet controller 112.
As is known in the art, the Ethernet controller 112 can be configured to power down, or "sleep", when not used. A system administration on a remote site may "wake up" the Ethernet controller 112 by sending a frame through the chip 100 and to the
Ethernet controller 112. The frame has a particular bit pattern, the "wake pattern", at a set byte location in the frame. To determine if it should wake, the Ethernet controller 112 counts the bytes in the frame until it reaches the set byte location. The Ethernet controller 112 then attempts to match the bit pattern at the set byte location with the wake pattern. If there is a match, then the Ethernet controller 112 wakes and powers up.
Otherwise, the Ethernet controller 112 continues to sleep.
However, under HPNA 2.0, the frame may contain an additional 8-byte Limited Automatic Repeat Request (LARQ) in its header. The LARQ 110 conveys link layer priority information and provides a negative acknowledgment protocol to increase the speed of frame retransmission. The Ethernet protocol used by the Ethernet controller 112 does not recognize or expect the LARQ header. When a HPNA frame with the LARQ header and the wake pattern is sent to the Ethernet controller 112, the Ethernet controller 112 counts the bytes to the set byte location and attempts to match the bit pattern with the wake pattern. However, since the LARQ header has added 8 bytes to the frame, the location at which the Ethernet controller 112 attempts to match the bit pattern is not where the wake pattern is actually located. The Ethernet controller 112 thus does not wake up.
Accordingly, there exists a need for a mechanism to strip the LARQ header to support remote wake up. The present invention addresses such a need. SUMMARY OF THE INVENTION
The present invention provides a method for supporting sleep mode wake up in a home phone line network. The method includes: detecting a limited automatic repeat request (LARQ) header in a frame; stripping the LARQ header and a frame check sequence (FCS) in the frame; recalculating the FCS for the stripped frame; and adding the recalculated FCS to the stripped frame. The method strips the LARQ header from a HPNA frame before it is sent to an Ethernet controller. By stripping the LARQ header, the Ethernet controller will correctly find the set byte location for the wake pattern and attempts to match the bit pattern with the wake pattern. In this manner, sleep mode wake up is supported.
BRIEF DESCRIPTION OF THE FIGURES
Figure 1 illustrates a home phone line network in accordance with the present invention.
Figure 2 illustrates a preferred embodiment of a MAC in accordance with the present invention.
Figure 3 is a flowchart illustrating a preferred embodiment of a method to strip the LARQ header to support remote wake up in accordance with the present invention. Figure 4 illustrates a preferred embodiment of a Receive Data Path which strips the LARQ header to support remote wake up in accordance with the present invention.
DETAD ED DESCRD?TION
The present invention provides a mechanism to strip the LARQ header to support remote wake up. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. Thus, the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest scope consistent with the principles and features described herein.
To more particularly describe the features of the present invention, please refer to Figures 2 through 4 in conjunction with the discussion below. Figure 2 illustrates a preferred embodiment of a MAC in accordance with the present invention. The MAC comprises a Receive Data Path 202, a Transmit Data Path 204, a Distributed Fair Priority Queuing (DFPQ) 206, a Binary Exponential Backoff (BEB) 208, a Link Integrity 210, a Network State 212, a Rate Request Control Frame (RRCF) 214, a plurality of registers and Management Information Base (MOB) counters 216.
The Receive Data Path 202 receives data packets from the PHY 110 and sends data packets either to the Mil 106. In the preferred embodiment, after each data packet sent by the Receive Data Path 202, another packet, referred to herein as a "frame status frame", is sent immediately following. The frame status frame contains certain status information required by subsequent processes.
The Transmit Data Path 204, which receives data packets from the Mil 106 and transmits them to the PHY 110.
The DFPQ 206 and the BEB 208 provide collision resolution. The HPNA 2.0 specification supports both a 10 megabyte per second (mbps) data rate and a 1 mbps data rate. The DFPQ 206 provides collision resolution for the 10 mbps data rate, while the BEB 208 provides collision resolution for the 1 mbps data rate. In the preferred embodiment, the PHY 110 will provide a collision detect signal. Either the DFPQ 206 or the BEB 208 will then attempt to resolve the collision. The Link Integrity 210 monitors the physical network conditions. In the preferred embodiment, the Link Integrity 210 updates a link status bit in a link register. The Link Integrity 210 also sends link packets in accordance with HPNA 2.0.
The Network State 212 monitors the current mode of the MAC 108, i.e., whether the MAC 108 is operating in the 10 mbps data rate mode ("10M8") or the 1 mbps data rate mode ("1M8").
The RRCF block (214) sends a RRCF whenever the MAC 108 transitions between data rates. The RRCF is used to perform the rate negotiation function, i.e., to determine what is the data rate to communicate between different stations in a home phone line network. The registers and MIB counters 216 provides programmability to the MAC 108 and handles error event counting.
Figure 3 is a flowchart illustrating a preferred embodiment of a method to strip the LARQ header to support remote wake up in accordance with the present invention. In the preferred embodiment, the method is provided as part of the Receive Data Path 202. First, the Receive Data Path detects the LARQ header in a frame, via step 302.
Next, the LARQ header and the frame check sequence (FCS) of the frame are stripped, via step 304. The FCS is the last four bytes of a frame which is used to determine whether or not the frame contains errors. In the preferred embodiment, the information in the stripped LARQ header is placed into the frame status frame which will immediately follow the stripped frame. In this way, the LARQ header information is still available to other processes. The Receive Data Path 202 then recalculates the FCS for the stripped frame and adds it to the stripped frame, via step 306. This recalculation is necessary because otherwise, the Ethernet controller 112 would erroneous determine that the stripped frame has errors because the LARQ is missing. Then, the stripped frame with the recalculated FCS is sent to the Ethernet controller 112, via step 308.
In the preferred embodiment, this stripping of the LARQ header may be user programmable. For example, the setting of a register is used to activate the stripping of the LARQ header as described above. The user may program the MAC such that whenever the Ethernet controller 112 goes into a sleep mode, the register is set and the
LARQ header is stripped. Otherwise, the register is not set, and the LARQ header in not stripped.
In the preferred embodiment, the method to strip the LARQ header is implemented in hardware. However, one of ordinary skill in the art will understand that the method may be implemented in software, or a combination of hardware and software, without departing from the spirit and scope of the present invention.
Figure 4 illustrates a preferred embodiment of a Receive Data Path which strips the LARQ header to support remote wake up in accordance with the present invention. The Receive Data Path 202 comprises a PM_RXDEC logic block 402, a PM_RXFCON logic block 404, a PMJRXNTB logic block 406, and a PM_RXFCSGEN logic block 408.
The registers in the Registers and MTB Counters 216 asserts a signal, strip LARQ, to the PM_RXDEC 402 to indicate that the LARQ header stripping is enabled. When a frame with a LARQ header is received via data buses RM)BYTE to the PM_RXDEC 402, the LARQ header is tripped from the frame, via step 302. The PM_RXDEC 402 then asserts the rm_sfcs signal and the rm_slarq signal to the PM_RXFCON 404. The asserted rm_sfcs signal indicates that the FCS in the frame is to be stripped. The asserted rm slarq signal indicates that the LARQ in the frame is to be stripped. The PM_RXFCON 404 then strips the FCS and the LARQ, via step 304. Next, the PM_RXFCON 404 asserts a rb_str_larq signal to the PM_RXNIB 406. The asserted rb_str_larq signal indicates that the LARQ has been stripped from the frame. The PM RXNIB 406 generates the frame control frame accordingly. The PM_RXNIB 406 asserts an enfcs signal to the PM_RXFCSGEN 408. The asserted enfcs signal enables FCS recalculation for the stripped frame. The PM_RXFCSGEN 408 then recalculates the FCS for the stripped frame, via step 306. The recalculated FCS is added to the stripped frame, and this frame is sent to the Ethernet controller 112, via step 308.
A method to strip the LARQ header to support remote wake has been disclosed. The method strips the LARQ header from a HPNA frame before it is sent to an Ethernet controller. By stripping the LARQ header, the Ethernet controller will correctly find the set byte location for the wake pattern and attempts to match the bit pattern with the wake pattern. In this manner, sleep mode wake up is supported.
Although the present invention has been described in accordance with the embodiments shown, one of ordinary skill in the art will readily recognize that there could be variations to the embodiments and those variations would be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.

Claims

CLAIMSWhat is claimed is:
1. A method for supporting sleep mode wake up in a home phone line network, comprising the steps of:
(a) detecting a limited automatic repeat request (LARQ) header in a frame;
(b) stripping the LARQ header and a frame check sequence (FCS) in the frame;
(c) recalculating the FCS for the stripped frame; and
(d) adding the recalculated FCS to the stripped frame.
2. The method of claim 1, wherein the stripping step (b) further comprises: (bl) placing information in the LARQ header in a frame status frame which will follow the stripped frame.
3. The method of claim 1, further comprising:
(e) sending the stripped frame with the recalculated FCS to an Ethernet controller.
4. The method of claim 3, further comprising:
(f) determining if a bit pattern at a set byte location in the stripped frame matches a wake pattern.
5. A home phone line controller, comprising: a first logic block for detecting a LARQ header in a frame; a second logic block for stripping the LARQ header and a FCS in the frame; and a third logic block for recalculating the FCS for the stripped frame and for adding the recalculated FCS to the stripped frame.
6. The controller of claim 5, wherein an asserted first signal to the first logic block indicates that the LARQ header is enabled and must be stripped from the frame.
7. The controller of claim 5, wherein the first logic block asserts a second signal and a third signal to the second logic block, wherein the second signal indicates that the FCS is to be stripped from the frame, wherein the third signal indicates that the
LARQ header is to be stripped from the frame.
8. The controller of claim 5, wherein an asserted fourth signal to the third logic block enables the recalculation of the FCS.
9. A system, comprising: an Ethernet controller in a sleep mode; and a home phone line network controller, wherein the home phone line network controller comprises: a first logic block for detecting a LARQ header in a frame, a second logic block for stripping the LARQ header and a FCS in the frame, and a third logic block for recalculating the FCS for the stripped frame and for adding the recalculated FCS to the stripped frame.
10. The system of claim 9, wherein an asserted first signal to the first logic block indicates that the LARQ header is enabled and must be stripped from the frame.
11. The system of claim 9, wherein the first logic block asserts a second signal and a third signal to the second logic block, wherein the second signal indicates that the FCS is to be stripped from the frame, wherein the third signal indicates that the LARQ header is to be stripped from the frame.
12. The system of claim 9, wherein an asserted fourth signal to the third logic block enables the recalculation of the FCS.
PCT/US2001/031298 2001-03-23 2001-10-04 Mechanism to strip larq header and regenerate fcs to support sleep mode wake up WO2002078242A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2002576355A JP3908667B2 (en) 2001-03-23 2001-10-04 Mechanism to extract LARQ header and regenerate FCS to support return to sleep mode
KR1020037012403A KR100804288B1 (en) 2001-03-23 2001-10-04 Method and system for supporting sleep mode wake up in a home phone line network, and home phone line controller
EP01977552A EP1391071A1 (en) 2001-03-23 2001-10-04 Mechanism to strip larq header and regenerate fcs to support sleep mode wake up

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/816,706 US6996124B1 (en) 2001-03-23 2001-03-23 Mechanism to strip LARQ header and regenerate FCS to support sleep mode wake up
US09/816,706 2001-03-23

Publications (1)

Publication Number Publication Date
WO2002078242A1 true WO2002078242A1 (en) 2002-10-03

Family

ID=25221403

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/031298 WO2002078242A1 (en) 2001-03-23 2001-10-04 Mechanism to strip larq header and regenerate fcs to support sleep mode wake up

Country Status (6)

Country Link
US (1) US6996124B1 (en)
EP (1) EP1391071A1 (en)
JP (1) JP3908667B2 (en)
KR (1) KR100804288B1 (en)
CN (1) CN1494779A (en)
WO (1) WO2002078242A1 (en)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7164681B2 (en) * 2001-07-13 2007-01-16 Advanced Micro Devices, Inc. Mechanism to strip LARQ header and preserve LARQ header in status frame
JP2003333061A (en) * 2002-04-03 2003-11-21 Samsung Electronics Co Ltd Ethernet (r) passive optical subscriber network and point-to-point emulation method
US8131879B1 (en) * 2002-08-30 2012-03-06 Globalfoundries Inc. Use of ethernet frames for exchanging control and status information within an HPNA controller
KR100863467B1 (en) * 2007-01-01 2008-10-16 주식회사 로직플랜트 A method that keeps suspended mode and allows remote wakeup of a computer that is connected to the network by defining wakeup patterns
CN201497951U (en) * 2009-08-07 2010-06-02 鸿富锦精密工业（深圳）有限公司 Network device
JP2013055393A (en) 2011-09-01 2013-03-21 Sony Corp Communication device, communication method, communication system, and base station

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996013106A1 (en) * 1994-10-20 1996-05-02 Advanced Micro Devices, Inc. System and method for remote wake-up
WO2000072498A1 (en) * 1999-05-21 2000-11-30 Broadcom Homenetworking, Inc. Limited automatic repeat request protocol for frame-based communication channels

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5251205A (en) * 1990-09-04 1993-10-05 Digital Equipment Corporation Multiple protocol routing
US5999541A (en) * 1997-02-28 1999-12-07 3Com Corporation Transmission of token-ring packets over ethernet by tunneling

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996013106A1 (en) * 1994-10-20 1996-05-02 Advanced Micro Devices, Inc. System and method for remote wake-up
WO2000072498A1 (en) * 1999-05-21 2000-11-30 Broadcom Homenetworking, Inc. Limited automatic repeat request protocol for frame-based communication channels

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
FRANK E H ET AL: "CONNECTING THE HOME WITH A PHONE LINE NETWORK CHIP SET", IEEE MICRO, IEEE INC. NEW YORK, US, vol. 20, no. 2, March 2000 (2000-03-01), pages 27 - 38, XP000908494, ISSN: 0272-1732 *

Also Published As

Publication number Publication date
KR20030085050A (en) 2003-11-01
US6996124B1 (en) 2006-02-07
EP1391071A1 (en) 2004-02-25
CN1494779A (en) 2004-05-05
JP2004535093A (en) 2004-11-18
JP3908667B2 (en) 2007-04-25
KR100804288B1 (en) 2008-02-18

Similar Documents

Publication Publication Date Title
US7103688B2 (en) Data transmission method and apparatus
KR101885935B1 (en) Method and apparatus for serial data transmission at a switchable data rate
CA1338220C (en) Variable speed local area network
US6909725B1 (en) Implementation of HPNA 2.0 network states in hardware
KR20150100790A (en) Data transmission using a protocol exception state
EP0560886A1 (en) Multiaccess carrier sensing network communication protocol with priority messages
US6925089B2 (en) Mechanism to consolidate HPNA three network states into two network states
US6741566B1 (en) Remote management ethernet network and device
US6996124B1 (en) Mechanism to strip LARQ header and regenerate FCS to support sleep mode wake up
US7164681B2 (en) Mechanism to strip LARQ header and preserve LARQ header in status frame
US7149818B2 (en) Method to communicate PHY mean square error to upper layer device driver for rate negotiation
US6961344B1 (en) Verification of collision detection and resolution in a home network
KR100609493B1 (en) Method for transmitting multiple sensors data with a CAN message
US7801053B2 (en) Method for setting consistent values for a parameter in a network of distributed stations, as well as a network subscriber station for carrying out the method
KR100819194B1 (en) Multiple buffers for removing unwanted header information from received data packets
EP1999882B1 (en) Duplex mismatch detection
US20040004974A1 (en) Method and system for optimizing the design of a network controller
US7072351B1 (en) Collision recovery interface support in a home phoneline networking alliance media access controller (HPNA MAC) operating in accordance with at least two different data rate standards
US6834313B1 (en) Performing a two-step read on a MAC register in a home network as an atomic read
US8131879B1 (en) Use of ethernet frames for exchanging control and status information within an HPNA controller
KR20050025518A (en) Apparatus and method of processing msdu in wireless lan
JPS62176236A (en) Method for preventing transmission error at reply packet transmission
JPS61105945A (en) Method of packeting process

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2002576355

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 018230687

Country of ref document: CN

Ref document number: 1020037012403

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2001977552

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWP Wipo information: published in national office

Ref document number: 2001977552

Country of ref document: EP