WO1998047267A1 - Cebus data link layer proxy - Google Patents
Cebus data link layer proxy Download PDFInfo
- Publication number
- WO1998047267A1 WO1998047267A1 PCT/US1998/007504 US9807504W WO9847267A1 WO 1998047267 A1 WO1998047267 A1 WO 1998047267A1 US 9807504 W US9807504 W US 9807504W WO 9847267 A1 WO9847267 A1 WO 9847267A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- cebus
- message
- network
- lpdu
- ack
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L12/2816—Controlling appliance services of a home automation network by calling their functionalities
- H04L12/2818—Controlling appliance services of a home automation network by calling their functionalities from a device located outside both the home and the home network
-
- 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
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1854—Scheduling and prioritising arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L12/283—Processing of data at an internetworking point of a home automation network
- H04L12/2832—Interconnection of the control functionalities between home networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
-
- 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
- H04L2001/0092—Error control systems characterised by the topology of the transmission link
- H04L2001/0097—Relays
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L2012/284—Home automation networks characterised by the type of medium used
- H04L2012/2843—Mains power line
Definitions
- a method for transmitting messages from a first node located on a non-CEBus network to a device located on a CEBus network via a proxy node comprising the steps of : transmitting a message from the first node to the proxy node over the non-CEBus network; and transmitting the message from the proxy node to the device over the CEBus network.
- the message of a type requiring a standard CEBus acknowledge (“Ack") message response be transmitted by the receiving entity and received by the transmitting entity within a first specified time interval from when the transmitting entity sends the message, comprising the further step of: transmitting a responsive CEBus Ack message from the device to the proxy node over the CEBus network, such that the proxy node receives the CEBus Ack message within the first specified interval.
- Ack CEBus acknowledge
- the message of a type requiring a standard CEBus acknowledge (“Ack") message response be transmitted by the receiving entity and received by the transmitting entity within a first specified time interval from when the transmitting entity sends the message, and wherein the CEBus Ack message is not received by the proxy node within the first specified time interval after first sending the message, comprising the further step of: periodically re-transmitting the message from the proxy node to the device over the CEBus network until such time as a CEBus Ack message is received by the proxy node within the first specified time interval after re-transmitting the message, or until a selected number of re-transmissions have been made, whichever occurring first.
- Ack CEBus acknowledge
- the method of claim 5, comprising the further step of: transmitting a non-standard acknowledge message from the proxy node to the first node over the non-CEBus network upon receiving a CEBus Ack message from the device, such that the first node receives the non- standard acknowledge message within a second specified time interval.
- a method for transmitting messages from a device located on a CEBus network to a first node located on a non-CEBus network via a proxy node comprising the steps of: transmitting a message from the device to the proxy node over the CEBus network; and transmitting the message from the proxy node to the first node over the non-CEBus network.
- the method of claim 12, comprising the further step of: 22 transmitting a non-standard acknowledge message from the first node to the proxy node over the non-CEBus network upon receiving the message, such that the proxy node receives the non-standard acknowledge message within a specified time interval from when it first sent the message.
- the message of a type requiring a standard CEBus acknowledge (“Ack") message response be transmitted by the receiving entity and received by the transmitting entity within a first specified time interval from when the transmitting entity sends the message, comprising the further step of: transmitting a responsive CEBus Ack message from the proxy node to the device over the CEBus network, such that the device receives the CEBus Ack message within the first specified interval.
- Ack CEBus acknowledge
- the message of a type requiring a standard CEBus acknowledge (“Ack") message response be transmitted by the receiving entity and received by the transmitting entity within a first specified time interval from when the transmitting entity sends the message, and wherein the CEBus Ack message is not received by the device within the first specified time interval after first sending the message, comprising the further step of: 23 periodically re-transmitting the message from the device to the proxy node over the CEBus network until such time as a CEBus Ack message is received by the device within the first specified time interval after re-transmitting the message, or until a selected number of re-transmissions have been made, whichever occurring first.
- Ack CEBus acknowledge
- the device is a utility managed settable node and the first node is a utility host master node.
- a method for transmitting messages from a first node located on a non-CEBus network to a device located on a CEBus network via a proxy node comprising the steps of: transmitting a message from the first node to the proxy node over the non-CEBus network, the message of a type requiring a standard CEBus acknowledge ("Ack") message response be transmitted by the receiving entity; transmitting the message from the proxy node to the device over the CEBus network; if a responsive CEBus Ack message is received by the proxy node from the device within a first specified interval from when it sent the message, transmitting a non-standard acknowledge message from the proxy node to the first node; and if a responsive CEBus Ack message is not received by the proxy node from the device within a first specified interval from when it sent the message, periodically re-transmitting the message from the proxy node to the device over the CEBus network until such time as a CEBus Ack message is received by the proxy node within the first specified
- Nack non-standard negative-acknowledge
- the present invention pertains to the field of data communications and, more particularly, to methods and apparatus for mapping a CEBus network across a non-CEBus network, while maintaining EIA/IS-60 Data Link Protocol requirements .
- a controller device may command an air conditioner in a home to power on, or off, in an attempt to balance the power load in a residential subdivision.
- CEBus Consumer Electronics Bus
- EIA Electronics Industry Association's
- consumer residential electrical
- This standard specifies how devices are to send and receive information, the media available to them for communication purposes, and the format for the information the devices communicate to each other.
- the CEBus standard permits devices made by various manufacturers to be able to communicate with each other in a residential setting.
- the standard is documented in the CEBus EIA/lS-60 specification, which is fully incorporated herein by reference. Thus far, networks based on the CEBus standard have been geared for "local access” control and surveillance.
- a specified subset of messages transmitted within a CEBus network by a controller device, or any other CEBus network device require a CEBus "Ack" (i.e, acknowledge) message to be transmitted in response, and to be received by the device transmitting the original message within 600 ⁇ secs of the transmission of that original message.
- a CEBus "Ack" i.e, acknowledge
- controller devices for CEBus networks have necessarily been required to be located locally, i.e., in the general vicinity of the controlled device (s), which has thus far prevented the effective extension of the CEBus standard protocol to allow for "remote access” control.
- the situation is further complicated if a remote controller device for exercising control of one or more devices on a CEBus network itself communicates via a non-CEBus network.
- the present invention provides apparatus and methods for employing a communication protocol proxy that enables a CEBus network to be mapped across a non- CEBus network, thereby allowing a remotely located node (e.g., a controller) to communicate via a non-CEBus network with electronic devices connected to the CEBus network, while still conforming with the EIA/IS-60 protocol requirements.
- a remotely located node e.g., a controller
- a proxy node is provided on a CEBus network, wherein the proxy node is also connected to a non-CEBus network (e.g., a wide area network ("WAN") ) .
- a remotely located controller on the non-CEBus network may communicate with a device on the CEBus network by transmitting messages to the proxy node over the non-CEBus network.
- the proxy node then forwards the message to the respective CEBus device over the CEBus network. If the message requires a CEBus Ack message response, the CEBus device transmits a CEBus Ack message to the proxy node, so that it is received within the time interval specified by the CEBus standard.
- the proxy node On receiving the CEBus Ack message, the proxy node transmits a non-CEBus standard acknowledge message to the controller, which can be received over an extended time interval. If the message does not require a CEBus Ack message response, the proxy node still transmits a non-CEBus standard acknowledge message to the controller in order to verify receipt of the message.
- the CEBus device For message transmissions from the CEBus device to the controller, the CEBus device transmits a message to the proxy node on the CEBus network. The proxy node then transmits the message to the controller, over the non-CEBus network. If the message requires a CEBus Ack message response, the proxy node itself transmits the CEBus Ack message to the CEBus device. Whether or not the message requires a CEBus Ack message response, the controller, upon receiving the message from the proxy node, transmits a non-CEBus standard acknowledge message to the proxy node .
- a general object of the invention is to support communications between a remote access controller on a non-CEBus network and one or more devices on a CEBus network.
- Figure 1 is a diagram illustrating the mapping of a plurality of CEBus residential networks across a non- CEBus wide area network ("WAN") , via a plurality of respective proxy nodes;
- WAN wide area network
- FIG. 2 is a diagram of preferred message transmission protocol sequences for link protocol data unit (“LPDU”) transmissions from a remotely located utility host master node (“UHMN”) on a non-CEBus network to a utility-managed settable node (“UMSN”) on a CEBus network;
- UHMN utility host master node
- UMSN utility-managed settable node
- Figure 3 is a diagram of preferred message transmission protocol sequences for LPDU transmissions from a UMSN on a CEBus network to a UHMN on a non-CEBus network;
- FIG. 4 is a diagram of a preferred network termination data link layer acknowledge/ negative acknowledge (“NT DLL Ack/Nack”) message format.
- a plurality of CEBus standard residential networks 130 each connect various respective devices located in one or more respective residences 120.
- a residential home 120 may contain one or more utility-managed settable nodes (“UMSN”s) 125 managed by a utility company in energy- management applications, including, but not limited to, gas and electrical appliances.
- UMSN utility-managed settable nodes
- a UMSN 125 is a "smart" consumer device, also referred to as a "CEBus device” or a "CEBus node,” that communicates with other similar devices via CEBus standard-defined messages and protocols.
- a CEBus network 130 may contain CEBus devices 125 from a plurality of residential homes 120. The same CEBus network may also contain other, non-UMSN CEBus devices 145. Each CEBus network 130 has a physical layer, which consists of the information signal transmitted within the respective CEBus network 130. Each CEBus network 130 also has a data link layer (“DLL") , which provides the means for establishing and maintaining individual data links on the respective CEBus network 130. The CEBus network 130 DLL also provides for the transfer of information over a physical link, or links, connecting the respective CEBus nodes 125, 135 and 145, including the requisite synchronization, error control and flow control.
- DLL data link layer
- Each residential home 120 containing one or more UMSNs 125 is also provided with a network terminal ("NT") device 135 located proximate to, or placed in, the respective residential home 120, wherein the NT 135 is linked to the respective CEBus network 130 connecting the UMSNs 125 of that home 120.
- the NTs 135 are UMSNs, and are also special application CEBus devices which enable the CEBus networks 130 to be mapped to external, non-CEBus networks.
- each NT 135 also delivers analog distributive services and digital interactive services to the respective residences 120, which are received over a two-way hybrid fiber/coax distribution ("HFC") network 140, and are provided by the NT 135 over a mix of service interfaces (not shown) to its respective residence 120, i.e., for various computing, telecommunications and entertainment equipment (also not shown) .
- HFC hybrid fiber/coax distribution
- NT network interface
- the disclosed network interface supports the two-way transport of multiple communication services, including at least RF analog and RF carrier modulated ATM cells, over a single coaxial distribution cable.
- ATM cell-mux circuitry in the network interface provides for de-multiplexing and routing of incoming ATM cells, and for collecting and multiplexing of outgoing ATM cells, respectively, wherein the incoming and outgoing ATM cells are routed to and from a plurality of "ATM" subscriber service modules within the subscriber interface.
- the respective subscriber service modules each support individual services such as telecommunications, set-top telemetry, or baseband digital data services, such as, e.g., ethernets or a dedicated PC modem data line.
- Each service module "disassembles" the respective incoming cells routed to it by the ATM cell-mux, converting (or “adapting") the data contained therein into an appropriate service protocol for delivery through a subscriber-side I/O port associated with the respective service module.
- the protocol conversion may include, for example, circuit emulation for providing a synchronous digital data stream, depending on the respective service.
- information in upstream signals received through a subscriber-side I/O port is assembled into sequential cells by the respective service module and delivered to the ATM cell-mux. In this manner, the ATM transmission of combined services over the network side 7 is advantageously transparent at the subscriber-side I/O ports of the subscriber interface.
- the hybrid fiber coax distribution network 140 may take several alternate physical forms.
- "downstream" ATM traffic transmitted by the switch 160 and intended for one or more NTs 135 may initially be multiplexed for transport over a shared high speed optical fiber (not shown) , then de-multiplexed for local distribution over a shared coaxial cable (also not shown) .
- a pure optical or coaxial network may be equally employed.
- Each NT 135 has a CEBus network interface 155 for the transmission and receipt of messages between the NT 8
- Each NT 135 also has a non-CEBus network interface 185, for the transmission and receipt of data over the HFC 140.
- each NT 135 transmits and receives data over the HFC 140 to and from a packet switch 160, e.g., an asynchronous transfer mode ("ATM") switch, located at an access network termination ("ANT") facility 150.
- the packet switch 160 also communicates via a data link 165 with an energy management terminal (“EMT”) 170 located at the ANT
- the UHMN 180 via a wide area network (“WAN") 175.
- the UHMN 180 is a central management entity, responsible for monitoring and controlling UMSNs 125 located in several residences 120; i.e., via the plurality of CEBus networks 130.
- respective UMSNs 125 communicate via CEBus standard packets, or messages, also called “link protocol data units" ("LPDU"s) .
- LPDU is a packet of information of a maximum length of 41 bytes (also referred to as “octets”) , which includes a header field, a destination device address field, a destination house code field, a source device address field, a source house code field, and a "common application language"
- CAL statement field The CAL statement field of an
- LPDU comprises the command or status information transmitted via the LPDU.
- An LPDU may require a respective CEBus Ack (acknowledge) message to be transmitted by the receiving device back to the device which transmitted the LPDU.
- the CEBus Ack message format is defined in the EIA/IS-60 specification.
- the CEBus EIA/IS-60 protocol requires that the CEBus Ack message be received by the originally transmitting device within 600 /sees of the transmission of the LPDU requiring the response.
- the UHMN 180 may remotely control one or more UMSNs 125 by transmitting and receiving LPDUs over the respective WAN 175 and HFC 140, to the respective NTs 135, which act as proxy nodes for the UMSNs 125. More particularly, an LPDU transmitted from the UHMN 180, and addressed for a specified UMSN 125, is received by the respective NT 135 of the residence 120 containing that UMSN 125. The NT 135 then transmits the LPDU to the identified UMSN 125.
- the recipient UMSN 125 transmits a CEBus Ack message back to the respective NT 135 so that the CEBus Ack message is received by the NT 135 within the 600 ⁇ sec time interval specified by the EIA/IS-60 standard; i.e., based on when the LPDU was transmitted by the NT 135.
- the NT 135 Upon receiving the CEBus Ack message from the UMSN 125, the NT 135 transmits a non-CEBus standard NT DLL Ack message to the UHMN 180 over the non-CEBus network (i.e., the HFC network 140/WAN 175).
- the respective NT 135 still transmits a non-CEBus standard NT DLL Ack message to the UHMN 180, but does so immediately upon receipt of the LPDU from the UHMN 180.
- N is set to a value of 3.
- the respective NT 135 does receive a CEBus Ack message from the UMSN 125 in response to a re-transmission of the LPDU to the UMSN 125, it transmits a non-CEBus standard NT DLL Ack message back to the UHMN 180. If the respective NT 135 does not receive a CEBus Ack message from the recipient UMSN 125 in response to either the original or any of the re-transmissions of the LPDU, it transmits a non- CEBus standard NT DLL Nack message to the UHMN 180.
- a preferred NT DLL Ack/Nack message format is described in greater detail below, in conjunction with Figure 4.
- an LPDU may be transmitted from the UHMN 180 for more than one UMSN 125.
- each recipient UMSN 125 for whom the LPDU is sent transmits a CEBus Ack message to its respective NT 135.
- the respective NT 135 On receiving a first UMSN 125 CEBus Ack message, the respective NT 135 transmits an NT DLL Ack message to the UHMN 180 and discards any further received CEBus Ack messages corresponding to the respective LPDU.
- the UHMN 180 should send an LPDU requiring a CEBus Ack message response addressed to that UMSN 125.
- the UHMN 180 may also transmit an LPDU addressed to a specified NT 135 itself.
- the UHMN 180 may also set a specified field in the LPDU to indicate that the NT 135 should respond to the LPDU with a CEBus Ack message .
- the recipient NT 135 first responds to receipt of the LPDU message by transmitting an NT DLL Ack message to the UHMN 180.
- the NT 135 transmits a CEBus Ack message to the UHMN 180.
- an NT 135 receives an LPDU addressed for it from the UHMN 180 and the LPDU does not indicate that the NT 135 should transmit a CEBus Ack message response, the NT 135 still transmits an NT DLL Ack message to the UHMN 180 upon receipt of the LPDU.
- the UMSNs 125 may also generate messages to be transmitted to the UHMN 180. More particularly, an LPDU transmitted from a UMSN 125 for the UHMN 180 is received by the respective NT 135 of the residence 120 containing the UMSN 125. The NT 135 then transmits the LPDU to the UHMN 180 over the respective HFC 140 and WAN 175.
- the recipient NT 135 transmits a CEBus Ack message back to the respective UMSN 125, so that the CEBus Ack message is received by the UMSN 125 within the 600 sec time interval specified by the EIA/IS-60 standard; i.e., based on when the LPDU was transmitted by the UMSN 125.
- the UMSN 125 initiates a retry sequence, whereby it re-transmits the LPDU to the UHMN 180.
- the UMSN 125 repeats this retry sequence a (CEBus standard) maximum of N x 8 times, where N is in the range 0-15, or until the respective NT 135 responds to an LPDU retransmission with a timely CEBus Ack message.
- N is set to a value of 3.
- the UHMN 180 upon receiving the LPDU from the NT 135, transmits a non-CEBus standard NT DLL Ack message to the NT 135.
- Figure 2 depicts preferred message transmission protocol sequences for LPDUs transmitted from a remotely located UHMN 15 over a non-CEBus network 18, via an NT proxy node 16, to a respective UMSN 17 on a CEBus network 19.
- an LPDU 11 of the type requiring a CEBus Ack message response is 12 transmitted from the UHMN 15 and is received by the NT 16.
- the NT 16 transmits the LPDU 11 to the specified UMSN 17.
- the UMSN 17 transmits a responsive CEBus Ack message 12 to the NT 16, which is received by the NT 16 within 600 ⁇ secs of when it transmitted the LPDU 11 to the UMSN 17.
- the NT 16 Upon receiving the CEBus Ack message 12, the NT 16 transmits an NT DLL Ack message 13 to the UHMN 15, which is preferably received by the UHMN
- an LPDU 21 of the type requiring a CEBus Ack message response is transmitted from the UHMN 15 and is received by the NT 16.
- the NT 16 then transmits the LPDU 21 to the specified UMSN 17.
- the NT 16 does not receive a CEBus Ack message response from the UMSN 17 within 600 ⁇ secs of when it transmits the LPDU 21.
- the NT 16 executes one or more retry attempts, i.e., with each retry attempt consisting of re-transmitting the LPDU 21 to the UMSN 17.
- the NT 16 remains in a "retry CEBus transmission state" until it finally receives the CEBus Ack message 22 within 600 ⁇ secs of re-transmitting the LPDU 21 to the UMSN 17. Only then does the NT 16 transmit an NT DLL Ack message 23 to the UHMN 15, which should still receive the NT DLL Ack message 23 within 5 seconds of originally transmitting the LPDU 21.
- the message transmission protocol sequence for the respective LPDU 21 is now completed.
- an LPDU 31 of the type which does not require a CEBus Ack message response is transmitted from the UHMN 15 and is received by the NT 16.
- the NT 16 then transmits the LPDU 31 to the specified UMSN 17.
- the NT Upon receipt of the LPDU 31, the NT
- the NT 16 then transmits the LPDU 41 to the specified UMSN 17. In scenario 40, however, the NT 16 does not receive a CEBus Ack message from the UMSN 17 within 600 ⁇ secs of transmitting the LPDU 41 to the UMSN
- the NT 16 then re-transmits the LPDU 41 to the UMSN 17 (up to) twenty-four times, but still does not receive a CEBus Ack message from the UMSN 17 within 600 ⁇ secs of re-transmitting the LPDU 41.
- the NT 16 transmits an NT DLL Nack message 42 to the UHMN 15, which is received by the UHMN 15 within 5 seconds of when it originally transmitted the LPDU 41.
- the message transmission protocol for the respective LPDU 41 is now completed.
- the UHMN 15 may continue to re-transmit the LPDU 41 to the NT 16, based on the message type, message priority, and/or system requirements, attempting to have the LPDU 41 be successfully received and responded to by the UMSN 17.
- an LPDU 51 of the type requiring a CEBus Ack message response is transmitted from the UHMN 15 and is received by the NT 16.
- the UHMN 15 does not receive an NT DLL Ack message or an NT DLL Nack message from the NT 16 within 5 seconds of transmitting the LPDU 51.
- the UHMN 15 then re-transmits the LPDU 51 one more time, but still does not receive an NT DLL Ack message or an NT DLL Nack message from the NT 16 within 5 seconds.
- the message transmission protocol sequence for the respective LPDU 51 is now completed.
- the UHMN 15 may continue to re-transmit the LPDU 51 to the NT 16, based on the message type, message priority, and/or system requirements, attempting to have the LPDU 51 be successfully received by the UMSN 17.
- Figure 3 depicts preferred message transmission protocol sequences for LPDUs transmitted from a UMSN 57 on a CEBus network 59 to a remote UHMN 55, located on a non-CEBus network 58, via an NT proxy node 56.
- an LPDU 61 of the type requiring a CEBus Ack message response is transmitted by the UMSN 57 and received by the NT 56.
- the NT 56 then transmits the LPDU 61 to the UHMN 55.
- the NT 56 also transmits a responsive CEBus Ack message 62 to the UMSN 57, which is received by the UMSN 57 within 600 ⁇ secs of when it transmitted the LPDU 61.
- the UHMN 55 Upon receiving the LPDU 61, the UHMN 55 transmits an NT DLL Ack message 63 to the NT 56, which the NT 56 receives within five seconds of transmitting the LPDU 61.
- the message transmission protocol sequence for the respective LPDU 61 is now completed.
- an LPDU 71 of the type that does not require a CEBus Ack message response is transmitted by the UMSN 57 and received by the NT 56.
- the NT 56 then transmits the LPDU 71 to the UHMN 55.
- the UHMN 55 Upon receiving the LPDU 71, the UHMN 55 transmits an NT DLL Ack message 72 to the NT 56, which the NT 56 receives within five seconds of transmitting the LPDU 71.
- the message transmission protocol sequence for the respective LPDU 71 is now completed.
- an LPDU 81 of the type requiring a CEBus Ack message response is transmitted by the UMSN 57 and received by the NT 56.
- the NT 56 then transmits the LPDU 81 to the UHMN 55.
- the NT 56 also transmits a responsive CEBus Ack message 82 back to the UMSN 57 upon receiving the LPDU 81, which 15 the UMSN 57 receives within 600 ⁇ secs of transmitting the LPDU 81.
- the NT 56 does not receive an NT DLL Ack message from the UHMN 55 within 5 seconds of transmitting the LPDU 81 to the UHMN 55.
- the NT 56 then re-transmits the LPDU 81 to the UHMN 55, and receives an NT DLL Ack message 83 from the UHMN 55 within five seconds of its second transmission of the LPDU 81.
- the message transmission protocol sequence for the respective LPDU 81 is now completed.
- an LPDU 91 of the type requiring a CEBus Ack message response is transmitted by the UMSN 57 and is received by the NT 56.
- the NT 56 then transmits the LPDU 91 to the UHMN 55.
- the NT 56 also transmits a responsive CEBus Ack message 92 back to the UMSN 57 upon receiving the LPDU 91, which the UMSN 57 receives within 600 usec of transmitting the LPDU 91.
- the NT 56 does not receive an NT DLL Ack message from the UHMN 55 within five seconds of transmitting the LPDU 91 to the UHMN 55.
- the NT 56 then re-transmits the LPDU 91 to the UHMN 55, but still does not receive an NT DLL Ack message from the UHMN 55 within five seconds.
- the message transmission protocol sequence for the respective LPDU 91 is now completed.
- the NT 56 may continue to re-transmit the LPDU 91 to the UHMN 55, based on the message type, message priority, and/or system requirements, attempting to have the LPDU 91 be successfully received and responded to by the UHMN 55.
- an LPDU 101 of the type that does not require a CEBus Ack message response is transmitted by the UMSN 57 and is received by the NT 56.
- the NT 56 then transmits the LPDU 101 to the UHMN 55.
- the NT 56 does not receive an NT DLL Ack message from the UHMN 55 within five seconds of transmitting the LPDU 101 to the UHMN 55.
- the NT 56 then re-transmits the LPDU 101 to the UHMN 55, but still does not receive an NT DLL Ack 16 message from the UHMN 55 within five seconds.
- the message transmission protocol sequence for the respective LPDU 101 is now completed.
- the NT 56 may continue to re-transmit the LPDU 101 to the UHMN 55, based on the message type, message priority, and/or system requirements, attempting to have the LPDU 101 be successfully received and responded to by the UHMN 55.
- a UHMN, each NT, and each UMSN has a processor and associated memory (not shown) , for executing the instructions necessary to perform the above-described protocol and exemplary protocol sequences.
- Figure 4 depicts a preferred format for a non-CEBus standard NT DLL Ack/Nack message 400 for use in a network configuration of Figure 1.
- Each byte, or octet, of the NT DLL Ack/Nack message 400 is 8 bits.
- a first, and most significant, byte of the NT DLL Ack/Nack message consists of a control byte 401.
- the value of control byte 401 is set to OxFF hex.
- the next two bytes of the NT DLL Ack/Nack message 400 consist of an NT device address field 402.
- An NT device address is a unique address assigned to each NT 135.
- the NT device address field 402 of an NT DLL Ack/Nack message carries the address of the NT 135 to whom, or from whom, the NT DLL Ack/Nack message is transmitted.
- the next two bytes of an NT DLL Ack/Nack message 400 consist of an NT "house code" field 403.
- NTs 135, which are interconnected through the same physical medium, or even interconnected through multiple physical media may comprise a group that is assigned a unique house code.
- the NT house code field 403 of an NT DLL Ack/Nack message 400 comprises a code assigned to a group in 17 which the NT 135 receiving or transmitting the respective NT DLL Ack/Nack message 400 is a part of.
- the next two bytes of an NT DLL Ack/Nack message 400 consist of a destination device address field 404.
- the destination device address field 404 is set to the address of a specified UMSN 125, (or more generically, a CEBus device) to which the original LPDU was transmitted, i.e., the original LPDU being the initiation of the message protocol sequence resulting in the respective NT DLL Ack/Nack message 400. If the original LPDU was transmitted to more than one CEBus device, the destination device address field 404 of the respective NT DLL Ack/Nack message 400 is set to a broadcast device address that the CEBus devices for whom the LPDU was transmitted share in common.
- the next byte of the NT DLL Ack/Nack message 400 consists of an ack/nack code field 405, which is used to identify whether the message is an NT DLL "Ack" message or an NT DLL "Nack” message.
- the value of field 405 is set to 0x00 hex to indicate the message is an NT DLL Ack message, and to 0x01 hex to indicate the message is an NT DLL Nack message .
- next three bytes of an NT DLL Ack/Nack message 400 are a reserved field 406, the bits of this field 406 reserved for future use .
- the final, and least significant byte of the NT DLL Ack/Nack message 400 consists of a Frame Check Sequence ("FCS") field 407.
- FCS is an encoded value appended to each message to allow detection of transmission errors in the physical channel.
- the FCS field 407 carries an 8-bit checksum value. While embodiments and applications of preferred apparatus and methods for employing a communication protocol proxy that enables a CEBus network to be mapped across a non-CEBus network have been shown and described, as would be apparent to those skilled in the art, many modifications and applications are possible without departing from the inventive concepts herein.
- a UHMN may be implemented as any device that is situated on a non- CEBus network.
- a non-CEBus network may also be a local area network ("LAN") or a point-to-point network.
- LAN local area network
- a UMSN may be any CEBus device that a remote controller wishes to access.
Abstract
Description
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP98919767A EP0976224A1 (en) | 1997-04-16 | 1998-04-14 | Cebus data link layer proxy |
AU72480/98A AU7248098A (en) | 1997-04-16 | 1998-04-14 | Cebus data link layer proxy |
CA002285972A CA2285972A1 (en) | 1997-04-16 | 1998-04-14 | Cebus data link layer proxy |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/843,461 US6073266A (en) | 1997-04-16 | 1997-04-16 | Cebus data link layer proxy |
US08/843,461 | 1997-04-16 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO1998047267A1 true WO1998047267A1 (en) | 1998-10-22 |
Family
ID=25290053
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US1998/007504 WO1998047267A1 (en) | 1997-04-16 | 1998-04-14 | Cebus data link layer proxy |
Country Status (6)
Country | Link |
---|---|
US (1) | US6073266A (en) |
EP (1) | EP0976224A1 (en) |
CN (1) | CN1260929A (en) |
AU (1) | AU7248098A (en) |
CA (1) | CA2285972A1 (en) |
WO (1) | WO1998047267A1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1113626A1 (en) * | 1999-12-30 | 2001-07-04 | Sony International (Europe) GmbH | Interface link layer device to build a distributed network |
EP1115228A1 (en) * | 2000-01-05 | 2001-07-11 | Siemens Aktiengesellschaft | Network coupling device and data network with this coupling device |
Families Citing this family (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7054271B2 (en) | 1996-12-06 | 2006-05-30 | Ipco, Llc | Wireless network system and method for providing same |
US8982856B2 (en) | 1996-12-06 | 2015-03-17 | Ipco, Llc | Systems and methods for facilitating wireless network communication, satellite-based wireless network systems, and aircraft-based wireless network systems, and related methods |
JP3214450B2 (en) * | 1998-06-05 | 2001-10-02 | 日本電気株式会社 | Proxy call control device in ATM subscriber communication network |
US8410931B2 (en) | 1998-06-22 | 2013-04-02 | Sipco, Llc | Mobile inventory unit monitoring systems and methods |
US6891838B1 (en) | 1998-06-22 | 2005-05-10 | Statsignal Ipc, Llc | System and method for monitoring and controlling residential devices |
US6914893B2 (en) | 1998-06-22 | 2005-07-05 | Statsignal Ipc, Llc | System and method for monitoring and controlling remote devices |
US6437692B1 (en) | 1998-06-22 | 2002-08-20 | Statsignal Systems, Inc. | System and method for monitoring and controlling remote devices |
US7650425B2 (en) | 1999-03-18 | 2010-01-19 | Sipco, Llc | System and method for controlling communication between a host computer and communication devices associated with remote devices in an automated monitoring system |
US7263073B2 (en) * | 1999-03-18 | 2007-08-28 | Statsignal Ipc, Llc | Systems and methods for enabling a mobile user to notify an automated monitoring system of an emergency situation |
US6317854B1 (en) * | 1999-05-14 | 2001-11-13 | Nokia Corporation | Apparatus, and associated method, for selecting retransmission of packet data |
US6816512B2 (en) * | 1999-12-30 | 2004-11-09 | General Instrument Corporation | Arrangement for managing multiple telephone lines terminating at a single location |
US6836737B2 (en) | 2000-08-09 | 2004-12-28 | Statsignal Systems, Inc. | Systems and methods for providing remote monitoring of consumption for a utility meter |
US7552239B2 (en) * | 2001-05-14 | 2009-06-23 | Canon Information Systems, Inc. | Network device mimic support |
US7480501B2 (en) | 2001-10-24 | 2009-01-20 | Statsignal Ipc, Llc | System and method for transmitting an emergency message over an integrated wireless network |
US8489063B2 (en) | 2001-10-24 | 2013-07-16 | Sipco, Llc | Systems and methods for providing emergency messages to a mobile device |
US7424527B2 (en) | 2001-10-30 | 2008-09-09 | Sipco, Llc | System and method for transmitting pollution information over an integrated wireless network |
US20030083758A1 (en) * | 2001-11-01 | 2003-05-01 | Williamson Charles G. | Remote updating of intelligent household appliances |
US20030083028A1 (en) * | 2001-11-01 | 2003-05-01 | Williamson Charles G. | Remote programming of radio preset stations over a network |
US20030080113A1 (en) * | 2001-11-01 | 2003-05-01 | Williamson Charles G. | Intelligent oven appliance |
US20040015609A1 (en) * | 2002-07-18 | 2004-01-22 | International Business Machines Corporation | Method and system for conversion of message formats in a pervasive embedded network environment |
US7756956B2 (en) | 2002-11-14 | 2010-07-13 | Canon Development Americas, Inc. | Mimic support address resolution |
US8031650B2 (en) | 2004-03-03 | 2011-10-04 | Sipco, Llc | System and method for monitoring remote devices with a dual-mode wireless communication protocol |
US7756086B2 (en) | 2004-03-03 | 2010-07-13 | Sipco, Llc | Method for communicating in dual-modes |
US9439126B2 (en) | 2005-01-25 | 2016-09-06 | Sipco, Llc | Wireless network protocol system and methods |
US20090285138A1 (en) * | 2008-05-13 | 2009-11-19 | Tzero Technologies, Inc. | Maintaining wireless communication between Consumer Electronic Control devices |
US8755388B2 (en) * | 2008-09-19 | 2014-06-17 | Qualcomm Incorporated | System and method for acknowledgement packet transmitting and receiving |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0658026A2 (en) * | 1993-12-10 | 1995-06-14 | International Business Machines Corporation | A method and system for transmitting data packets in a distributed data processing system |
WO1997009800A2 (en) * | 1995-08-29 | 1997-03-13 | Open Systems Communications Marketing, Inc. | Modular communications and applications control system |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1990015394A1 (en) * | 1989-06-02 | 1990-12-13 | Aisi Research Corporation | Appliance interface for exchanging data |
US5471190A (en) * | 1989-07-20 | 1995-11-28 | Timothy D. Schoechle | Method and apparatus for resource allocation in a communication network system |
US5268666A (en) * | 1991-12-23 | 1993-12-07 | At&T Bell Laboratories | Appliance control system providing out-of-context usage |
US5544036A (en) * | 1992-03-25 | 1996-08-06 | Brown, Jr.; Robert J. | Energy management and home automation system |
US5809076A (en) * | 1993-03-31 | 1998-09-15 | Panasonic Technologies, Inc. | Method for automatically independently providing asynchronous brouter address information to remote control units |
US5485630A (en) * | 1994-03-31 | 1996-01-16 | Panasonic Technologies, Inc. | Audio/video distribution system |
US5500794A (en) * | 1994-03-31 | 1996-03-19 | Panasonic Technologies, Inc. | Distribution system and method for menu-driven user interface |
US5495239A (en) * | 1994-08-02 | 1996-02-27 | General Electric Company | Method and apparatus for communicating with a plurality of electrical metering devices and a system control center with a mobile node |
US5572438A (en) * | 1995-01-05 | 1996-11-05 | Teco Energy Management Services | Engery management and building automation system |
US5859848A (en) * | 1995-01-26 | 1999-01-12 | Canon Kabushiki Kaisha | Asynchronous transfer mode packet conversion to one of plural formats |
US5805591A (en) * | 1996-02-28 | 1998-09-08 | Ericsson Raynet | Subscriber network interface |
-
1997
- 1997-04-16 US US08/843,461 patent/US6073266A/en not_active Expired - Lifetime
-
1998
- 1998-04-14 AU AU72480/98A patent/AU7248098A/en not_active Abandoned
- 1998-04-14 CA CA002285972A patent/CA2285972A1/en not_active Abandoned
- 1998-04-14 EP EP98919767A patent/EP0976224A1/en not_active Withdrawn
- 1998-04-14 WO PCT/US1998/007504 patent/WO1998047267A1/en not_active Application Discontinuation
- 1998-04-14 CN CN98806127.9A patent/CN1260929A/en active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0658026A2 (en) * | 1993-12-10 | 1995-06-14 | International Business Machines Corporation | A method and system for transmitting data packets in a distributed data processing system |
WO1997009800A2 (en) * | 1995-08-29 | 1997-03-13 | Open Systems Communications Marketing, Inc. | Modular communications and applications control system |
Non-Patent Citations (1)
Title |
---|
HARGADEN P J ET AL: "FUNCTIONS AND OPERATIONS OF CEBUS ROUTERS", IEEE TRANSACTIONS ON CONSUMER ELECTRONICS, vol. 37, no. 2, 1 May 1991 (1991-05-01), pages 135 - 143, XP000234470 * |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1113626A1 (en) * | 1999-12-30 | 2001-07-04 | Sony International (Europe) GmbH | Interface link layer device to build a distributed network |
US7180904B2 (en) | 1999-12-30 | 2007-02-20 | Sony Deutschland Gmbh | Interface link layer device to build a distributed network |
EP1115228A1 (en) * | 2000-01-05 | 2001-07-11 | Siemens Aktiengesellschaft | Network coupling device and data network with this coupling device |
US6904042B2 (en) | 2000-01-05 | 2005-06-07 | Siemens Aktiengesellschaft | Network coupling device and data network with network coupling device |
Also Published As
Publication number | Publication date |
---|---|
AU7248098A (en) | 1998-11-11 |
EP0976224A1 (en) | 2000-02-02 |
US6073266A (en) | 2000-06-06 |
CA2285972A1 (en) | 1998-10-22 |
CN1260929A (en) | 2000-07-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6073266A (en) | Cebus data link layer proxy | |
US5949779A (en) | Multiprotocol adaptor for communication between CEBus devices and remote controllers over an ATM-based broadband access network | |
US6058355A (en) | Automatic power outage notification via CEBus interface | |
US6456631B1 (en) | Communication control equipment and communication control method | |
US5898387A (en) | Modular meter based utility gateway enclosure | |
US5896382A (en) | Method and apparatus for communicating information between a headend and subscriber over a wide area network | |
EP0560886B1 (en) | Multiaccess carrier sensing network communication protocol with priority messages | |
US20060062192A1 (en) | Method for wireless access system supporting multiple frame types | |
US4775974A (en) | Multipoint satellite packet communication system | |
EP1113626B1 (en) | Interface link layer device to build a distributed network | |
US5457689A (en) | High speed polling protocol for multiple node network with sequential flooding of a polling message and a poll-answering message | |
EP2178248A1 (en) | A method to improve channel utilization in a time division multiple access based protocol | |
WO1998048536A2 (en) | Communications module based repeater | |
US9026878B2 (en) | Apparatus and method for fast retransmission in a power line communication network | |
JP2001077831A (en) | Communication controller, method, communication system and program storage medium | |
Cisco | LLC2 and SDLC Commands | |
Cisco | LLC2 and SDLC Commands | |
Cisco | LLC2 and SDLC Commands | |
Cisco | LLC2 and SDLC Commands | |
Cisco | LLC2 and SDLC Commands | |
Cisco | LLC2 and SDLC Commands | |
Cisco | LLC2 and SDLC Commands | |
Cisco | LLC2 and SDLC Commands | |
WO2009009918A1 (en) | Data transmission and encapsulation | |
JP4013393B2 (en) | Wireless communication method and apparatus |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WWE | Wipo information: entry into national phase |
Ref document number: 98806127.9 Country of ref document: CN |
|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE GH GM GW HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): GH GM KE LS MW SD SZ 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 BF BJ CF CG CI CM GA GN ML MR NE SN TD TG |
|
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
ENP | Entry into the national phase |
Ref document number: 2285972 Country of ref document: CA Ref document number: 2285972 Country of ref document: CA Kind code of ref document: A |
|
WWE | Wipo information: entry into national phase |
Ref document number: 72480/98 Country of ref document: AU |
|
WWE | Wipo information: entry into national phase |
Ref document number: 1998919767 Country of ref document: EP |
|
WWP | Wipo information: published in national office |
Ref document number: 1998919767 Country of ref document: EP |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
NENP | Non-entry into the national phase |
Ref document number: 1998544217 Country of ref document: JP |
|
WWW | Wipo information: withdrawn in national office |
Ref document number: 1998919767 Country of ref document: EP |