Patent Application
20150244604
Embodiments of the present subject matter generally relate to the field of communication devices and, more particularly, to powerline communication (PLC) devices.
Network devices have evolved to operate with multiple communication technologies (e.g., various combinations that may include wireless local area network (WLAN) technologies, PLC technologies, and multimedia over coaxial (MoCA), IEEE 1901, Ethernet, etc.). Each communication technology may have unique requirements such as protocols, message formats, and testing procedures.
To ensure that a network device meets networking specifications, performance requirements, and/or regulations, testing procedures may be executed to confirm that the device operates in accordance with each relevant communication technology. Testing may also be referred to as “certification” or “validation.” However, testing procedures for a first communication technology (e.g., Ethernet) may not be applicable to a second communication technology (e.g., PLC). Furthermore, performance of a communication medium may be determined differently for different communication technologies.
Disclosed are testing procedures and associated messaging to test a PLC device and performance of a PLC medium. In one embodiment, a first device transmits a test setup request message including at least one test parameter to a second device via a powerline communication (PLC) medium. The first device conducts a test, via the PLC medium, of the second device in accordance with the at least one test parameter. The first device determines a first performance metric associated with the test.
In other embodiments, the first device may cause the second device to transmit a test traffic message to the first device. The first device can receive the test traffic message from the second device and determine a second performance metric associated with the first device based, at least in part, on the test traffic message.
The present embodiments may be better understood, and numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.
The description that follows includes exemplary systems, methods, techniques, instruction sequences, and computer program products that embody techniques of the present subject matter. However, it is understood that the described embodiments may be practiced without these specific details. For instance, although examples refer to using a high-definition multimedia interface (HDMI) protocol for testing an embedded PLC device, embodiments are not so limited. In other embodiments, other suitable communication protocols and standards (e.g., a serial peripheral interface (SPI) protocol, a universal serial bus (USB) protocol, a universal asynchronous receiver/transmitter (UART), User Datagram Protocol (UDP), Transmission Control Protocol (TCP), etc.) may be used for testing the embedded PLC device. Additionally, although examples refer to testing a PLC device, in other embodiments, the test operations described herein may be executed to test network devices that implement other suitable communication protocols (e.g., multimedia over coax alliance (MoCA®)). In other instances, well-known instructions, protocols, structures, and techniques have not been shown in detail in order not to obfuscate the description.
PLC devices typically include an Ethernet interface in addition to a PLC interface. Conventional testing techniques for testing the PLC devices rely on the Ethernet interface and the Ethernet communication protocol. For example, current HomePlug® certification procedures describe testing a PLC device using the Ethernet communication protocol. In the conventional testing techniques, the PLC device may be coupled with an external testing device using the Ethernet interface of the PLC device. The external testing device may test and certify the PLC device by exchanging Ethernet messages with the PLC device via the Ethernet interface and in accordance with Ethernet-based test parameters.
However, PLC devices may not include an Ethernet interface or may not implement an Ethernet protocol due to, for example, expense and/or size of implementing the Ethernet interface on a PLC device, or due to a lack of requirements for an Ethernet interface in an embedded PLC device. Therefore, existing testing techniques may be unsuitable to test this type of PLC device.
In the present disclosure, PLC medium may be used for testing/certifying a PLC device. The PLC device being tested may or may not include an Ethernet interface. More specifically, a testing procedure using a PLC protocol via a PLC medium may be implemented. In one embodiment, a first PLC device can generate test messages and test the performance of a second PLC device without using a separate external testing device or an additional network interface (e.g., the Ethernet interface). Test procedures may be based on a server-client pseudo-relationship where a server PLC device (e.g., a first PLC device) transmits test messages via the PLC medium to a client PLC device (e.g., a second PLC device). The designation of server and client are used herein merely as descriptive of a relationship between two PLC devices in which the server PLC device has responsibility to send test traffic and/or manage the test procedures.
The server PLC device may estimate the performance (referred to as “PLC-based performance”) of the client PLC device by conducting the test via the PLC medium as will be further described with reference to
As will be further described below, the first and second device testing controllers 104, 110 may execute operations (referred to herein as test/testing operations, or test/testing procedures) for: 1) conducting a test on a PLC interface, 2) self-generating test traffic messages on the PLC medium, and/or 3) determining performance metrics based on information received from the device being tested (sometimes referred to as the device under test, or DUT). Test control messages (e.g., messages for setting up, starting, stopping, synchronizing, and monitoring the test, and requesting test results) may be sent between the first and second devices to coordinate a test procedure.
The test procedure may be used to test functionality of an embedded PLC device. In one example, the first device may be a computer while the second device may be a television. Either or both of the computer and the television may have embedded PLC devices. However, one or both of the computer and the television may not have an Ethernet interface available to coordinate testing of its respective embedded PLC device. In one example, the embedded PLC device (e.g., first device) within the computer may connect via the PLC medium to the embedded PLC device (e.g., second device) within the television. Using a test procedure described herein, the embedded PLC device within the computer can test the performance of the embedded PLC device within the television, and test the performance (e.g., bandwidth, noise level, etc.) of the PLC medium between the two embedded PLC devices.
The first device 102 and the second device 108 may each include functionality to operate in a server operating mode or a client operating mode depending on which device is being tested. Referring to
In one embodiment, the first device testing controller 104 may detect the second device 108 in response to a communication via the PLC medium 114. The first device testing controller 104 may determine to test the second device 108 in response to detecting the second device 108, or in response to activation of the test by a user. For example, the first device testing controller 104 may be activated to test the performance or standards compliance of the second PLC interface 112 in the second device 108.
This disclosure provides several examples of tests that may be performed. The tests may be performed to collect different performance metrics associated with the PLC device being tested or associated with the PLC medium. For example, the performance metrics may include one or more of: compliance with control messages, a number of bytes received, a time elapsed for the test, a signal to noise ratio, a quality metric for the PLC medium, a transmission data rate, a bit error rate, attenuation, or the like. In one example, the performance metrics may describe the performance of a tested device relative to other PLC devices or relative to a standard for powerline communications. In another example, the performance metrics may describe the PLC medium between two devices. Examples of different tests, described below, include a unidirectional test, a bidirectional test, and a mirror (loopback) test. One or more of the tests may be performed.
A unidirectional test may be used to estimate performance metrics based on test traffic messages sent in one direction on the PLC medium. For example, in a unidirectional test, the second device testing controller 110 may estimate performance metrics of the second PLC interface 112 based on the test traffic messages received from the first device 102. The second device testing controller 110 may determine the number of bytes of the test traffic messages that were received from the first device 102, the time interval between the first device transmitting the test traffic messages and the second device receiving the test traffic messages (“transit time”), attenuation of the test traffic messages, the signal-to-noise ratio (SNR) of the retransmitted test traffic messages, etc. The second device testing controller 110 may then transmit the performance metrics as the test results to the first device 102.
A bidirectional test (sometimes also referred to as a synchronized bidirectional test) may involve test traffic messages sent in both directions on the PLC medium. For example, in a bidirectional test, the first and second device testing controllers 104, 110 may exchange synchronization messages and agree on traffic parameters. For example, first and second device testing controllers 104, 110 may exchange test control messages and negotiate the test parameters for conducting the test. After selecting the test parameters, the first device 102 and the second device 108 may concurrently transmit test traffic messages. For example, the first device 102 may transmit a first set of test traffic messages to test the performance of the second PLC interface 112 of the second device 108. At the same time, the second device 108 may transmit a second set of test traffic messages to test the performance of the first PLC interface 106 of the first device 102. Alternatively, the first device 102 may transmit test traffic messages to test the performance of the second device 108; while the second device 108 may concurrently transmit data messages (e.g., including actual data and not test data) to the first device 102.
Another type of test is a mirror or loopback test, in which test traffic messages are sent in a one direction via the PLC medium and are retransmitted back in the reverse direction via the PLC medium. For example, in a mirror or loopback test, the second device 108 may simply retransmit the test traffic messages received from the first device 102 back to the first device 102. In this embodiment, the retransmitted/mirrored test traffic messages may be analyzed by the first device 102 to determine the test results. The first device testing controller 104 may estimate performance metrics associated with the second PLC interface 112 of the second device 108 based on a comparison of the originally transmitted test traffic messages and the retransmitted test traffic messages received from the second device 108. For example, the first device testing controller 104 may determine the number of bytes of the test traffic messages that were transmitted from the first device 102, the number of bytes of the retransmitted test traffic message that were received from the second device 108, the round-trip transit time, the attenuation of the retransmitted test traffic messages, the SNR of the retransmitted test traffic messages, etc.
In another embodiment of a loopback test, the first device 102 may transmit multiple test traffic messages to the second device 108. The second device 108 may temporarily buffer the received test traffic messages. In response to receiving an instruction from the first device 102, the second device 108 may retransmit the buffered test traffic messages to the first device.
In some embodiments, the first device testing controller 104 of the first device 102 (configured in the server operating mode) may determine whether the second device 108 should transmit the test results using the loopback test mode, the unidirectional test mode, or the bidirectional test mode. As described above, the first device testing controller 104 may indicate the test mode as one of the test parameters of the test setup request message. In one embodiment, the first device 102 may be preconfigured to use a particular test mode for receiving the test results. In another embodiment, the first device 102 may randomly select a test mode for receiving the test results. In another embodiment, the first device 102 may select the test mode based on processing capabilities of the first device 102 and/or the second device 108. In some embodiments, the first device 102 may conduct the test twice—for example, one test using the loopback test mode and the other test using the unidirectional test mode. In another embodiment, however, the first device 102 may conduct the test only once using any one of the test modes.
In some embodiments, the first device testing controller 104 may also translate (e.g., “convert”) the performance metrics determined using the PLC medium (“PLC-based performance metrics”) to Ethernet-based performance metrics. The first device testing controller 104 may use a PLC-to-Ethernet conversion mapping (or a PLC-to-Ethernet conversion algorithm) to determine the Ethernet-based performance metrics from the PLC-based performance metrics. In one example, the PLC-to-Ethernet conversion mapping may be determined by testing embedded PLC devices using both the PLC medium and the Ethernet medium and identifying a relationship between the PLC-based performance metrics and the Ethernet-based performance metrics. By translating the PLC-based performance metrics to Ethernet-based performance metrics, the second device 108 (e.g., the Second PLC interface 112) can be compared against other devices (e.g., PLC interfaces) that were previously tested using the Ethernet medium.
In
Example message fields for the test setup request message are depicted by Table 1.
In response to receiving the test setup request message 310, the second device 108 may determine from the test setup request message whether the second device 108 should be configured in the client operating mode. The second device 108 may determine (shown at 315) whether the second device 108 is capable of executing the test procedure identified in the test setup request message. The second device 108 can transmit a test setup confirmation message 320 to acknowledge receipt of the test setup request message. The test setup confirmation message 320 may also indicate whether the second device 108 will execute the requested test procedure. The test setup confirmation message 320 may also indicate that the second device 108 has been configured to operate in the client operating mode for the test procedure.
Example message fields for the test setup confirmation message 320 are depicted in Table 2
After receiving the test setup confirmation message 320 from the second device 108, the first device testing controller 104 may optionally transmit a test start message 330 to the second device 108. The test start message 330 may indicate that the first device 102 will start transmitting test traffic messages 350, 351. 352 to the second device 108. The test start message 330 may indicate a time period, time delay, or duration associated with the test traffic messages 350, 351, 352.
Example message fields for the test start message 330 are depicted in Table 3. The message format described in Table 3 may also be used as a test stop message, described below.
In some embodiments, after receiving the test start message 330 from the first device 102, the second device 108 may transmit a test start confirmation message 332 to the first device 102. Example message field for the test start confirmation message 332 are depicted in Table 4. The message format described in Table 4 may also be used as a test stop confirmation message, described below.
In one embodiment of a testing procedure, the first device 102 transmits test traffic messages 350, 351, 352 to the second device 108 after receiving the test setup confirmation message 320 or the test start confirmation message 332. The test traffic messages 350, 351, 352 may include predetermined data (or payload) for transmission to the second device 108. Alternatively, the test traffic messages 350, 351, 352 may include randomly generated data. The data/payload that is transmitted in the test traffic messages 350, 351, 352 may be determined based, at least in part, on a model or simulation of the traffic in the communication network. In some embodiments, the first device 102 may generate the data to be transmitted in the test traffic messages 350, 351, 352. For example, the first device testing controller (not shown) or a traffic generation unit (not shown) may be used to generate the data to be transmitted in the test traffic messages 350, 351, 352.
After the first device 102 transmits a predetermined number of test traffic messages 350, 351, 352 to the second device 108 and/or after the duration for conducting the test elapses, the first device 102 may transmit a test stop message 340 to the second device 108. The test stop message 340 may indicate that the first device 102 will not transmit additional test traffic messages to the second device 108 and that the second device 108 should end monitoring for the test traffic messages. An example format of the test stop message 340 is described in Table 3, above. In response to receiving the test stop message 340, the second device 108 may transmit a test stop confirmation message 342 to the first device 102. An example format of the test stop confirmation message 342 is described in Table 4, above.
In response to receiving the test stop confirmation message 342, the first device 102 may transmit a test results request message 360 to the second device 108. The test results request message 360 may indicate that the second device 108 should transmit the test results to the first device 102. In some embodiments, the test results request message 360 may also indicate what type of test results should be provided. For example, the test results request message 360 may indicate whether the second device 108 should provide the attenuation level and the signal-to-noise ratio (SNR) associated with the test traffic messages. Example message fields for the test results request message 360 are depicted in Table 5.
The second device 108 may determine the test results (shown at 355) from the test traffic message 350, 351, 352. In response to the test results request message 360, the second device 108 may transmit a test results confirmation message 362 including the test results. An example format of the test results confirmation message 362 will be further described in Table 6. Example test results that may be included in the test results confirmation message 362 will be further described in Table 7.
Example message fields for the test results confirmation message are depicted in Table 6.
Example message sub-fields for the test result data field are depicted in Table 7.
Although examples describe the first device 102 transmitting the test results request message 360 and the second device transmitting the test results confirmation message 362, embodiments are not so limited. In some embodiments, the first device 102 may notify the second device (e.g., in the test setup request message 310) to operate using the loopback test mode. In response to receiving a test traffic message 350,351,352 from the first device 102, the second device 108 may immediately retransmit the test traffic message (not shown) back to the first device 102. In the loopback test mode, because the first device 102 determines the performance metrics based on the test traffic messages retransmitted from the second device 108, the first device may not transmit the test results request message to the second device 108.
In some embodiments, after the first device 102 determines the performance of the second device 108, the second device 108 may execute the operations described above for testing the first device 102. For example, the second device 108 may transmit a test setup request message (not shown) to configure the second device 108 in the server operating mode and to configure the first device 102 in the client operating mode. The second device testing controller 110 may then transmit other test control messages (not shown) and test traffic messages as described above to estimate the performance of the first device 102.
The first host device 402 includes a host testing controller 410. The second host device may or may not include a host testing controller 412. As will be further described below, the operations for testing an embedded PLC device may be driven by the external host device. In this embodiment, the testing functionality (e.g., the first and second device testing controllers 104, 110) implemented on the first and second devices 102, 108 may be bypassed in favor of the testing functionality on the first and second host devices 402, 404. In other words, in the example of
The first and second host devices 402, 404 may operate in a server operating mode or a client operating mode depending which of the PLC device 102, 108 is being tested. Referring to
The host testing controller 410 (of the first host device 402) may detect the second device 108, and determine to test the second PLC interface 112 of the second device 108. The host testing controller 410 may generate a test setup request message to prompt the host testing controller 412 to initiate the test operations at the second host device 404. The test setup request message may include an indication that the second host device 404 (and the second device 108) should operate in the client operating mode. The test setup request message may also indicate a test mode, a time interval for executing the test operations, etc. as described with reference to
In accordance with the TMDS protocol, a transmitting device (e.g., the first host device 402) utilizes an encoding algorithm that minimizes electromagnetic interference over the communication medium and that enables robust clock recovery at a receiving device (e.g., the first device 102) to achieve high skew tolerance. To encode the test traffic messages and the test control messages, the host testing controller 410 may implement a two-stage TMDS protocol that converts an 8-bit input into a 10-bit output symbol. In the first stage, the first input bit is untransformed. Each subsequent input bit is either XOR or XNOR transformed against the previous input bit. Whether to execute XOR and XNOR transformation between two consecutive input bits is selected by determining which transformation will result in the fewest transitions in the output symbol. The ninth bit of the output symbol indicates whether the XOR transformation or XNOR transformation was performed. In the second stage, the first eight bits (after transformation) may be inverted to balance the number of ones and zeros in the output symbol and to have an approximately constant average DC level. The tenth bit of the output symbol indicates whether the inversion operations were performed.
After encoding the test setup request message, the host testing controller 410 may transmit the encoded test setup request message to the first device via the communication link 406 (e.g., an HDMI communication link, a DVI communication link, etc.). The first device testing controller 104 may forward the encoded test setup request message from the first PLC interface 106 of the first device 102 to the second PLC interface 112 of the second device 108 via the PLC medium 114. The second device testing controller 110 of the second device 108 may forward the test setup request message to the second host device 404. The host testing controller 412 may determine whether to operate in the client operating mode and whether to execute the test operations. The host testing controller 412 may generate a test setup confirmation message to acknowledge receipt of the test setup request message and to indicate whether the second host device 404 (and the second device 108) will execute the test operations. The host testing controller 412 may also encode the test setup confirmation message using the TMDS protocol and may transmit the encoded test setup confirmation message to the second device 108. The second device testing controller 110 may forward the encoded test setup confirmation message from the second PLC interface 112 of the second device 108 to the first PLC interface 106 of the first device 102. If determined to execute the test operations, the host testing controller 412 can configure the second host device 404 in the client operating mode.
After receiving the test setup confirmation message from the second device 108, the host testing controller 410 may transmit a test start message to the second host device 404 to indicate that the first host device 402 will start transmitting test traffic messages. The host testing controller 410 may generate the test start message, encode the test start message (e.g., using the TMDS protocol), and provide the encoded test start message to the first device 102. The first device testing controller 104 may forward the encoded test start message from the first PLC interface 106 to the second PLC interface 112 of the second device 108. The second device testing controller 110 may forward the encoded test start message to the second host device 404. In response, the host testing controller 412 may generate an encoded test start confirmation message and may similarly transmit the encoded test start confirmation message to the first host device 402 via the second device 108 and the first device 102.
The first host device 402 transmits the test traffic messages to the second host device 404 via the first device 102 and the second device 108 after receiving the test start confirmation message. In some embodiments, the first host device 402 may encode the test traffic messages prior to transmitting the test traffic messages. In other embodiments, however, the first host device 402 may not encode the test traffic messages to obtain an accurate representation of the performance of the second PLC interface 112 and the PLC medium.
After transmitting a predetermined number of test traffic messages and/or after the duration for transmitting the test traffic messages elapses, the host testing controller 410 may generate a test stop message. The test stop message may indicate that additional test traffic messages will not be transmitted. The host testing controller 410 may encode the test stop message and transmit the encoded test stop message to the second host device 404 via the first device 102 and the second device 108 as described above. In response to receiving the test stop message, the second host device 404 may transmit an encoded test stop confirmation message to the first host device 402. In response to receiving the test stop confirmation message, the host testing controller 410 may generate and transmit an encoded test results request message to the second host device 404 via the first device 102 and the second device 108. As described with reference to
The host testing controller 412 and/or second device testing controller 110 may transmit a test results confirmation message including the test results in response to receiving the test results request message. Additionally, the host testing controller 412 may also determine how to transmit test results to the first host device 402 based, at least in part, on the test mode received from the first host device 402 in the test setup request message, as described above with reference to
In some embodiments, the host testing controller 410 may also translate PLC-based performance metrics of the second PLC interface 112 to Ethernet-based performance metrics. The host testing controller 410 may use a PLC-to-Ethernet conversion mapping or a PLC-to-Ethernet conversion algorithm to determine the Ethernet-based performance metrics from the PLC-based performance metrics. By translating the PLC-based performance metrics to Ethernet-based performance metrics, the second device 108 (e.g., the second PLC interface 112) can be compared against other devices (e.g., PLC interfaces) that are associated with the Ethernet-based performance metrics.
In some embodiments, after the first host device 402 determines the performance of the second PLC interface 112 of the second device 108, the second host device 404 may execute the operations described above for testing the first PLC interface 106 of the first device 102 as described above with reference to
At block 502, a first device transmits a test setup request message including at least one test parameter to a second device via a powerline communication (PLC) medium. For example, the first device can transmit the test setup request message in response to detecting activation of a trigger unit associated with the first device. The test parameter can indicate which of the devices should be configured in the server operating mode and the client operating mode. In one embodiment, the first device may configure itself in the server operating mode in response to detecting activation of its trigger unit. The test parameter may indicate that the second device should be configured in the client operating mode. Configuring the second device in the client operating mode can indicate that first device will execute test operations to test the second device and the PLC medium. The test parameter may also indicate which test to conduct (e.g., a unidirectional test, a bidirectional test, a loopback test, etc.). Other test parameters could be indicated, including a test duration, traffic type, number of bytes that will be transmitted, packet length, etc. The flow continues at block 504.
At block 504, the first device conducts a test of the second device based, at least in part, on the at least one test parameter. After the first device is configured in the server operating mode and the second device is configured in the client operating mode, the first device can transmit a test start message to the second device. The test start message can indicate that the first device will start transmitting test traffic messages to test the PLC interface of the second device and to test the PLC medium. After receiving a test start confirmation message from the second device, the first device can start transmitting the test traffic messages. The number of test traffic messages transmitted may depend on the test parameters transmitted in the test setup request message. After the duration for conducting the test elapses (or after a predetermined number of test traffic messages have been transmitted), the first device transmits a test stop message to the second device to indicate that additional test traffic messages will not be transmitted. After receiving a test stop confirmation message from the second device, the first device can transmit a test results request message to the second device. The first device can transmit the test results request message to prompt the second device to transmit test results to the first device. The flow continues at block 506.
At block 506, the first device determines a performance metric associated with the test. In response to transmitting the test results request message, the first device may receive a test results confirmation message from the second device. The test results confirmation message may include test results as described above with reference to
At block 602, a first device may transmit a test setup request message including at least one test parameter from a first device to a second device via a powerline communication (PLC) medium, the test setup request message indicating that the second device is the server for the test. At block 604, the first device may receive a test setup confirmation message from the second device. At block 606, the first device may configure itself to receive a test traffic message from the second device. At block 608, the first device may receive the test traffic message from the second device. The test traffic message may include predetermined test data known to the first device and the second device. At block 610, the first device may determine a performance metric associated with the test, wherein the performance metric describes at least one of a PLC interface of the first device and the PLC medium between the first device and the second device.
In another embodiment, the first device can send test traffic messages (not shown) and subsequently receive a re-transmission of the test traffic messages from the second device. The test traffic messages re-transmitted from the second device may be a mirrored transmission of the test traffic messages originally transmitted by the first device. The first device may estimate the performance of the PLC interface of the second device based on the test traffic messages originally transmitted from the first device and the retransmitted test traffic messages received from the second device. Additionally, the first device may estimate the performance (e.g., bandwidth) of the PLC medium between the first device and the second device.
In some embodiments, the first device may translate the PLC-based performance metrics determined on the PLC medium to corresponding Ethernet-based performance metrics associated with the Ethernet medium. The translated performance metrics may be used to compare the PLC interface of the second device relative to a PLC interface of another device that was tested using an Ethernet interface.
The Figures in this disclosure, including
For example, PHY layer performance may be measured for a PLC embedded device. The PLC embedded device may implement the features described herein to initiate a test responsive to activation of a trigger unit. In one embodiment, a user can cause the PLC embedded device to initiate a test mode (e.g., by pressing a push button or other activation means). Upon activation, the PLC embedded device initiates the embedded test mode setup process. For example, the PLC embedded device may configure itself as server and send a command to a second PLC device requesting the second PLC device to configure itself as client. The server and client may communicate the test parameters using management messages as described herein to perform tests of the PHY layer performance.
MAC layer performance metrics may also be measured using the techniques described herein. For example, the tests described in
Although the Figures describe the first device configuring itself in the server operating mode if the trigger unit associated with the first device is activated, embodiments are not so limited. In other embodiments, the first device may configure itself in the client operating mode after detecting activation of its trigger unit. The first device may transmit a test setup request message to the second device. The test parameters in the test setup request message may indicate that the second device should configure itself in the server operating mode to test the PLC interface of the first device. After configuring itself in the server operating mode, the second device may transmit other test control messages (e.g., the test start message, test stop message, test results request message, etc.) and the test traffic messages to the first device to conduct the test. The second device can test the performance of the PLC interface of the first device based on test results received from the first device as similarly described above with reference to
Although the Figures describe the first device transmitting test control messages and test traffic messages to the second device to test the performance of the second device, embodiments are not so limited. In other embodiments, the first device may transmit the test control messages and the test traffic messages to the second device to test the performance of the PLC interface of the first device. The first device may transmit the test traffic messages to the second device. In one embodiment, the second device may estimate the performance of the PLC interface of the first device based on the test traffic messages received from the first device. In another embodiment, the second device may re-transmit the test traffic messages to the first network device. The first network device may estimate the performance of its PLC interface based on the test traffic messages transmitted from the first device and the retransmitted test traffic messages received from the second device.
Although the host-driven testing mechanism of
In another implementation, the PLC-capable device under test (and configured in the client operating mode) may be coupled with a host device. The PLC-capable device conducting the test (and configured in the server operating mode) may not be coupled with a host device. Referring to the example of
In one embodiment, a communication system may include a first device communicatively coupled with a second device for performance testing. The first device may be configured to transmit a test setup request message including test parameters to the second device via a powerline communication (PLC) medium. The first device may be configured to conduct a test of a PLC interface of the second device in accordance with the test parameters and determine a performance metric associated with the PLC interface of the second device based, at least in part, on the test. The second device may be configured to determine how to transmit test results to the first device based, at least in part, on the test parameters in the test setup request message.
As will be appreciated by one skilled in the art, aspects of the present subject matter may be embodied as a system, method, or computer program product. Accordingly, aspects of the present subject matter may take the form of an entirely hardware embodiment, a software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present subject matter may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Any combination of one or more non-transitory computer readable medium(s) may be utilized. Non-transitory computer-readable media comprise all computer-readable media, with the sole exception being a transitory, propagating signal. The non-transitory computer readable medium may be a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
Computer program code embodied on a computer readable medium for carrying out operations for aspects of the present subject matter may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the present subject matter are described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the present subject matter. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The electronic device 700 also includes a device testing controller 708. In some embodiments, the device testing controller 708 may implement functionality to test the performance of the PLC interface of another electronic device. The device testing controller 708 can transmit test control messages to configure another electronic device in a client operating mode (“client electronic device”) and to subsequently test the PLC interface of the client electronic device. The device testing controller 708 may transmit test traffic messages to the client electronic device and determine test results based on information received from the client electronic device. The device testing controller 708 may determine the performance of the PLC interface of the client electronic device and the PLC medium from the test results as described above. In another implementation, the electronic device 700 may be a host device that is communicatively coupled with and that drives a PLC-capable device. In this implementation, the device testing controller 708 (of the host device) can generate test control messages and test traffic messages for testing the client electronic device and the PLC medium. The device testing controller 708 may or may not encode the test control messages and the test traffic messages depending on whether the client electronic device is communicatively coupled with a host device. The device testing controller 708 may determine test results based on information received from the client electronic device. The device testing controller 708 may determine the performance of the PLC interface of the client electronic device and the PLC medium from the test results as described above. In some embodiments, the electronic device 700 may include a trigger unit 712, a virtual button on a display (not shown), a switch (not shown), or other activation means capable of detecting an activation request by a user. Responsive to the activation request, the electronic device 700 may initiate a test procedure such as those described above.
Any one of these functionalities may be partially (or entirely) implemented in hardware and/or on the processor 702. For example, the functionality may be implemented with an application specific integrated circuit (ASIC), in logic implemented in the processor 702, in a co-processor on a peripheral device or card, etc. In some embodiments, the device testing controller 708 can each be implemented on a system-on-a-chip (SoC), an ASIC, or another suitable integrated circuit to enable communications of the electronic device 700. In some embodiments, the device testing controller 708 may include additional processors and memory, and may be implemented in one or more integrated circuits on one or more circuit boards of the electronic device 700. Further, realizations may include fewer or additional components not illustrated in
While the embodiments are described with reference to various implementations and exploitations, it will be understood that these embodiments are illustrative and that the scope of the present subject matter is not limited to them. In general, techniques for testing PLC devices as described herein may be implemented with facilities consistent with any hardware system or hardware systems. Many variations, modifications, additions, and improvements are possible.
Plural instances may be provided for components, operations, or structures described herein as a single instance. Finally, boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the present subject matter. In general, structures and functionality presented as separate components in the exemplary configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the present subject matter.
This application claims the priority benefit of U.S. Provisional Application Ser. No. 61/943,872 filed Feb. 24, 2014.
| Number | Date | Country | |
|---|---|---|---|
| 61943872 | Feb 2014 | US |
