Software upgrade in a home network using lower layer messaging

Abstract

Principles, apparatuses, systems, circuits, methods, and computer program products for performing a software upgrade in a MoCA network includes receiving an image of a software upgrade at a server and sending the image in the MoCA network using an L2ME message channel to a client that is enabled to receive the image and store the image in a client memory. The image may be broken up into packets, and a sequence number may be assigned to each packet to assist the client in assembling them. CRC information may also be appended to the packets to enable the client to verify their contents.

Claims

1. A method of performing a software upgrade in a Multimedia Over Coax Alliance (MoCA) network, comprising: initiating the software upgrade, via a service provider, by pushing a first wave submit message to a MoCA gateway, wherein the MoCA gateway does not interpret the contents of the first wave submit message; pushing a first wave request message, via the MoCA gateway, to a television set top box in the MoCA network; passing a second wave response, via the MoCA gateway, to the service provider; transmitting an image of a software upgrade, over a communication network external to a coaxial cable network of a home, from the service provider to a first transceiver of the MoCA gateway; and instructing the MoCA gateway to send the image of the software upgrade to the television set top box in the MoCA network, wherein the MoCA gateway is configured to send the image of the software upgrade over the coaxial cable network of the home via a second transceiver.

2. The method of claim 1, wherein the method comprises instructing the MoCA gateway to send the image of the software upgrade as at least one L2ME (Layer-2 Management Entity) message on an L2ME message channel.

3. The method of claim 2, wherein the at least one L2ME message comprises a message type indication that specifies to the television set top box that the L2ME message is a software upgrade.

4. The method of claim 2, wherein the at least one L2ME message comprises a plurality of packets.

5. The method of claim 4, wherein a sequence number is assigned to each packet of the plurality of packets to assist the television set top box in assembling the plurality of packets.

6. The method of claim 4, wherein a CRC (Cyclic Redundancy Check) is appended to the plurality of packets.

7. A service provider server for performing a software upgrade in a Multimedia Over Coax Alliance (MoCA) network, wherein the service provider server comprises: memory operable to store the software upgrade; a transmitter operable to: push a first wave submit message to a MoCA gateway, wherein the MoCA gateway does not interpret the contents of the first wave submit message, receive a second wave response, from the MoCA gateway, according to a first wave request message to a television set top box in the MoCA network, and transmit an image of the software upgrade, over a communication network external to a coaxial cable network of a home, from the service provider to a first transceiver of the MoCA gateway; and a processor operable to instruct the MoCA gateway to send the image of the software upgrade to the television set top box in the MoCA network, wherein the MoCA gateway is configured to send the image of the software upgrade over the coaxial cable network of the home via a second transceiver.

8. The service provider server of claim 7, wherein the processor is operable to instruct the MoCA gateway to send the image of the software upgrade as at least one L2ME (Layer-2 Management Entity) message on an L2ME message channel.

9. The service provider server of claim 8, wherein the at least one L2ME message comprises a message type indication that specifies to the television set top box that the L2ME message is a software upgrade.

10. The service provider server of claim 8, wherein the at least one L2ME message comprises a plurality of packets.

11. The service provider server of claim 10, wherein a sequence number is assigned to each packet of the plurality of packets to assist the television set top box in assembling the plurality of packets.

12. The service provider server of claim 10, wherein a CRC (Cyclic Redundancy Check) is appended to the plurality of packets.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) One or more various embodiments of the disclosed principles, apparatuses, methods, systems, and computer program products are described with reference to the following figures. The drawings are provided for purposes of illustration only and merely depict examples of some disclosed embodiments to facilitate the reader's understanding. They should not be considered to limit the breadth, scope, or applicability of the claimed invention. It should be noted that for clarity and ease of illustration these drawings are not necessarily made to scale. The figures are not intended to be exhaustive or to limit the claimed invention to the precise form disclosed. It should be understood that the disclosed principles, apparatuses, methods, systems, and computer program products can be practiced with modification and alteration, and that the invention should be limited only by the claims and the equivalents thereof.

(2) FIG. 1 shows an example MoCA network used in a home media network.

(3) FIG. 2 shows a block diagram illustrating an example of a software upgrade hardware configuration using a MoCA interface.

(4) FIG. 3 shows a sequence diagram illustrating an example of a software upgrade process.

(5) FIG. 4 shows an example of a possible payload construction for each upgrade packet.

(6) FIG. 5 is a sequence diagram illustrating an example of a two-wave push message L2ME transaction.

(7) FIG. 6 shows an example of an L2ME payload for the PUSH message example illustrated in FIG. 5.

(8) And FIG. 7 is a sequence diagram illustrating an example of a two-wave get push message acknowledgement L2ME transaction.

(9) In the various figures of the drawing, like reference numerals denote like or similar parts.

DETAILED DESCRIPTION

(10) The disclosed are principles, apparatuses, methods, systems, and computer program products perform a software upgrade using a MoCA interface. A block diagram of one example of a construction for a system 40 to perform the software upgrade using MoCA interface is shown in FIG. 2, to which reference is now additionally made.

(11) The system 40 includes a server 42 and at least one client 44. The server 42 includes an ECL (Ethernet Convergence Layer) 46, a memory 48, and hardware and software to provide a MoCA MAC (Media Access Control) layer 50 and a MoCA PHY (physical) layer 52. The ECL is described in the MoCA specification, and is the boundary between the MoCA MAC layer and upper layer software, such as TCP/IP and other applications. The MoCA MAC layer is a sublayer of the data link layer and serves as an interface between the logical link control sublayer and the PHY layer. The PHY layer controls the transmission of data bits between network nodes.

(12) The client 44 is constructed in a manner that is substantially similar to the server 40, including an ECL 56, a memory 58, and hardware and software to provide a MoCA MAC layer 60 and a MoCA PHY layer 62. The server 42 and client 44 are connected, for example, by a coaxial cable 64, or the like, over which an L2ME message can be transmitted. Although only one client 44 is illustrated, it should be understood that a plurality of similarly constructed clients may exist in any particular installation.

(13) In the upgrade process, the ECL 40 receives a software image 54 to be upgraded from a central office (not shown) and stores it in its local memory 46. The central office may be, for example, a media content provider. The server 40 breaks up the software image 54, for example, into multiple small packets of 4-6 words each. (The 4-6 word size is imposed by limitations of the interface between the ECL 46 and the MoCA MAC layer 50 in current devices; however, in future products, this size may be larger, limited by the size of the maximum payload allowed by the L2ME messages of the systems.)

(14) After the software update image has been received and packetized, the ECL 40 of the server 42 assigns a sequence number and appends CRC (Cyclic Redundancy Check) information to each packet to ensure the client can assemble these packets into the software image. The ECL 56 of the server 42 then sends the packets over the coaxial cable 64 to the ECL 56 of the client 44, using the proprietary L2ME messages. The client 44 receives the packets, and, after CRC verification, writes them to a nonvolatile memory 66 to store the software image.

(15) FIG. 3 to which reference is now additionally made shows an example sequence diagram for the software upgrade process. For simplicity, the NC (Network Controller), which may be involved in relaying L2ME messages, is not shown. The upgrade process begins by the server 42 sending a message 70 to the client 44 to begin a software upgrade. The server then sends a request acknowledgement message 72 to the client asking for acknowledgment that the client is ready to receive the software upgrade. The client 44 responds with an acknowledgement message 74.

(16) The server then begins the process of sending the software image packets to the client 44, sending software payload #1 76 to the client 44. After software payload #1 has been sent, the server 42 sends a receive acknowledgement message 78 to the client 44 indicating that software payload #1′ has been sent, to assure that software payload #1 has been received. The client 44 responds with an acknowledgement message 80. The server 42 then sends software payload #2 82 to the client 44. After software payload #2 has been sent, the server 42 sends a receive acknowledgement message 84 to the client 44 indicating that software payload #2′ has been sent, to assure that software payload #2 has been received. The client 44 responds with an acknowledgement message 86. The process is repeated until all of the software image packets have been sent and received.

(17) After the entire software image packets have been sent and received, the server sends a message 90 to the client 44 to switch to the new image. The server 42 then requests acknowledgment 92 from the client 44 that the client 44 has received the message 90. The client 44 responds with an acknowledgement message 94. The client 44 then switches to the new software image.

(18) FIG. 4, to which reference is now additionally made, shows one possible format 120 by which the L2ME payload of the three message types, “begin SW upgrade,” “SW upgrade payload (#N),” and “switch to new SW image,” shown in FIG. 3 may be constructed. The first set of information contains packet type information 104 in the first byte of the first word 122. The second set of information contains packet length information 106 in the next two bytes of the first word 122. And the third set of information contains the first byte, BYTE 1, 108 of the payload in the last byte 108 of the first word 122. The remaining words 123-127 each contain four bytes of the software update image.

(19) The packet type information 104 specifies the type of information of the packet type parameter, can be anything agreed to between the server and client, for example:

(20) TABLE-US-00001 #define UPGRADE_PKT 1 #define START_UPGRADE_PKT 2 #define SWITCH_TO_NEW_IMAGE 3

(21) The packet length information 106 is zero if the packet type information 104 is START_UPGRADE_PKT or SWITCH_TO_NEW_IMAGE. However, the packet length information 106 is non-zero if the packet type information 104 is UPGRADE_PKT. The packet length information 106 is the number of bytes of the upgrade packet and has a maximum length of 360 bytes. (It should be noted that the current software implementation has a 21-byte limitation with respect to the maximum number of upgrade packet bytes; however, future implementations will be able to support the maximum possible payload size of 360 bytes allowed by L2ME transactions.)

(22) Examples of vendor specific L2ME messages that can be used to support the above-described software upgrade process include a “push message” L2ME transaction and a “get push message acknowledgement” L2ME transaction. An example of the “push message” L2ME transaction 140 is illustrated in the sequence diagram of FIG. 5, to which reference is now additionally made. The process begins in a first wave, wave 0, by an entry node 142 pushing a “submit” message to the network controller 146. The entry node 142 is the server performing the software upgrade. The network controller 146 does not interpret the contents of the submit message 144, unless the network controller 146, itself, is part of the node bit mask requested by entry node 142.

(23) The network controller 146, in turn, pushes a request message 148 to the other nodes in the MoCA network, collectively indicated by the reference numeral 150. The network controller 146 creates the wave 0 request message 148 based on the submit message 144 received from the entry node server 142. The network controller copies the information from the submit message 144 into the request message 148 appropriately, including both the L2ME header and the payload information.

(24) In response to the request from the network controller 146, the other nodes 150 send responses 152 . . . 153 back to the network controller 146 in accordance with the wave 0 node mask. The wave 0 response from the nodes 150 does not contain any payload. The nodes that understand the wave 0 request will set an INTERPRETED bit to “1” in the RESP_STATUS field of the response message.

(25) The network controller 146 then passes a concatenated response 155 from all the client nodes 150 from wave 0 back to the entry node 142 in a second wave, denoted wave 1, and the entry node 142 acknowledges the request with an acknowledge message 157 to close the transaction. Since there is no payload in the wave 1 request, the request primarily contains a list of all nodes that reported with the INTERPRETED bit set. It should be noted that the entry node MoCA MAC layer can communicate the response to ECL software that is responsible for the software upgrade process.

(26) An example of the basic format submit message 144 follows the submit message format specified in the MoCA 1.1 specification table 2.2. Following are specific values to be filled in SUBMIT message for PUSH transaction:

(27) VENDOR_ID=0x10 (Vendor ID)

(28) TRANS_TYPE=1 (Network Management type)

(29) TRANS_SUBTYPE=3 (PUSH transaction)

(30) WAVE0_NODEMASK=bit mask indicating all client node IDs that need to receive this PUSH message

(31) MSG_PRIORITY=64

(32) TXN_LAST_WAVE_NUM=1

(33) The push message can also be used for other purposes such as node discovery. For example, a client node can initiate a push message. An examples of a possible push message includes:

(34) #define PUSH_NODE_INFO 4

(35) The payload for this case may be: Vendor ID—byte 1 & byte 2 Hardware version ID—byte 2, byte 3, byte 4 and byte 5 Chip ID—byte 6, byte 7, byte 8 and byte 9 Software version ID—byte 10, byte 11, byte 12 and byte 13 MAC Address—byte 14, byte 15, byte 16, byte 17, byte 18 and byte 19

(36) The packet length of the push message of this example would be set to 19 in this case.

(37) An example of the L2ME message payload 160 for the push message 144 is shown in FIG. 6, to which reference is now additionally made. The push message 160 includes a vendor identification 162, a request number 164, and a number of vender payload words 166-177. The vendor identification may be an OEM's/Service Provider's vendor ID of an OEM or service provider and may or may not be same as the VENDOR ID in the L2ME message SUBMIT header. The vendor identification should not exceed a 16-bit value. The request number 164 can be used as a transaction identification and can be used to verify that the clients correctly received the request. The request number range is 0-255. The request number should not be used as a software upgrade packet sequence number due to limitation on value range. The last six words 166-171 are for vendor specific information. Each word is 32 bits wide. For software upgrade purposes, this can contain one of the packet formats described above with reference to FIG. 4.

(38) It should be noted that L2ME procedure ensures reliable delivery of the software upgrade payload to the MoCA MAC layer running on the client nodes. The ECL of the server has to periodically poll and retrieve the payload from the MoCA MAC layer on the client nodes. The ECL on the server can retrieve the entire L2ME payload of the push message 144. A software development kit (SDK) is available to provide APIs to allow this retrieval Entropic Communications, Inc. of San Diego, Calif. Thus, the acknowledgements received from client nodes 150 as part of the L2ME transactions are not sufficient for the server to ensure that the ECL on the client nodes received the vendor payload. To confirm that the ECL has received the payload, another L2ME transaction called “get push acknowledgement” may be employed. That transaction gets acknowledgement from the ECL that the payload has been received. In a “get push acknowledgement” transaction, the client nodes 150 will return the “request number” received in the push transaction as a part of a push acknowledgement L2ME transaction (described below).

(39) It is optional for the server to initiate a push acknowledgement transaction following a push transaction. A push acknowledgement transaction ensures an end-to-end (i.e., server-client) acknowledgement. If the push acknowledgement transaction is not initiated, the server must ensure a sufficient time gap between successive push transactions (i.e., successive upgrade packets) to ensure that the previous packet is not overwritten before the ECL on the client retrieved it. The actual time gap is implementation dependent and has to be determined by the amount of time it takes complete one push L2ME transaction plus the periodicity of polling by the client.

(40) If the server decides to initiate a push acknowledgement transaction, it is possible sometimes the push acknowledgement returns with a failure (for example, if the ECL at the client has not retrieved the upgrade packet yet). In such cases, the server has to retry the push acknowledgement. Another possibility is to introduce a delay between push and push acknowledgement.

(41) As mentioned above, the entry node 150 server may initiate a get push message acknowledgement L2ME transaction to confirm that the ECLs at all the clients in the other nodes 150 have successfully received the payload from a previously sent push message. Alternatively, a user may initiate a push acknowledgement L2ME transaction. In either event, the get push message acknowledgement L2ME transaction or the push acknowledgement L2ME transaction are optional messages and that improve the robustness of a transaction end-to-end. However, these messages may also add extra messages on the wire and potentially extra time to the software upgrade process. An example of a sequence diagram of the get push message acknowledgement L2ME transaction 180 is illustrated in FIG. 7, to which reference is now additionally made. Those skilled in the art will recognize that the sequences of a push acknowledgement L2ME transaction that is initiated by a user will be substantially similar to those shown in the example of the server initiated get push message acknowledgement L2ME transaction.

(42) The process begins in a first wave, wave 0, by an entry node 142 pushing a wave 0 submit “get message acknowledgement” message 184 to the network controller 146. The L2ME header for the submit get push message acknowledgement L2ME message is similar to the push message described above with reference to FIG. 6, except the transaction subtype is TRANS_SUBTYPE=2 (GET PUSH ACK) and the payload is a 32 bit field containing the request number. The value contained in the request number has to be identical to the value sent in the push message.

(43) The network controller 146 does not interpret the contents of the submit message 184, unless the network controller 146, itself, is part of the node bit mask requested by entry node 142. After the network controller 146 has received the submit message 184, it copies the information from the submit message 184 into a request message 188, including both the L2ME header and the payload information. The network controller then broadcasts, or pushes, the request message 188 to the other nodes 150 in the MoCA network.

(44) In response to the request from the network controller 146, the other nodes 150 send responses 192 . . . 193 back to the network controller 146 in accordance with the wave 0 node mask. The nodes that understand the wave 0 request will respond with the INTERPRETED bit to set to “1.”

(45) The response also contains a payload of 32 bits comprising the ECL acknowledgement status as follows:

(46) Value of “1” indicates ECL successfully acknowledged;

(47) Value of “0” indicates ECL has not acknowledged.

(48) The network controller 146 then passes a concatenated response 195 from all the client nodes 150 from wave 0 back to the entry node 142 in a second wave, denoted wave 1, and the entry node 142 acknowledges the request with an acknowledge message 196 to close the transaction. There is no payload in the wave 1 request, hence the request primarily contains list of all nodes that reported with INTERPRETED bit set. It should be noted that the entry node MoCA MAC layer can communicate the response to ECL software that is responsible for the software upgrade process.

(49) It should be apparent from the above that the methods and techniques described above for upgrading software of a client processor in a MoCA network can be accomplished in software, contained for example in at least one computer program product, such as a memory, or other computer usable medium having a computer readable program code embodied therein. In the examples described above with regard, for example, to FIGS. 2, 3, 5, and 7, instances of the computer usable medium and computer readable program code thereon may be located at any or all of the various locations described. Thus, an instance of the computer usable medium and computer readable program code thereon may be located in one of, or all of, the server, network controller, client(s) entry node, or other MoCA node on or serving the MoCA network.

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

(51) Although the disclosed method and apparatus is described above in terms of various exemplary embodiments and implementations, it should be understood that the various features, aspects and functionality described in one or more of the individual embodiments are not limited in their applicability to the particular embodiment with which they are described. Thus, the breadth and scope of the claimed invention should not be limited by any of the above-described exemplary embodiments.

(52) Terms and phrases used in this document, and variations thereof, unless otherwise expressly stated, should be construed as open ended as opposed to limiting. As examples of the foregoing: the term “including” should be read as meaning “including, without limitation” or the like; the term “example” is used to provide exemplary instances of the item in discussion, not an exhaustive or limiting list thereof; the terms “a” or “an” should be read as meaning “at least one,” “one or more” or the like; and adjectives such as “conventional,” “traditional,” “normal,” “standard,” “known” and terms of similar meaning should not be construed as limiting the item described to a given time period or to an item available as of a given time, but instead should be read to encompass conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future. Likewise, where this document refers to technologies that would be apparent or known to one of ordinary skill in the art, such technologies encompass those apparent or known to the skilled artisan now or at any time in the future.

(53) A group of items linked with the conjunction “and” should not be read as requiring that each and every one of those items be present in the grouping, but rather should be read as “and/or” unless expressly stated otherwise. Similarly, a group of items linked with the conjunction “or” should not be read as requiring mutual exclusivity among that group, but rather should also be read as “and/or” unless expressly stated otherwise. Furthermore, although items, elements or components of the disclosed method and apparatus may be described or claimed in the singular, the plural is contemplated to be within the scope thereof unless limitation to the singular is explicitly stated.

(54) The presence of broadening words and phrases such as “one or more,” “at least,” “but not limited to” or other like phrases in some instances shall not be read to mean that the narrower case is intended or required in instances where such broadening phrases may be absent. The use of the term “module” does not imply that the components or functionality described or claimed as part of the module are all configured in a common package. Indeed, any or all of the various components of a module, whether control logic or other components, can be combined in a single package or separately maintained and can further be distributed in multiple groupings or packages or across multiple locations.

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