HK1155867B - A method for use of the nodes in home communication network - Google Patents

Description

Method for using nodes in a home communication network

Technical Field

The present invention relates to information networks, and more particularly to a method of transmitting information (e.g., media information) over communication lines (e.g., coaxial cables) that form a communication network.

Background

It is well known that general home network technology employs coaxial cables. The multimedia over coax alliance (MoCA) provides a suitable specification (MoCA 1.1) at its website www.mocalliance.org for digital video and entertainment networking over existing coaxial cable in the home, which has been released to open members. The present invention is referenced to the MoCA 1.1 specification and incorporates the entire contents thereof.

Coaxial cable home networks tap into the vast amount of unused bandwidth available on home coaxial cables. Over 70% of homes in the united states have coaxial cables installed on the home infrastructure. One or more major entertainment consumption locations, such as a living room, multimedia room, and home, many have been deployed with coaxial cables, which is ideal for network configurations. The home network technology enables family members to use this infrastructure as a network system and deliver entertainment and information programs with high QoS (quality of service).

Coaxial cable home network technology provides high speed (270mbps), high QoS, and inherent security brought by the shield, wired connection in combination with the state of the art packet data level encryption technology. Coaxial cable is designed to carry high bandwidth video. Today, coaxial cable is commonly used to securely deliver millions of dollars per day of pay-per-view and high-priced (premium) video content. The coaxial cable home network may also serve as a backbone for multiple wireless access points to extend the coverage of the wireless network throughout the user's residence.

A coax home network provides a constant, high-throughput, high-quality connection over existing coax to the video devices in the home. The coaxial cable home network provides the primary link for digital entertainment and may also cooperate with other wired and wireless networks to spread the entertainment experience throughout the home.

Currently, coaxial cable home networks work in conjunction with access technologies such as ADSL and VDSL services or Fiber To The Home (FTTH), these accesses typically enter the home over twisted pair or fiber, operating at a frequency band from a few hundred KHz to 8.5MHz for ADSL and 12MHz for VDSL. After the service arrives at home through xDSL or FTTH, it can be routed to video equipment through coax home networking technology and indoor coax. Cable services, such as video, audio and internet access, may be provided to the home by a cable operator over coaxial cable and used to reach various cable service consuming devices in various rooms of the home using the coaxial cable routed within the home. Generally, coaxial cable home network type services run in parallel with wireline services on different frequencies.

It is therefore desirable to achieve the selection by the selection of SRV nodes selected by MoCA devices connected to the MoCA home network.

Disclosure of Invention

A system and/or method is provided for selecting a Selected Service Node (SSN) using MoCA devices connected via 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.

According to an aspect of the present invention, there is provided a method of using a node in a home communication network, the communication network comprising a plurality of nodes and a coaxial cable, the method comprising:

submitting a query message using an ingress node, the query message being in a selected field of a device attribute information element in an L2ME protocol, the ingress node being a node requiring advanced services and the ingress node being unaware of which of a plurality of nodes is the node selected to support advanced services on the network, the selected field including a vendor specific field;

distributing the query message to a plurality of nodes;

determining, in response to the query message, which of the plurality of nodes are selectable to support advanced services on the network;

propagating information about which of the plurality of nodes can be selected to support the advanced service on the network to each of the plurality of nodes that can be selected to support the advanced service on the network; and

a determination is made as to whether a node of the plurality of nodes has been selected to support the advanced service on the network.

Preferably, the vendor-specific field includes at least one of a TLV type, a TLV length, and a TLV value field.

Preferably, the method comprises: if there is no node chosen at the end of the query, the portal node is used to select itself to support advanced services on the network.

Preferably, the method comprises: the portal node is used to send an advertisement to the network regarding the portal node's own choice.

Preferably, the method comprises: if there are no selected nodes at the end of the query, the node with the smallest node Identifier (ID) is selected to support the advanced services on the network.

Preferably, the method comprises: advertising to the plurality of nodes that the node with the smallest node identifier has been selected to support the advanced service on the network.

Preferably, the method comprises: if the communication link between the selected node and the network is terminated, a communication is sent to the network via a network advertisement.

According to an aspect of the present invention, there is provided a method of using a node in a home communication network, the communication network comprising a plurality of nodes and a coaxial cable, the method comprising:

submitting a query message using an ingress node, the query message being in at least one of TLV type, TLV length and TLV value fields of a device attribute information element in an L2ME protocol, the ingress node being a node requiring advanced services and the ingress node not knowing which of a plurality of nodes is a node selected to support advanced services on a network, the selected field including a vendor specific field;

distributing the query message to a plurality of nodes;

determining, in response to the query message, which of the plurality of nodes are selectable to support advanced services on the network;

propagating information about which of the plurality of nodes can be selected to support the advanced service on the network to each of the plurality of nodes that can be selected to support the advanced service on the network; and

a determination is made as to whether a node of the plurality of nodes has been selected to support the advanced service on the network.

Preferably, the method comprises: if there is no node chosen at the end of the query, the portal node is used to select itself to support advanced services on the network.

Preferably, the method comprises: the portal node is used to send an advertisement to the network regarding the portal node's own choice.

Preferably, the method comprises: if there are no selected nodes at the end of the query, the node with the smallest node Identifier (ID) is selected to support the advanced services on the network.

Preferably, the method comprises: advertising to the plurality of nodes that the node with the smallest node identifier has been selected to support the advanced service on the network.

Preferably, the method comprises: if the communication link between the selected node and the network is terminated, a communication is sent to the network via a network advertisement.

According to an aspect of the present invention, there is provided a method of using a node in a home communication network, the communication network comprising a plurality of nodes and a coaxial cable, the method comprising:

submitting a selection message using an ingress node, the selection message being in a selected field of a device attribute information element in an L2ME protocol, the ingress node being a node requiring advanced services and the ingress node being unaware of which of a plurality of nodes is the node selected to support advanced services on the network, the selected field including a vendor specific field;

distributing the selection message to a plurality of nodes;

determining, in response to the selection message, which of the plurality of nodes can be selected to support advanced services on the network;

propagating information about which of the plurality of nodes can be selected to support the advanced service on the network to each of the plurality of nodes that can be selected to support the advanced service on the network; and

a determination is made as to whether a node of the plurality of nodes has been selected to support the advanced service on the network.

Preferably, the vendor-specific field includes at least one of a TLV type, a TLV length, and a TLV value field.

Preferably, the method comprises: if there are no nodes chosen at the end of the selection, the portal node is used to select itself to support advanced services on the network.

Preferably, the method comprises: the portal node is used to send an advertisement to the network regarding the portal node's own choice.

Preferably, the method comprises: if there are no selected nodes at the end of the selection, the node with the smallest node Identifier (ID) is selected to support the advanced services on the network.

Preferably, the method comprises: advertising to the plurality of nodes that the node with the smallest node identifier has been selected to support the advanced service on the network.

Preferably, the method comprises: if the communication link between the selected node and the network is terminated, a communication is sent to the network via a network advertisement.

According to an aspect of the present invention, there is provided a method of using a node in a home communication network, the communication network comprising a plurality of nodes and a coaxial cable, the method comprising:

submitting an acknowledgement message using an ingress node, the acknowledgement message being in at least one of TLV type, TLV length, and TLV value fields of a device attribute information element in an L2ME protocol, the ingress node being a node requiring advanced services and the ingress node being unaware of which of a plurality of nodes is a node selected to support advanced services on a network, the selected field comprising a vendor specific field;

distributing the acknowledgement messages to a plurality of nodes;

in response to the acknowledgement message, a reply message is received from a node that can be selected to support the advanced service on the network.

Preferably, the method comprises: the portal node is used to send an advertisement to the network regarding the portal node's own choice.

Drawings

FIG. 1 is a schematic diagram of an embodiment of messages exchanged in the L2ME protocol used in accordance with the present invention;

fig. 2 is a schematic diagram of an embodiment of messages exchanged in an SRV node selection process according to the present invention;

FIG. 3 is a schematic diagram of an embodiment of an SRV node selection query using an L2ME submit (submission) rule in accordance with the present invention;

FIG. 4 is a schematic diagram of the details of each message exchanged in the node selection process in accordance with the present invention;

FIG. 5 is a schematic diagram of the details of each message exchanged in the node confirmation process in accordance with the present invention;

FIG. 6 is a table of IEEE SRV device attribute Information Elements (IEs);

FIG. 7 is a schematic diagram of a single chip or multi-chip module of the present invention in a data processing system.

Detailed Description

Various embodiments are described below with reference to the accompanying drawings, which form a part hereof, and in which are 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 to the embodiments set forth herein without departing from the scope and spirit of the present invention.

After reading the following description, it will be apparent to one skilled in the art that various features described herein can be implemented in a method, data processing system, or computer program product. Accordingly, these features may be embodied entirely in hardware, entirely in software, or in a combination of hardware and software. Furthermore, the above-described features may also be embodied in the form of a computer program product stored on one or more computer-readable storage media having computer-readable program code segments or instructions embodied in the storage medium. Any use of a computer-readable storage medium may be utilized including hard disks, CD-ROMs, optical storage devices, magnetic storage devices, and/or any combination of the foregoing.

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

For ease of reference, the following glossary gives the meanings of the various abbreviations and symbols used in the present patent application:

the digital PHY includes MoCA IC ports that form signal transmission paths to and from the receiver and/or transceiver ICs

EN MoCA existing node (the term "node" may be replaced with "module" herein)

IE Information Element (Information Element)

L2ME (MoCA) layer 2 management entity

MAC media Access control-comprising MoCA Integrated Circuit logic that schedules digital PHYs to be turned on and off when signals need to be transmitted to and/or received from a receiver and/or transceiver Integrated Circuit

MAP media Access plan

NC MoCA network controller

Physical layer of PHY MoCA network

QoS quality of service

SRV service-generic name of service running in a higher layer with respect to the MoCA layer

SRV node selected by SSN (SRV selection node) — node selected for running SRV service (for all devices connected to the same network)

Some advanced services implemented on MoCA networks, such as IEEE 802.1 audio video bridging system (AVB) broadband reservations, require the MoCA network to select a node to run a predetermined service for the entire MoCA network.

If the service is optional, the network control Node (NC) may not support this optional service. If the NC does not support the optional service, the NC cannot be selected as the SSN. Alternatively, any node that supports SRV-i.e., is capable of supporting the advanced service (although optional) -may be selected as the SSN. In some embodiments of the present invention, the SRV node selection protocol described herein is preferably orthogonal (orthogonall) to NC selection and NC handover/backup.

In some embodiments of the invention, possible SSN selection rules for selecting SRV nodes are as follows:

these rules include the inquiry messages that need to be sent by any SRV-capable node that is admitted to the network, one embodiment of which is described below in connection with fig. 2 and the corresponding portions of the description.

After the query is completed, any SRV-capable node (SRV-selected node) that shares the same SRV node query related information (which is forwarded through the ingress node) may be used as an SRV-selected node (SRV-selected node). Further, after the query is completed, preferably all SRV-capable nodes (including the ingress node, as defined below) share the same information: regarding which nodes on the network are SRV-capable and which node (if any) is an SRV selection node.

If no node has been selected at the end of the query, the portal node may select itself as the selected node and send an advertisement (notification) of its own selection to the network. Alternatively, other nodes that support SRV may be selected and the NC notified of the selection.

Another embodiment of the present invention employs the following efficient techniques to support dynamic SRV selection.

This topology change is achieved at least in part by network advertisement if the SRV selection node is removed from the network (or by shutting down/failing and/or conserving power as appropriate).

The SRV enabled node with the smallest node id (nid) becomes the SRV selection node and submits a selection to advertise the selection to other nodes.

This scheme is preferably fully compatible with the current MoCA specification and does not require any modification to the specification.

In some embodiments of the invention, when the selected SRV node fails to perform (fail), other SRV-capable nodes may be dynamically selected as the new SSN. The SRV selection protocol may include a recovery protocol to dynamically select one of the nodes that support SRV as a new SRV selection node.

The SRV selection protocol may be based on the L2ME architecture message protocol specified in the MoCA 1.1 specification and/or the 2.0 specification, which are incorporated herein by reference in their entirety.

If all nodes do not support SRV, the ingress node becomes an SRV selection node.

If more than one node (other than the ingress node) is SRV enabled and none of the nodes are SRV selection nodes, the ingress node may select the SRV enabled node with the smallest NID as the SRV selection node.

When the SSN submits the SRV node selection L2ME message (see fig. 4 and corresponding description) before entering power save mode, the ingress node may reset its NID bit (bit) to correspond to the SSN bit mask (bitmask).

The entry node response may be used to confirm the SSN selection of the entry node to the NC. In response to a message from the NC regarding SSN selection, all other SRV-capable nodes may send a null response (zero-length payload) to the NC.

Fig. 1 is a schematic diagram of an embodiment of messages exchanged in the L2ME discovery protocol used in accordance with the present invention. The L2ME device discovery protocol is a protocol used by a node to discover the attributes of a particular set of other nodes.

FIG. 1 shows an exemplary client node 102, NC 104, and other nodes 106. The first message 108 in the protocol commits-i.e., the node sends a request to the NC to run a "device discovery" transaction (a multiplex exchange of information between the NC and other nodes of the network). Device discovery transaction (devicedensivediscovery transaction) enables a MoCA node to discover the capabilities of every other node. In particular, each MoCA node preferably has a set of associated attributes that characterize its capabilities, such as maximum aggregation size (aggregation size) and the amount of packet data that the node is capable of handling. These attributes are also vendor specific. The message 108 preferably includes a header indicating that the message is directed to (directto) device discovery. Message 108 also includes a payload indicating that the discovery is directed to the node attribute IE. In this way, the L2ME device discovery protocol enables any node in the MoCA network to regain the attributes of one or more particular nodes in the MoCA network.

The NC preferably broadcasts the request to the other nodes 106. The NC forwards the payload and the request. Each of the other nodes 106 sends a response, such as 112. Each of the other nodes 106 identifies them by a field (field) characterized by a particular bit configuration. This field is commonly referred to as a wave node MASK (WAVENODE MASK) or as a bit MASK or Node ID (NID) bit MASK. Such a mask preferably indicates a range of Internet Protocol (IP) addresses. These addresses may be used to identify the IP address of the SRV enabled node.

Each of the responses 112 preferably includes an attribute IE corresponding to each of the other nodes 106. At 114, the NC broadcasts the set of responses in message 114. The set and response message 114 includes a payload that includes an aggregated IE for each of the other nodes 106 that responded to device discovery.

Fig. 2 is a schematic diagram of an embodiment of messages exchanged in an SRV node selection transaction according to the present invention. Fig. 2 shows messages exchanged between SRV-enabled ingress nodes 202, NC 204 and other nodes 206. For this application, the ingress node is the node that needs the SRV service, which does not know which node is the SSN. The entry node also acts as a node that submits transaction requests (see detailed description below) to the NC. As specified by the IEEE 802.1Qat specification, for example, the SRV Protocol is used to select an assigned multi-Stream Reservation Protocol (MSRP) node (DMN).

In accordance with the method of the present invention, messages (as shown in FIG. 2) determine the SRV capabilities of each node on the network using, at least in part, the L2ME message protocol. Thus, in accordance with the device discovery protocol of the present invention, the L2ME message architecture and protocol is balanced in order to obtain information about the SRV capabilities of each node on the network.

The message protocols include wave 0208, wave 1210, wave 2212, and wave 3214. Wave 0208 includes a first message submission 216 by ingress node 202 to NC 204. The ingress node 202 is a node that requires SRV services and does not know which node is an SSN. To reiterate, the entry node 202 submits a request at 216 for an SSN transaction on the network.

At 218, NC 204 advertises the entry node's SSN request to the node. The other node 206 and the ingress node 202 respond to the SSN request 218 at 220.

In wave 1210, the NC 204 advertises a response to the SSN request to the ingress node 202 and other SRV-enabled nodes 222 at 224. Using the response received at 226, ingress node 202 may construct an SRV advertisement message indicating an SRV-capable bitmask (a bitmask that defines which nodes are SRV-capable) and an SRV selection bitmask (a bitmask that defines which nodes are SSNs (if any). In one embodiment of the invention, when the portal node determines that the network already has an SSN, the portal node defaults to the SSN already present in the network. If there is no SSN in the network, the ingress node initiates a node selection transaction to determine if the ingress node should become an SSN, or if another node (e.g., with a minimum NID) should become an SSN. At 228, the entry node transmits information about the two bitmasks to the NC.

In wave 2212, the NC 204 advertises the entry node SRV bitmask determination 226 to other SRV-enabled nodes 222 at step 230. At 232, the SRV enabled nodes 222 send their replies to the NC 204 as determined by the entry node.

In wave 3214, NC 204 may advertise the response to the SRV indication request to the entry node and other SRV enabled nodes in an L2ME link format (as suggested in MoCA Specification 1.1, which the present invention refers to and incorporates in its entirety or any other suitable MoCA Specification), as shown in step 234. Thereafter, the SRV-capable node 222 may respond to the advertisement at step 236. Ingress node 202 preferably responds to the advertisement with a null response at step 238.

Fig. 3 is a schematic diagram of an embodiment of an SRV node selection query using L2ME submission (submission) rules, in accordance with the present invention.

Wave 0308 shows that in some embodiments of the invention, any node 302 that supports SRV may submit an SRV node query to NC 304 if it is allowed to enter the network. At step 314, NC 304 may advertise the entry node's SRV query to other nodes 306. The response of the SRV enabled node 318 may indicate its corresponding SRV mode, as shown at step 316.

Wave 1310 shows that node 318 supporting SRV receives advertisement 320 from NC 304. The announcement 320 preferably includes a response to the SRV query. At step 322, a response to the SRV query 320 may be sent to the NC.

At the end of the query, all SRV-capable nodes 318, including the ingress node 304, share the same information: regarding which nodes on the network are SRV-capable nodes and which node (if any) is an SRV selection node. If there is no SRV selecting node, the SRV capable node with the smallest Node ID (NID) or any other suitable optional node may become the SRV selecting node and may be able to submit an SRV node selection message to advertise the other SRV capable nodes.

If the SRV selecting node is removed from the network (or by shutting down/powering down and/or failing as appropriate), then, in one embodiment of the invention, the SRV-capable node with the smallest NID becomes the SRV selecting node and submits an SRV node selection message to advertise the other SRV-capable nodes.

Fig. 4 is a schematic diagram of an SRV node selection query using L2ME submission rules in accordance with the present invention. In particular, fig. 4 is a schematic diagram illustrating an embodiment of a method according to the present invention that requires an SRV node to perform processing operations when the SRV selection node is powered off (e.g., by selection or due to entering a power saving mode and/or a failure). Fig. 4 shows a wave 0408 comprising communication between an ingress node 402 with a minimum node id (nid) after an SSN node link failure, an NC 404, and other SRV enabled nodes 406. According to the present invention, upon a SRV selected node being dropped, the SRV-capable node with the relatively smallest NID becomes the SRV selected node, and sends an SRV node selection submit L2ME message.

In particular, SRV selection entry node 402 preferably shows an SRV node selection commit 408. The submission preferably advertises other SRV-capable nodes about the SRV selection submission, step 410. At step 412, the SRV enabled node 402/406 sends a response to the NC 404 regarding the commit 408.

Thus, the method enables a node supporting SRV to send an SRV node optional submit L2ME message to the NC after a connection failure between the SSN and the network.

It should be reiterated that in addition to node selection at the time of failure, prior SRV selection nodes may remove themselves from a set of SRV enabled nodes and send L2ME messages indicating that they are not available before entering power save mode and/or shutting down.

An exemplary L2ME SRV acknowledgment processing transaction in accordance with the present invention is described below in fig. 5 and the corresponding portions of the specification. The NC node may begin the transaction upon receiving a submit L2ME frame from the entry node, or independently (i.e., without receiving hints from other nodes).

Figure 5 is a schematic diagram of an embodiment of an SRV node select L2ME acknowledgment processing transaction in accordance with the present invention. Shown in fig. 5 are entry node 502, NC 504, SRV enabled node 506, wave 0508, and wave 1510. Specifically, at step 512, ingress node 502 sends a submit L2ME frame to NC 504 to trigger an SRV node acknowledgement.

At step 514, the NC 504 advertises all network nodes for the SRV node acknowledgement submission of the ingress node 502.

At step 516, SRV enabled node 506 sends a response.

In some embodiments of the invention, a node (not shown) that does not support SRV may return a generic L2ME response error code.

After wave 0508, one possible embodiment of L2ME wave 1 request 510 is shown.

In wave 1510, NC 504 advertises responses in L2ME to node 502 and node 506 regarding SRV node acknowledgment submissions, step 518. This announcement may be implemented in the connection payload format available in L2 ME.

Using the response received in step 518, ingress node 502 may acknowledge the SRV advertisement message to indicate:

SRV selects NID; and

NID bitmask that supports SRV.

SRV-enabled nodes preferably include IEEE SRV device attribute information elements (see fig. 6 and description thereof) with the L2ME payload of the device discovery protocol commit L2ME transaction message as specified in the multimedia over coax alliance MoCA v2.0 specification. Such content preferably includes information that effectively forms an overlay (overlay) over the MoCA L2ME protocol. Such coverage is possible because the L2ME protocol in MoCA has provisions for delivering vendor specific information elements that are not interpreted by MoCA. Accordingly, the L2ME protocol is retained unchanged, as specified in MoCA. The only request is to get the vendor ID value (vendor ID value) assigned to the particular entity to which the SRV belongs. For example, one may have a vendor ID assigned to the company named ACME. As a result, ACME defines several TLV TYPEs (TLV TYPE) for multiple Services (SRV).

As further described herein, when the L2ME device discovery transaction is completed, preferably all SRV-capable nodes in the MoCA network may share the same information about other SRV-capable nodes. These pieces of information include:

1) which MoCA nodes are SRV enabled; and

2) which MoCA node is selected to be the SSN.

If no node is selected as SSN, SSN selection will be performed.

Fig. 6 is a table of IEEE SRV device attribute Information Elements (IEs). In general, the IEEE SRV device attributes IE field may be defined as in the table in fig. 6. The general format of the device attribute information element is described in the multimedia over coax alliance MoCA v2.0 specification, the entire contents of which are incorporated herein.

The table in fig. 6 illustrates IEEE SRV device attribute IEs showing bits (bits) 602 for each attribute number, octets (octets)604 corresponding to each attribute number, and an offset 606 for the start of each IE.

The format of the device attribute Information Element (IE) is defined in MoCA. The MoCA specification specifies that when the attribute field is set to 0xFF, the first 16 bits of the information field define the vendor ID. The vendor ID is assigned by MoCA to a particular vendor or entity.

In any event, the vendor ID is vendor specific. In the following embodiments of the invention, the TLV type, TLV length (TLV LENGTH) and TLV VALUE (TLV VALUE) are vendor specific-i.e. each vendor has a different VALUE for these fields, which is vendor specific, rather than MoCA specific. This means that vendor specific messages can be ignored-i.e., the MoCA L2ME protocol transmits these messages over MoCA without interpreting the contents of the vendor specific messages. Thus, a node using the MoCA L2ME protocol transmits an IE to other nodes without attempting to interpret vendor specific messages. Accordingly, the SRV selection protocol (which is implemented using TLV types, TLV lengths, and TLV values) is an overlay protocol over the MoCA standard L2ME protocol.

The table in fig. 6 illustrates the following attributes:

an attribute ID 608;

the value of the attribute ID is 0 xFF.

Length (UInteger8) 610;

the value of the length may be 1. In some embodiments of the present invention, the actual length of the attribute IE is (length +1) × 32 in bits.

A vendor ID 612;

the value of the vendor ID is preferably assignable by the MoCA alliance and is hereby incorporated by reference.

A TLV type 614; (e.g., SRV IEEE Audio video bridging System (AVB) (IEEE 802.1Qat) may set a TLV type value to 0. in another embodiment of the present invention, the TLV type may be specified as the same value or other suitable value for other suitable services.)

TLV length 616: (the length is the length required to implement the service specified by the TVL type 614)

A TVL value 618;

it should be noted that in accordance with the present invention, in the TLV value field, the IE may include two bitmasks (not shown): one for indicating whether the node is a SRV-capable node and the other for indicating whether the node is an SRV-selecting node.

In the first bitmask of the TVL value field, a value of 1 for the bit corresponding to the node ID indicates that the node is a node capable of supporting SRV in the network. A value of 0 indicates that the node is not capable of functioning as a SRV-capable node in the network.

In the second bitmask of the TVL value field, a value of 1 for the bit corresponding to the node ID indicates that the node is selected as a SRV node in the network. A value of 0 indicates that the node is not the selected node. Whether the selected node is present on the network, or whether there are no selected nodes on the network, needs to be determined by a second bitmask, which then indicates which nodes are SRV capable and which node should be elected as an SRV node based on a selection criterion, e.g., the node with the smallest NID. The second bitmask also indicates to other nodes that support SRV that a node has been selected as an SRV node. This prevents other nodes from requesting to become SRV nodes and causing collisions.

According to the invention, selection and validation of SRVs: if either of 1) the SRV selection node indicates that the selected SRV node has been removed from the network (due to a failure, power state/shutdown, etc.), or 2) the SRV enabled node discovery process transaction indicates that no SRV selection node has been discovered, the RSV enabled node with the smallest node ID or other suitable selected node may begin to act as an SRV and acknowledge this selection to other SRV enabled nodes by generating an L2ME SRV acknowledgement process transaction.

FIG. 7 illustrates a single-chip or multi-chip module 702, which may be one or more integrated circuits, in a data processing system 700 according to the present invention. Data processing system 700 may include one or more of the following components: I/O circuitry 704, peripherals 706, processor 708, and memory 710. These components are communicatively coupled via a system bus or other interconnection component 712 and assembled on a circuit board 720 included in an end-user system 730. System 700 may be configured for use with a cable tuner according to the present invention. It should be noted that system 700 is only an example and that the true scope and spirit of the present invention should be defined by the claims.

The foregoing describes a system and method for providing a MoCA SSN selection policy.

While the invention has been described with reference to several embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the invention. For example, those skilled in the art will appreciate that the steps illustrated in the figures may be performed in another order, and that one or more of the steps illustrated may be optional. The methods and systems of the above-referenced embodiments may also include other elements, steps, computer-executable instructions, or computer-readable data structures. In this regard, other embodiments disclosed herein may be partially or fully implemented on computer-readable media, for example, by storing computer-executable instructions or modules or by using computer-readable data structures.

Claims (9)

1. A method of using a node in a home communications network, the communications network comprising a plurality of nodes and coaxial cable, the method comprising:

submitting an inquiry message in at least one of TLV type, TLV length and TLV value fields of a device attribute information element in a layer 2 management entity and/or in a selected field, the ingress node being a node requiring advanced services and the ingress node not knowing which of a plurality of nodes is the node selected to support advanced services on the network, the selected field comprising a vendor specific field;

distributing the query message to a plurality of nodes;

determining, in response to the query message, which of the plurality of nodes are selectable to support advanced services on the network;

propagating information about which of the plurality of nodes can be selected to support the advanced service on the network to each of the plurality of nodes that can be selected to support the advanced service on the network; and

a determination is made as to whether a node of the plurality of nodes has been selected to support the advanced service on the network.

2. The method of claim 1, wherein the vendor-specific field comprises at least one of a TLV type, a TLV length, and a TLV value field.

3. The method of claim 1, wherein if there is no selected node at the end of the query, using the portal node to select itself to support advanced services on the network.

4. A method according to claim 1, characterized in that the portal node is used to send an advertisement to the network about its own choice.

5. The method of claim 1, wherein if there is no selected node at the end of the query, the node with the smallest node identifier is selected to support advanced services on the network.

6. The method of claim 5, wherein the plurality of nodes are advertised that the node with the smallest node identifier has been selected to support advanced services on the network.

7. The method of claim 1, wherein the query message is submitted using the ingress node in at least one of TLV type, TLV length, and TLV value fields of a device attribute information element in a layer 2 management entity protocol.

8. A method of using a node in a home communications network, the communications network comprising a plurality of nodes and coaxial cable, the method comprising:

submitting a selection message using an ingress node, the selection message being in a selected field of a device attribute information element in a layer 2 management entity protocol, the ingress node being a node requiring advanced services and the ingress node being unaware of which of a plurality of nodes is the node selected to support advanced services on a network, the selected field including a vendor specific field;

distributing the selection message to a plurality of nodes;

determining, in response to the selection message, which of the plurality of nodes can be selected to support advanced services on the network;

propagating information about which of the plurality of nodes can be selected to support the advanced service on the network to each of the plurality of nodes that can be selected to support the advanced service on the network; and

a determination is made as to whether a node of the plurality of nodes has been selected to support the advanced service on the network.

9. A method of using a node in a home communications network, the communications network comprising a plurality of nodes and coaxial cable, the method comprising:

submitting an acknowledgement message using an ingress node, the acknowledgement message being in at least one of TLV type, TLV length, and TLV value fields of a device attribute information element in a layer 2 management entity protocol, the ingress node being a node requiring advanced services and the ingress node being unaware of which of a plurality of nodes is a node selected to support advanced services on a network, the fields including vendor specific fields;

distributing the acknowledgement messages to a plurality of nodes;

receiving a response message from a node that can be selected to support a premium service on the network in response to the acknowledgement message;

propagating information about which of the plurality of nodes can be selected to support the advanced service on the network to each of the plurality of nodes that can be selected to support the advanced service on the network; and

a determination is made as to whether a node of the plurality of nodes has been selected to support the advanced service on the network.