阅读说明：本技术 装置、计算机程序和方法 (Apparatus, computer program and method ) 是由 罗伯特·马克·斯特凡·波特 陈建荣 理查德·库珀 于 2020-03-20 设计创作，主要内容包括：一种监测具有第一装置和第二装置的网络的方法,包括：接收来自该网络上该第一装置的包含媒体内容的IP分组,该IP分组被发送到该第二装置；分析所接收的IP分组以确定该媒体内容的参数；分析该媒体内容的参数以及与该第二装置相关联的参数；以及如果该媒体内容的该参数不同于与该第二装置相关联的该参数,则执行预定动作。(A method of monitoring a network having a first device and a second device, comprising: receiving IP packets containing media content from the first device on the network, the IP packets being sent to the second device; analyzing the received IP packets to determine parameters of the media content; analyzing parameters of the media content and parameters associated with the second device; and performing a predetermined action if the parameter of the media content is different from the parameter associated with the second device.)

1. A method of monitoring a network having a first device and a second device, comprising:

receiving IP packets containing media content from the first device on the network, the IP packets being sent to the second device;

analyzing the received IP packets to determine parameters of the media content;

analyzing the parameter of the media content and a parameter associated with the second device, wherein, in the event that the parameter of the media content is different from the parameter associated with the second device, the method comprises:

comparing the parameters to attributes of a configuration of at least one of the network, the first device, and the second device; and

a predetermined action is performed.

2. The method of claim 1, wherein the parameter of the media content is a frame rate and/or a resolution and/or a bit depth and/or a chroma format of the media content.

3. The method of claim 1, wherein the parameter of the media content is a bandwidth of the media content.

4. The method of claim 1, wherein the parameter of the media content is that the video component, audio component, and metadata component of the media content are all destined for the second device.

5. The method of claim 1, wherein the predetermined action is providing a message to a user.

6. The method of claim 5, wherein the message is an alert or a recommendation.

7. The method of claim 5, wherein the suggestion is a new configuration of at least one of the network, the first device, and the second device.

8. The method of claim 1, wherein the predetermined action is automatically applying a new configuration to at least one of the network, the first device, and the second device.

9. A method of monitoring a network having a first device and a second device, comprising:

receiving an IP packet containing control data transmitted over the network;

analyzing the received IP packet to determine a source of the IP packet; and

in the case where the source of the IP packet is not a media device, the method comprises:

determining a time delay of the IP packet; and in the case that the latency is above a threshold latency, the method comprises:

a warning is provided to the user.

10. The method of claim 9, wherein the warning is a visual warning.

11. A method of monitoring a network having a first device and a second device, comprising:

receiving a control packet transmitted from the first apparatus to the second apparatus;

receiving a response to the control packet sent from the second apparatus to the first apparatus; and

in the event that the control packet is not received from the first apparatus or the response is not received from the second apparatus within a predetermined period of time, the method comprises:

measuring a characteristic of the control packet from the first apparatus and the control packet from the second apparatus;

comparing these characteristics to characteristics of a configuration of at least one of the network, the first device, and the second device; and

a predetermined event is performed.

12. The method of claim 11, wherein the characteristic of the control packet is a time at which the control packet is transmitted and/or received.

13. The method of claim 11, wherein the nonce packet is an ARP packet or an IGMP packet.

14. The method of claim 13, wherein the known parameter of the system is a timeout event/period.

15. A computer program product comprising computer readable instructions which, when loaded onto a computer, configure the computer to perform the method of claim 1 or 11.

16. An apparatus for monitoring a network having a first apparatus and a second apparatus, comprising:

a circuit configured to:

receiving an IP packet containing media content from the first device on the network, the IP packet being sent to the second device;

analyzing the received IP packets to determine parameters of the media content;

analyzing the parameters of the media content and parameters associated with the second device;

wherein, in an instance in which the parameter of the media content is different from a parameter associated with the second apparatus, the circuitry is configured to:

comparing these parameters with properties of a configuration of at least one of the network, the first device and the second device, and

a predetermined action is performed.

17. The apparatus of claim 16, wherein the parameter of the media content is a frame rate and/or a resolution and/or a bit depth and/or a chroma format of the media content.

18. The apparatus of claim 16, wherein the parameter of the media content is a bandwidth of the media content.

19. The apparatus of claim 16, wherein the parameter is that the video component, the audio component, and the metadata component of the media content are all destined for the second apparatus.

20. The apparatus of claim 16, wherein the predetermined action is providing a message to a user.

21. The apparatus of claim 20, wherein the message is an alert or a recommendation.

22. The apparatus of claim 20, wherein the suggestion is a new configuration of at least one of the network, the first apparatus, and the second apparatus.

23. The apparatus of claim 16, wherein the predetermined action is automatically applying a new configuration to at least one of the network, the first apparatus, and the second apparatus.

24. An apparatus for monitoring a network having a first apparatus and a second apparatus, comprising:

a circuit configured to:

receiving an IP packet containing control data transmitted over the network;

analyzing the received IP packet to determine a source of the IP packet; and

in the case where the source of the IP packet is not a media device, the method comprises:

determining a time delay of the IP packet; and in the event that the time delay is above a threshold time delay, the circuitry is configured to:

a warning is provided to the user.

25. The apparatus of claim 24, wherein the warning is a visual warning.

26. An apparatus for monitoring a network having a first apparatus and a second apparatus, comprising:

a circuit configured to:

receiving a control packet transmitted from the first apparatus to the second apparatus;

receiving a response to the control packet sent from the second apparatus to the first apparatus; and

in the event that the control packet is not received from the first apparatus or a response is not received from the second apparatus within a predetermined period of time, the circuitry is configured to:

measuring a characteristic of the control packet from the first apparatus and the control packet from the second apparatus;

comparing these characteristics to known characteristics of a configuration of at least one of the network, the first device, and the second device; and

a predetermined event is performed.

27. The apparatus of claim 26, wherein the characteristic of the control packet is a time at which the control packet is transmitted and/or received.

28. The apparatus of claim 26, wherein the control packet is an ARP packet or an IGMP packet.

29. The apparatus of claim 28, wherein the known parameter of the system is a timeout event/period.

Technical Field

The present technology relates to an apparatus, a computer program and a method.

Background

The "background" description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

Professional audio-video systems (Pro-AV systems) increasingly use Internet Protocol (IP) packets to transfer audio-video (AV) data between devices. This is because existing infrastructure can be used, thereby reducing the cost of implementing such a system.

In order to convert AV data into IP packets, devices called "AV over IP" devices are sometimes used. These devices convert AV data into IP packets that are then distributed over an ethernet network, or convert IP data received from a network into AV data.

A management system is used to control the distribution of IP packets (e.g., defining the source and destination of the packets). However, the inventors have recognized that there are problems with existing systems.

As the size of networks increases, and as networks include different types of devices, the inventors have identified one or more improvements that may be made to management systems.

In particular, although the management system may establish forwarding paths between devices, the physical capacity of the network through which IP packets traverse may not be able to physically route the IP packets. Furthermore, many devices are "plug and play" type devices, in which case the settings are automatically configured when the device is connected to the network, there is an additional risk of transmitting AV data as IP packets to multiple devices in a format or resolution that is not supported by one or more devices, or in a format or resolution that is not the highest available quality supported by the receiving device.

It is an object of the present disclosure to address one or more of these issues.

Disclosure of Invention

According to an embodiment of the present disclosure, there is provided a method of monitoring a network having first and second devices, comprising: receiving an IP packet containing media content from a first device on a network, the IP packet being transmitted to the second device; analyzing the received IP packets to determine parameters of the media content; analyzing parameters of the media content and parameters associated with the second device; and performing a predetermined action if the parameter of the media content is different from the parameter associated with the second device. Other embodiments and features of the present disclosure are defined by the following claims.

The contents of the above paragraphs are intended as an overview and are not intended to limit the scope of the appended claims. The described embodiments, together with further advantages, will be best understood by reference to the following detailed description taken in conjunction with the accompanying drawings.

Drawings

A more complete appreciation of the present disclosure and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:

FIG. 1 shows a block diagram of a network 100 to which embodiments of the present disclosure are applied;

FIG. 2 illustrates a data structure associated with each device on the network stored within the memory 155 of the monitoring device 150;

FIG. 3 shows a flow chart 500 illustrating initial network function monitoring performed by the monitoring device 150;

FIG. 4 shows a flow diagram according to an embodiment;

FIG. 5 shows a timeline illustrating a problem

FIG. 6 shows a timeline illustrating a situation where the problem of FIG. 5 does not occur

Fig. 7 shows a flow diagram illustrating monitoring of a broadcast communication stream by the monitoring device 150;

fig. 8 shows a flowchart illustrating a mechanism for recognizing whether a converter or an AV device connected thereto operates incorrectly;

FIG. 9 shows a flow diagram 900 illustrating analysis of video format conversion according to an embodiment;

FIG. 10 shows a flow chart describing an embodiment of the present disclosure;

11 a-11 c show diagrams that help users visualize network problems

Fig. 12a and 12b illustrate user interfaces that help a user visualize a problem with a network.

Detailed Description

Reference is now made to the drawings, wherein like reference numerals designate identical or corresponding parts throughout the several views.

Fig. 1 depicts a block diagram illustrating a network 100 to which embodiments of the present disclosure are applied. The network 100 includes a network switch 115, the network switch 115 configured to route IP packets around the network 100. Network switch 115 may be any type of network switch capable of supporting the bandwidth required by an "AV over IP" device and capable of connecting to one or more "AV over IP" devices. Which may be a 10Gbps, 25Gbps, or 100Gbps switch. The network switch 115 may support monitoring features such as NETCONF. Further, in an example, the network switch 115 may also support packet capture or statistics generation, which may require an extended monitoring Application Programming Interface (API), or a Software Defined Network (SDN) API, such as OpenFlow. As will be understood by those skilled in the art, the network switch 115 may be considered to have a data plane and a control and monitoring plane. These two planes have been identified in the figure. Further, it is understood that although only a single network switch 115 is shown in fig. 1, the present disclosure is not so limited and network 100 according to embodiments may include multiple network switches.

Connected to a port within network switch 115 is an "AV over IP" device 120 and 123. These "AV over IP" devices convert between audio and/or video data and, where applicable, associated metadata and IP packets for distribution over the network 100 as appropriate. An example of such a device is the DisplayNet DN-200 series of devices. It should be noted that the present disclosure is not limited to "AV over IP" devices, and contemplates any device that transmits or receives media content (such as AV data) over a computer network or converts media content (such as AV data) with IP packets for distribution over a computer network. These means will be referred to as "converters" in the following. It should be understood that although a converter is described, the present disclosure is not so limited. In an example, a source or destination of AV data can locally send or receive "AV over IP. In other words, the present disclosure is not limited to the case where the converter is required to convert AV into IP data or vice versa; the AV device may locally distribute "AV over IP".

Where the "AV over IP" device is a switch, attached to each switch 120 and 123 is the source or destination of the AV data. In other words, a source or destination is a media device that is the source or destination of media content. Specifically, the television 130 is connected to the first converter 120,an optical disc player 131 is connected to the second converter 121, a Crystal Light Emitting Diode (CLED) display 132 is connected to the third converter 122, and a computer 133 is connected to the fourth converter 123. The connection between the converter and the corresponding device may be a High Definition Multimedia Interface (HDMI) connector or a Serial Digital Interface (SDI) connector, etc. Of course, the present disclosure is not limited to any one type of connector, and any type of connector capable of carrying media content is contemplated.

Also connected to the network switch 115 is a management platform 110. The management platform 110 performs various tasks. For example, management platform 110 may configure switch 120 and 123 to define which multicast groups to send from which senders and which multicast groups to receive by which recipients. The network device 115 cooperates with the SDN controller 105 to ensure that correct data is routed from the translator 120 and 123 by monitoring control signals or packets (e.g., Internet Group Management Protocol (IGMP), Address Resolution Protocol (ARP), etc.). In other networks (e.g., legacy networks), SDN controllers 105 are not present and distributed software running on each network switch 115 may provide this functionality.

The management platform 110 may also configure the translators 120 and 123 so that an administrator can configure the routing of the AV data between the translators. In other words, the management platform 110 may allow an administrator to assign priorities to various AV streams, types of data packets handled by the devices, and the like.

In the case of an SDN network, additionally connected to the network switch 115 is a Software Defined Network (SDN) controller 105. SDN controller 105 manages the flow of data traffic around the network according to forwarding policies set by a network administrator. Specifically, SDN controller 105 reacts to control packets sensed between converters 120 and 123 according to policies set by an administrator. SDN controller 105 is configured to instruct network switch 115 to send IP packets between devices based on these policies. In an embodiment, SDN controller 105 is a server (or more broadly, a computer architecture) onto which SDN applications are loaded. SDN controller 105 looks at a portion of the data traffic flow sent through network switch 115. In general, the data traffic flow (data traffic) viewed by the SDN controller 105 may be a subset of all data packets. In an embodiment, the subset may be a sample of all packets, e.g. 1 out of every 100 packets. In other embodiments, SDN controller 105 provides this functionality by capturing control packets and configuring the routing hardware of the network device (e.g., "forwarding table" including "flow entries"). Additionally, while capturing control packets to implement these forwarding policies, SDN controller 105 may also send control information to monitoring application 150 for analysis. This analysis will be explained below.

Although SDN controller 105 is described above as being able to view all (or a subset) of the data traffic, the disclosure is not so limited. In an embodiment, SDN controller 105 is configured to only look at selected traffic flows, such as low bandwidth control traffic flows, e.g. ARP, IGMP or LLDP traffic flows.

In an embodiment, the monitoring function may be implemented by replacing SDN controller 105 with a module using other APIs provided by network switch 115 (e.g., NETCONF) to obtain similar information.

A monitoring device 150 is also provided in the network 100, according to an embodiment of the present disclosure. In an embodiment, monitoring device 150 is a sub-module located within SDN controller 105. In other words, the monitoring device 150 is part of the SDN controller 150. However, in an embodiment, monitoring device 150 is a separate device that communicates with SDN controller 105 via an Application Programming Interface (API). For ease of illustration, the monitoring device 150 includes a control circuit 160 and a memory 155. The control circuit 160 may take the form of a microprocessor formed from semiconductor circuitry that controls the operation of the monitoring device 150 under the control of software. An example of the memory 155 may be a semiconductor or magnetically readable memory and configured to store software that controls the control circuit 150 and/or the state of the operating software. In embodiments where monitoring device 150 is a sub-module located within SDN controller 105, control circuitry 160 and memory 155 may be implemented within SDN controller 105.

Although not specifically shown, the monitoring device 150 may be connected to a display that is viewable by a user. Additionally or alternatively, the monitoring device 150 may generate reports for use by other tools or users to make decisions.

The monitoring device 150 receives parameters related to some or all of the IP packets sent through the network switch 115. Specifically, the monitoring device 150 receives parameters related to the media content transmitted through the network switch 115, as well as control data transmitted by each device. The control data has two levels of control data, namely, application-level control data and network-level control data. In the application-level control data, information higher than the application-level control data (e.g., video format) is provided to the monitoring device 150 by the management platform 110. In the network-level control data (e.g., ARP, IGMP data, etc.), the network-level control data is sensed by SDN controller 105 (or some other monitoring API) and passed to monitoring device 150. The monitoring device 150 analyzes application-level control data and network-level control data (hereinafter referred to as control data). The monitoring device 150 uses the media content parameters and control data to perform network traffic analysis and video configuration analysis, and thus the parameters received at the monitoring device 150 should be able to do so.

Examples of parameters received by the monitoring device 150 include network control data, such as ARP packets that facilitate mapping IP addresses to ethernet hardware addresses, or multicast control data, such as IGMP packets. Video control data, such as Extended Display Identification Data (EDID) obtained from the management platform 110, may also be included.

In addition, examples of parameters received by the monitoring device 150 also include metadata associated with broadcast media content, such as media content to be displayed on all devices connected to the network, or metadata associated with multicast media content transmitted from one device for display on a plurality of devices connected to the network or with unicast media content transmitted from one device for display on another device connected to the network. In an embodiment, the media content is multicast media content, but the disclosure is not so limited.

The parameters received by the monitoring device 150 also include information related to each device connected to the network. This includes configuration data for each device, such as the technical capabilities of each device (e.g., the resolution of images supported by the device or the frame rate of each device); any user-defined parameter, such as whether the device has a particular priority within the network or whether the device is a protected device, causes media content provided to the protected device to be prioritized over media content provided to the unprotected device. Configuration data, user-defined parameters, or whether media content is provided to a protected device are examples of attributes of a device or network. Control data of each device, such as a MAC address of each device, an IP address assigned to each device, is also provided to the monitoring device 150.

The monitoring device 150 may receive information from the SDN controller 105 or the management platform 110.

Fig. 2 illustrates a data structure associated with each device on the network stored within the memory 155 of the monitoring device 150. In an embodiment, the data structure is a database or table structure. Although the data structure of fig. 2 shows a plurality of parameters, the present disclosure is not limited thereto, and the data structure may include any parameters, such as a pixel depth/number of bits per pixel (8, 10, 12, 16, etc.) and a chroma sub-sampling format (4:2:0, 4:2:2:, 4:4:4:, etc.).

In addition to the data structures associated with each device, memory 155 will also include parameters associated with the network to which each device is connected. These network parameters may include network capacity (i.e., how much data the network can handle at any one time before a network crash occurs, acceptable latency for the network, etc.). These network parameters may be stored in the data structure of fig. 2 or elsewhere in memory 155.

In fig. 2, the data structure includes at least some of the technical capabilities of each device. For example, the frame rates supported by the devices, the resolutions supported by the devices, and the connection means supported by each device are stored in a data structure. In the example of fig. 2, the apparatus 1 has a frame rate of 60Hz, a resolution of 1920 × 1080, and supports HDMI. However, other technical capabilities of each device may be stored, including color depth factors or coefficients (number of bits/clock rate), supported compression or encoding, and so forth.

Further, although only a single value is shown in fig. 2, the present disclosure is not limited thereto. In an embodiment, multiple values may be stored for each entry in the data structure. For example, the device 1 may also support 1280x 720, 3840x 2160(4K), 7680x 4320(8K), or the like. In this case, all supported resolutions (or a subset thereof) may be included in the entry. However, in the case where there are multiple supported resolutions or frame rates, the currently used frame rate and resolution are recorded within the data structure. Additionally, where there are multiple supported resolutions or frame rates, the optimal and/or preferred frame rate and resolution are recorded within the data structure.

In addition, the expected data rates of the media content provided to or by each device are stored. In other words, the monitoring device 150 is configured to calculate the amount of expected data of the media content to be received or transmitted from each device. The value is based on the frame rate, the resolution supported by the device, and the resolution currently used by the device. Thus, for example, in the case where the apparatus 1 has a frame rate of 60Hz and a resolution of 1920 × 1080, the expected video data bandwidth per channel is 1.99 Gbps. It will be appreciated that the data volume of the media content may be predefined or loaded from a configuration file or the like. Of course, if supported compression or encoding is applied to the media content, the expected data rate may be changed. The purpose of defining the expected data rate is to identify whether the device is providing or providing media content to the device in an unsupported or unexpected format. This will have a negative effect on the operation of the device. In this case, and as will be described later, the monitoring device 150 recognizes this.

Further, control data of each device is stored in the data structure of fig. 2. In this case, the IP address and MAC address of each device are stored in a data structure. Other control data, such as an ARP cache timeout (ARP cache timeout) associated with each device connected to the network, is stored in a data structure.

Finally, user-defined data, such as whether the device is a protected device, is stored within the data structure.

The operation of the monitoring device 150 according to an embodiment will now be explained with reference to fig. 3 to 10.

Fig. 3 shows a flow chart 300 illustrating initial network function monitoring performed by the monitoring device 150. The flowchart begins at step 305. The process then proceeds to step 310, where the devices on the network are checked.

During the check in step 310, the assigned IP address of each device stored within the monitoring device 150 is checked against manually entered IP addresses or static/expected topology files defined at the time of building the network. To generate the static topology file, the network design tool may be stored within the monitoring device 150, may be generated using an external tool, or may be generated by any other suitable means. If not, a warning may be issued. To accomplish this, Link Layer Discovery Protocol (LLDP) traffic flows will be analyzed or, if LLDP is not supported, a ping command will be sent to each intended device to check the physical topology of the network 100.

Additionally, during the check in step 310, any unknown unicast or multicast destination addresses that are detected but not within the information provided by the network administrator may be identified. It will be appreciated that in embodiments this may occur at any time, as the detection will occur when the data is first sent. Furthermore, any unknown source IP address of any kind of data communication flow may be identified. This alerts the network to the presence of any illegal addresses or unexpected devices. Furthermore, as an additional security step to prevent inadvertent use of the network, monitoring device 150 may request user confirmation before allowing SDN controller 105 to add a route to an unrecognized device.

While the device is checked in step 310, the network topology is checked in step 315.

In step 315, the unmatched subnets and multicast range may be checked. In this case, the network administrator may provide information such as unicast subnets and allowed multicast ranges and check the actual configuration of the network against this information. A mismatch condition may again be identified and a warning issued.

To avoid the need to operate a separate DCHP server for the media content system, a DHCP server may be provided by the monitoring device 150 at step 315. In addition, a check will be performed to identify any problems with the corporate agent. It is particularly useful if the network 100 is bridged to a network outside of a corporate firewall.

A check may also be performed to determine if any media content packets escape the network or are being injected into the network. Other checks that may be performed include checks on corporate agents. Finally, multi-subnet detection is performed at step 315.

A further check may be provided to determine if the network 100 is a non-blocking network. In this case, any non-blocking guarantees defined within the network may be stored within the monitoring device 150 to determine whether the amount of non-media content unicast traffic on the network will break the non-blocking guarantees.

The process then ends at step 320.

In an embodiment, the device check of step 310 is performed in the ARP and IGMP processing, and the topology check of step 315 is performed when there is a topology change. Of course, the present disclosure is not limited thereto.

After the network topology has been checked and the network is operational, the monitoring device 150 begins monitoring the media content and control data flowing around the network 100.

As described above, the monitoring device 150 monitors the routing/network control data.

Fig. 4 shows a flow diagram 400 illustrating the detection and analysis of ARP packets in the monitoring device 150 according to an embodiment. It is to be appreciated that ARP packets are one example of routing and/or network control packets.

The process 400 includes a main processing thread 405 and a plurality of short-term observer processing threads 410. The main processing thread 405 begins at step 415. The main processing thread 405 then proceeds to step 420, where it waits for an ARP request from any device to be detected by the monitored device 150 (via SDN controller 105). When an ARP request packet is detected, the main processing thread 405 proceeds to step 422 and spawns the short lifetime observer thread 410. The main process then follows the "duplicate" path and awaits further ARP request data packets.

For each observer thread instance 410 (which was created in response to the relevant ARP request packet detected in step 420 of the main processing thread), the observer processing threads begin concurrently, step 425.

The observer processing then proceeds to step 428 and waits for an ARP reply to the relevant ARP request. When the relevant ARP reply is received, the process proceeds via the "receive" path to step 430. Alternatively, if the wait step times out after a period of time sufficient to conclude that no ARP reply will arrive (which period of time may be set by an administrator), then the process proceeds via the "timeout" path to step 430.

In step 430, a check is made to determine if an ARP reply is received. In the event that an ARP reply is not received, step 435 is reached along the no path, and an alarm (or other alert) is generated at step 435. The alarm indicates that an ARP packet is not sent and may be an audible alarm or a visual alarm. The alert may be any kind of event, such as an audible alert or advice provided to the user to resolve the problem. The observer then processes the event 410 to end at step 450.

Returning to step 430, if an ARP reply is received before the timeout of step 428, then step 440 is reached along the YES path. In step 440, a check is made to determine if an ARP response is received within a predetermined period of time. The predetermined time period may be set by an administrator of the network and may be less than the timeout period of step 428, but is slow for the network. If an ARP response is received within the predetermined period of time, the Yes path is followed to step 450 and the process ends.

Alternatively, where an ARP response is not received within a predetermined period of time, the NO path is followed to step 445 where an alert (or other alert) is issued indicating that the ARP response is slow. Again, the alert may be an audible or visual alert to the user, and may also include a suggestion to solve a problem or to perform any other kind of event. Processing then proceeds to step 450, where the observer processing thread 410 ends.

By providing alerts to the user, the user can analyze the network configuration and identify problems with the network. According to an embodiment, the alert accurately identifies a problem with the network. This helps the user to solve the problem. Further, as noted in other embodiments, in addition to the alert, the monitoring device 150 may provide a solution or suggestion to the problem from a database of possible solutions that the user will try. For example, in addition to issuing a warning that an ARP response timeout has occurred, the user may be guided to obtain various solutions or suggestions to address this issue. The suggestion may be a new configuration for one of the first device, the second device, and the network. In other instances, it may be possible to provide a questionnaire to the user, provide the questionnaire, allow the user to answer more questions that can better accurately identify the questions, and guide the user to obtain a more effective solution.

Fig. 5 illustrates the problem of ARP cache timeout as embodied by embodiments of the present disclosure. Which is shown as timeline 500. In step 502, the device issues an ARP request. The corresponding ARP response 504 is then received by the device. When the device issuing the ARP request writes a response to its ARP cache, an ARP cache clock is started at step 506. At the same time, the network routing clock is started at step 508. However, the network route timeout expires at step 510, and the ARP cache timeout expires at step 516. As will be seen, ARP cache timeouts expire after network route timeouts. This means that the data packet sent in time period 512 will not be delivered. This is because the ARP cache has not timed out, but the network route has timed out. Thus, the data packet will be transmitted by the device, but will not be received at the intended device.

After the ARP cache times out in period 514, the data packet sent in that period will generate an ARP request in step 518 and a corresponding ARP response in step 520. This resets the ARP cache clock and the network routing clock at steps 522 and 524.

The difference between the ARP cache timeout and the network route timeout means that the data packet sent in time period 512 will not be delivered.

Fig. 6 shows a timing diagram without the problems associated with fig. 5. In the timing diagram 550 of fig. 6, the slave device sends an ARP request 552 and receives a corresponding ARP response in step 554. At this point, the ARP cache timer and the network route timer are reset in steps 556 and 558, respectively. However, unlike the embodiment of FIG. 5, in FIG. 6, the ARP cache expires before the network routes. Specifically, at step 562, the ARP cache expires. This means that the ARP request is issued at step 564 and the corresponding response received at step 566 resets the network routing timer before the network route expires. Thus, when the network routing timer does not expire before the ARP timer expires, all packets are delivered. In the embodiment of fig. 6, the ARP cache timer is reset at step 568 and the network route will expire at 560. In this case, however, the network routing clock is reset at step 560 because the ARP cache has not expired.

In the above, ARP requests, ARP responses, ARP cache timeouts, and network route timeouts are all examples of events. These events may involve dependent parameters (co-dependent parameters). The analysis described herein allows the monitoring device 150 to detect when such dependent parameters are not configured correctly, as shown in FIG. 5, and allows the administrator to change the dependent parameters to configure correctly, as shown in FIG. 6. In this example, the dependent parameters are ARP cache timeouts and network route timeouts, but it should be understood that the present disclosure is applicable to any two or more such dependent parameter sets.

Fig. 7 shows a flow diagram illustrating the monitoring of the broadcast communication stream by the monitoring device 150. Many "AV over IP" devices broadcast control data, and it is therefore desirable to monitor or prevent non-AV over IP "devices from sending too much broadcast data over the network, as this may prevent or delay the control data broadcast by the" AV over IP "devices from reaching their destination. Process 700 begins at step 705. The process proceeds to step 710 where the monitoring device 150 receives a broadcast communication stream (e.g., an ARP communication stream or other control data). A source of the received broadcast communication stream is established. This is accomplished by analyzing the received broadcast IP packet and occurs in step 715.

In the event that the source of the broadcast communication stream is not one of converter 1120, converter 2121, converter 3122, and converter 4123, the process proceeds to step 735 and ends. In other words, if the broadcast data source is not an "AV over IP" device, the process proceeds to step 740. At step 740, the amount of non "AV over IP" traffic or data volume is determined. In step 740, the amount of data is recorded along with a timestamp. The process proceeds to step 745 where a comparison is performed to determine if the amount of data recorded compares to an acceptable amount or data amount. In case the recorded data amount exceeds the acceptable data amount, a warning is issued in step 750. The warning may be an audible or visual warning. Alternatively, if the amount of data recorded is within acceptable limits, the process proceeds to step 735 and ends.

In the case where the broadcast communication stream is an "AV over IP" broadcast communication stream, the latency of the broadcast communication stream is determined in step 720. The delay of broadcasting the IP packet may be determined by analyzing the difference between the time of the packet sent out by the source device and the time of the packet received by the monitoring device 150. This indicates the latency of the SDN controller 105. In an embodiment, the broadcast packets may be time stamped, which enables accurate measurement of the processing delay of SDN controller 105.

In other embodiments, the timestamp of a packet received in the SDN controller 105 and the time the packet was sent by the switch 115 may be able to determine the amount of data of the communication flow sent via the SDN controller 105 and compare it to the available bandwidth of the network link between the switch 115 and the SDN controller 105 to estimate whether the broadcast communication flow is bottleneck impeded. The latency can also be determined in this way, especially if these timestamps are supported by hardware.

In other embodiments, the latency may be determined by measuring a timestamp when the broadcast packet is received at the switch 115 and a timestamp when a copy is transmitted from the switch 115.

The process proceeds to step 725 where the delay is compared to an acceptable delay defined when the network is configured or taken from a snapshot of when the network is operating well 725. In general, whether the latency period is acceptable will depend on the type of device connected to the network and the type of broadcast communication stream sent over the network. In the case where a network is connected to many devices, where control data for these devices is broadcast over the network, low latency is required. Therefore, it is expected to reduce the amount of non-control broadcast data transmitted through the network.

If the latency is too large, the "too large" path is followed to step 730 where a warning is provided to the user indicating the latency, the type of broadcast data, and the source of such broadcast data. The warning may be visual or audible. Processing ends at step 735.

Alternatively, if the latency is acceptable, the "acceptable delay" path is followed to step 735, where the process ends.

In other embodiments, the broadcast latency may be measured in step 720 as described above, and the latency measurement may then be provided to a user or administrator, after which the process may end.

Although the embodiment of fig. 7 describes identifying delays in broadcast communication streams, the disclosure is not so limited. For example, in embodiments, similar processing may be followed for unicast traffic flows, control packets, or any other relevant packet classes. This is because in a network with a large percentage of the media content streams around it is usually assumed that the broadcast traffic, unicast traffic or any other control traffic should be small compared to the AV traffic and the network capacity.

Fig. 8 shows a flowchart illustrating a mechanism for identifying whether a converter or an AV device connected thereto operates incorrectly. Process 800 begins at step 805. The process then proceeds to step 810 where the bandwidth of the media content communication stream from one converter is analyzed. In an embodiment, bandwidth is one example of a parameter of media content. In the embodiment of fig. 8, the media content communication stream is a video stream. However, the present disclosure is not so limited and the media content communication stream may comprise an audio communication stream, or an audio and video communication stream.

The bandwidth of the media content is compared to expected data from the data structure of fig. 2. This is step 815. The expected data is one example of a parameter associated with the device. This is because the expected data depends on the frame rate of the device, the content expected at the device, and the resolution of the device and the content expected at the device.

The process proceeds to step 820 where it is determined whether the bandwidths are different. In the event that there is no difference in bandwidth (or only a difference less than a predetermined amount), the no path is followed to step 835 where the process ends.

Alternatively, if the bandwidths are different (or differ by more than a predetermined amount), the yes path is followed to step 825. In this case, the resolution of the media content (e.g., video content in a video stream) is compared to the video resolution expected by the device. This expected information is obtained from the data structure of fig. 2. The video resolution of the video stream may be determined based on the average bandwidth of the video stream over a period of time. A warning may be issued to the user indicating that bandwidth is not expected and that the video resolution of the video stream is as expected or different from that expected. Alerts are one example of events when there is a negative comparison between a parameter of content and a parameter of a device. The warning may be visual or audible.

This is useful because providing this information will help the user identify the likely cause of any device problems. For example, in the case where bandwidth is not expected and the video resolution of the media content is different from what is expected, this means that the resolution of the device has changed or the converter is not operating correctly. However, different bandwidths and resolutions of video are desirable, indicating different problems with the device or converter. The process then ends at step 835.

In an embodiment, this may also identify a situation where the resolution of the video stream has degraded without issuing a warning. For example, without obvious reasons, a 4K source sent to a 4K display may be degraded to High Definition (HD) resolution. The mechanism recognizes this particular situation and alerts the administrator accordingly.

In an embodiment, the monitoring device 150 may perform flow statistics and port statistics to identify the most active traffic flow and the most active port. These may be compared to expected flow and port statistics and in the case where there are more active traffic flows or ports than expected, a flag may be raised.

In an embodiment, the monitoring device 150 will determine the entire bandwidth used by the network. This will be compared to the maximum bandwidth of the network determined during the initial configuration of the network and stored in memory 155. In the event that the bandwidth used by the network is within a predetermined amount of the maximum bandwidth, a warning is issued to the user. The maximum bandwidth may be the theoretical maximum bandwidth or may be the maximum bandwidth acceptable to avoid a network crash.

In an embodiment, one or more converters may dynamically change the bit rate of the media content stream to match the available bandwidth. In particular, in embodiments, a change in bandwidth may be signaled without a corresponding change in video parameters, such as video resolution of the frame rate. In this case, the monitoring device 150 may flag such a change in bit rate as an event and/or issue a warning or alarm.

In an embodiment, Internet Group Management Protocol (IGMP) traffic is analyzed by the monitoring device 150. The processing described with reference to fig. 4A-6 may be used to reduce the impact of different IGMP timeouts on different devices. In other words, the processing described with reference to ARP traffic can be applied to IGMP traffic as well.

In an embodiment, the monitoring device 150 may include a display showing all devices and showing the video resolution and format used on each device. The display may list only the video resolution and format used on the network. In a further embodiment, the status of the video connection between the converter and the device may be displayed on a display. The display may also identify any video connections that are not running or have no negotiated format (in the case of video connections that support negotiation of a format such as HDMI). In an embodiment, the chart of fig. 6 may be adapted to show events, such as a change in the negotiated format of a video connection. Furthermore, any issues with video connection content protection can be displayed. For example, any errors caused by High Bandwidth Digital Content Protection (High Bandwidth Digital Content Protection) over an HDMI connection should be displayed. This allows the user to easily see and correct problems with the device or transducer.

In an embodiment, the monitoring device 150 will show any failures within the network in compliance with the networking standard on the display. For example, in case the device continuously performs ARP timeout, this will be displayed on the display.

In an embodiment, the detection of the transducer by the monitoring device 150 may reach the socket level. The result of this detection may also be displayed on a display.

In an embodiment, the monitoring device 150 will identify any device that has an Electronic Device ID (EDID) enabled. This is useful because in a network that provides media content via multicast, a converter can negotiate a particular video format or resolution with a device and then apply that video format or resolution to all devices to which the converter multicasts the content. The video format and/or resolution may not be applicable to all devices to which multicast is being performed. Alternatively, if the other devices are capable of receiving video content in that format and/or resolution, the other devices each need to renegotiate with the source device. This extends the time before media content can be sent over the network and also results in a further negotiation by other devices that receive the stream resulting from the first re-negotiation. By identifying EDID-enabled devices, and if the media content is delayed while being transmitted over the network, the user can quickly see if the problem caused the delay.

In a multicast media content system where the same media content is provided to multiple devices that all support different frame rates and video resolutions, it may be appropriate to provide the media content to the same device at the same frame rate and video resolution, but it may not be appropriate to transmit the media content to different devices at the same frame rate or video resolution. In the example of fig. 1, media content sent to display 130 at a resolution of 1920 x 1080 may not be suitable for a much higher resolution (3840 x 2160) crystal light emitting diode. A video format common to both the converter and the management platform 110 needs to be negotiated. The negotiation may not take into account the different supported video resolutions and frame rates. Thus, according to embodiments of the present disclosure, the monitoring device 150 checks the selections made during this negotiation and will provide one or more alerts or suggestions to the user to help resolve any sub-optimal configurations.

Thus, fig. 9 shows a flow diagram 900 illustrating a video format conversion analysis to mitigate such a situation, according to an embodiment.

Process 900 begins at step 905. The process then proceeds to step 910 where the frame rate and/or resolution of the video, and/or the bit depth and/or chroma format and/or audio of the media content sent to each device, is checked at step 910. The frame rate and/or resolution and/or bit depth and/or chroma format of the media content of the source device is also checked. Frame rate and/or resolution and/or bit depth and/or chroma format of the media content are examples of parameters of the media content. The process proceeds to step 915 where the frame rate and/or resolution of the media content is compared to a frame rate and/or resolution supported by the device. In other words, the parameters of the media content are compared to the parameters of the device. The frame rate and/or resolution is stored in data structure 200. The process then proceeds to step 920 where an alert is issued if frame rate and/or resolution and/or bit depth and/or chroma format is not supported. In other words, the alert is an example of an event performed in the event of a negative comparison result. The warning may be a visual warning on the display of the monitoring device 150 or may be an audible warning. The process then ends at step 925. It should be noted herein that although the comparison is made between parameters of the media content and corresponding parameters of the device, the present disclosure is not so limited and the comparison may be made between the media content and any one or more of the device, a second device on the network, and the network.

Since the monitoring device 150 has a data structure 200 that identifies the technical characteristics of each device located on the network, the monitoring device 150 can establish the most common local resolution or local frame rate supported by each device to which the media content is being multicast. The monitoring device 150 may indicate the most common local resolution or local frame rate on the network in the alert so that the user may change the resolution (or frame rate) to the most common local resolution or frame rate. This reduces the number of transitions required to multicast the media content and thus improves the quality of the media content output from each device.

In an embodiment, a user or designer of the network may designate a device as a protected device. As shown in fig. 2, this information is stored in a data structure 200. The protected device is a device to which media content is provided at its local resolution and/or frame rate. In such a case, using the embodiment of fig. 9, the monitoring device 150 may issue an alert indicating that media content is being provided to any of the protected devices at a non-local resolution and/or frame rate. In an embodiment, a user or designer of network 100 may provide each device with a priority value that will weight the most common analysis of local resolution and/or frame rate. Thus, for example, if the device is a protected device, the media content must be provided to the device in its original resolution and/or video format. However, if the device is higher priority than another device, the likelihood of the higher priority device receiving the media content at its local resolution and/or frame rate is increased, but not necessarily. This is intended to mitigate situations where a large display, such as a crystal LED display, receives media content at the same resolution as a mobile phone on a network.

In one arrangement, for example, there may be a large crystal LED display located in the conference room, with smaller displays located to the side of the room and smaller displays located outside the conference room. In this case, the crystal LED display may have a high priority, while the display at the side of the room may have a lower priority than the crystal LED display, and the display located outside the conference room may have an even lower priority. This means that the user or designer of the network has the flexibility to ensure that media content is provided to each device in the most appropriate format for the device and for use by the device. In an embodiment, the protected devices and the priority of each device may be applied to the media content stream being sent over the network and alert the user that the 4K display will not receive the best resolution content due to the mobile phone.

In the event that a compromise is required, priority is utilized to select which display receives the local stream because all displays must receive the same multicast media content, such that one or more of the displays must perform a conversion of the video parameters.

The priority may also incorporate other characteristics such as available bandwidth, e.g. when multicast to a 4K display (highest priority) and HD display (medium priority) and mobile phone (low priority), but due to bandwidth limitations the mobile phone does not receive 4K, then HD is selected as it is the closest 4K resolution that the mobile phone can accept. Alternatively, the monitoring device 150 may instruct the SDN controller 105 to block the connection of the mobile phone, as this would have an adverse effect on the higher priority display.

In some networks provided with media content, the audio and video components of the media content may be routed to different devices. For example, in a home network, the video component may be routed to a display and the audio component may be routed to a separate speaker. However, in larger networks where many devices are present on the network, the audio component may be routed to a speaker in a completely different physical location than the display, or multiple audio streams may be routed to mix. To mitigate the impact of such situations, in embodiments, a user is notified or alerted when audio and/or video and/or metadata streams associated with media content are being routed to different locations. The database of fig. 2 may store information indicating whether audio and/or video and/or metadata streams associated with media content should be routed to different locations.

Fig. 10 shows a flow chart describing an embodiment of the present disclosure that mitigates this problem.

Process 1000 begins at step 1005. The process then proceeds to step 1010, where the destination of one or more of the audio, video, and/or metadata streams in the media content is determined by the monitoring device 150. The process then proceeds to step 1015 where a check is made to determine if the destinations are the same. In the case where the destination is the same, the yes path is followed to step 1016. In this case, a check is made to determine if the same destination is expected. Where the same destination is expected, the process follows the YES path to step 1025, where it ends. However, if the same destination is not expected, the no path is followed to step 1020, with a warning being issued to the user at step 1020. In a similar manner to the previous embodiments, the warning may be an audible and/or visual warning. Processing then ends at step 1025.

Returning to step 1015, if the destinations are different, the no path is followed to step 1018 where a check is made to determine if a different destination is expected. If a different destination is not expected, the no path is followed to step 1020 where an alert is issued. However, if a different destination is expected, then the yes path is followed to step 1025, where the process ends.

In the embodiment of fig. 10, the parameters are that the video component, the audio component, and the metadata component of the media content are all destined for the second device.

As described above, the monitoring device 150 may provide suggestions to the user to solve technical problems of devices on the network or the network itself. In the example of fig. 9, the suggestion includes defining an appropriate resolution and/or frame rate for the media content. Note that the present disclosure is not limited thereto. In other embodiments, the monitoring device 150 may enter an advisor mode. In this case, the monitoring device 150 may check the database (stored locally in the memory 155 or remotely on the network 100 or the internet) when an alert is issued to the user. The database will include a number of solutions to address the various problems identified by the monitoring device 150. These solutions may include graphical information that the user may follow to perform, or a video that the individual performs some remedial (e.g., scheduled) action, or may provide a written description of the solution. One such predetermined action is to apply the new configuration to one of the first device, the second device and the network.

In the above embodiments, the media content is analyzed over a network. In embodiments where the analysis involves plotting time series data (e.g., port traffic statistics), adaptive data smoothing is applied to the time series data. In this case, time series data is collected at a high sampling rate and placed into a time series database. This data is then processed using advanced or adaptive filters to smooth the rendered map. One such filter may be a sharp cut-off selective low-pass filter. This will be through a change in the average data rate over the time sequence, but will smooth out the higher frequency rate fluctuations. The output is displayed to a user of the monitoring device 150. This reduces the amount of noise displayed to the user from changes in fast-changing and volatile data.

In an embodiment, a snapshot of the network configuration may be captured when the network is operating correctly. These snapshots may include system configuration snapshots.

Additionally or alternatively, the snapshots may include measured parameters such as measured traffic load, measured latency, measured timeout, and the like. These parameters will be captured when the known system is operating correctly and then used as threshold parameters during subsequent operations to warn of potential problems.

In some embodiments, the current configuration may be compared to previously known good snapshots to identify any differences and where the differences are, and the system may be arranged to generate one or more suggested configuration adjustments to improve the current configuration.

Fig. 11a, 11b and 11c show diagrams that help a user visualize network operation. The graphs each include events generated by embodiments of the present disclosure, which are plotted on a timeline.

Fig. 11a shows an embodiment of the normal operation of the network. Obviously, the events of detecting an ARP request and detecting an ARP response are plotted. In this case, an ARP request mode occurs, and it is expected that an ARP reply is obtained after a short time. The time period between the ARP request and the corresponding ARP reply is expected to be shorter than the time period between the ARP reply and the subsequent ARP request.

Fig. 11b shows an embodiment of a graph in which the network latency of ARP is too large. In this case, two ARP requests will be detected before any ARP responses are received. Of course, it is understood that any number of ARP requests may be detected. In the event that multiple ARP requests are detected, multiple ARP responses are received. This indicates that the network latency of ARP is too large, resulting in multiple retries of ARP requests. The user will then be able to correct this or will obtain an instruction in which the procedure for correcting this is described.

Fig. 11c illustrates an embodiment of a graph in which a network route timeout occurs. In this case, an ARP request is detected and after a short time a corresponding ARP response is detected. However, in this case, a network route timeout event is detected before the next ARP request is detected. It is important to note that in the example of fig. 11c, two instances of this pattern are shown. This is because occasional network routing timeouts may occur in the case of low traffic flows. However, the pattern of network route timeouts (e.g., constant time period between timeouts) may indicate a problem similar to that of fig. 6.

Although a chart is described above that is displayed to the user, artificial intelligence can also be used to locate these patterns and identify problems and resolve corresponding solutions.

Although a timeline with a single event at each time is shown above, the present disclosure is not so limited. In an embodiment, two or more events may occur simultaneously (i.e., ARP data packets sent to two or more IP addresses, etc.). Further, events related to each other (e.g., ARP packets related to the same network address) may be connected by wires to illustrate the relationship. Furthermore, color coding may be used to aid visualization so that errors detected from patterns may be used to identify errors. Further, the user may apply a filter to show a simplified timeline that includes only certain events.

Fig. 12a and 12b illustrate alternative visualization techniques that may assist a user. In fig. 12a and 12b, time is not a coordinate axis, but shows the sequence of events. In the example of fig. 12a, all events are shown with lines connecting related events. Event summaries consistent with the events are provided alongside the chart so that the user can easily identify the events with the summaries. In the event of an error (in this case, a video format error), no line is set, and the color (and summary) of the event may be different. Fig. 12b shows the same embodiment as the embodiment of fig. 12 a. In the embodiment of fig. 12b, all events related to the event currently under the mouse cursor are highlighted by displaying the event labels in bold, displaying the event markers in a color indicating an error or non-error state, and displaying lines between the event markers to indicate the relationship between the events. Typically, these colors are different. In the case where events are not correlated, no line is used to connect the events. Events that are not related to events under the mouse cursor are not highlighted. It should be appreciated that when the user moves the mouse cursor over the area of the event viewer, a different event group will be highlighted. This enables the user to more easily identify complex errors caused by the interaction of multiple system events.

Many modifications and variations of the present disclosure are possible in light of the above teachings. It is, therefore, to be understood that within the scope of the appended claims, the disclosure may be practiced otherwise than as specifically described herein.

To the extent that embodiments of the present disclosure have been described as being implemented at least in part by software-controlled data processing apparatus, it should be understood that non-transitory machine-readable media, such as optical disks, magnetic disks, semiconductor memory, etc., carrying such software are also considered to represent embodiments of the present disclosure.

It will be appreciated that the above description for clarity has described embodiments with reference to different functional units, circuits and/or processors. It will be apparent, however, that any suitable distribution of functionality between different functional units, circuits and/or processors may be used without detracting from the embodiments.

The described embodiments may be implemented in any suitable form, including by hardware, software, firmware, or any combination thereof. The described embodiments may optionally be implemented at least partly as computer software running on one or more data processors and/or digital signal processors. The elements and components of any embodiment may be physically, functionally and logically implemented in any suitable way. Indeed the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units. As such, the disclosed embodiments may be implemented in a single unit or may be physically and functionally distributed between different units, circuits and/or processors.

Although the present disclosure has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. In addition, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in any manner suitable for implementation of the technology.

Embodiments of the present technology may be described generally by the following numbered items:

1. a method of monitoring a network having a first device and a second device, comprising:

receiving IP packets containing media content from the first device on the network, the IP packets being sent to the second device;

analyzing the received IP packets to determine parameters of the media content;

analyzing the parameter of the media content and a parameter associated with the second device, wherein, in the event that the parameter of the media content is different from the parameter associated with the second device, the method comprises:

comparing the parameters to attributes of a configuration of at least one of the network, the first device, and the second device; and

a predetermined action is performed.

2. The method of item 1, wherein the parameter of the media content is a frame rate and/or a resolution and/or a bit depth and/or a chroma format of the media content.

3. The method of item 1, wherein the parameter of the media content is a bandwidth of the media content.

4. The method of item 1, wherein the parameter is that the video component, audio component, and metadata component of the media content are all destined for the second device.

5. A method according to any preceding claim, wherein the predetermined action is providing a message to a user.

6. The method of clause 5, wherein the message is an alert or a recommendation.

7. The method of clauses 5 or 6, wherein the suggestion is a new configuration of at least one of the network, the first device, and the second device.

8. The method of any of claims 1 to 4, wherein the predetermined action is automatically applying a new configuration to at least one of the network, the first device and the second device.

9. A method of monitoring a network having a first device and a second device, comprising:

receiving an IP packet containing control data transmitted over the network;

analyzing the received IP packet to determine a source of the IP packet; and

in the case where the source of the IP packet is not a media device, the method comprises:

determining a time delay of the IP packet; and in the case that the latency is above a threshold latency, the method comprises:

a warning is provided to the user.

10. The method of item 9, wherein the alert is a visual alert.

11. A method of monitoring a network having a first device and a second device, comprising:

receiving a control packet transmitted from the first apparatus to the second apparatus;

receiving a response to the control packet sent from the second apparatus to the first apparatus; and

in the event that the control packet is not received from the first apparatus or the response is not received from the second apparatus within a predetermined period of time, the method comprises:

measuring a characteristic of the control packet from the first apparatus and the control packet from the second apparatus;

comparing these characteristics to characteristics of a configuration of at least one of the network, the first device, and the second device; and

a predetermined event is performed.

12. The method of item 11, wherein the characteristic of the control packet is a time at which the control packet is transmitted and/or received.

13. The method of clause 11 or 12, wherein the nonce packet is an ARP packet or an IGMP packet.

14. The method of item 13, wherein the known parameter of the system is a timeout event/period.

15. A computer program product comprising computer readable instructions which, when loaded onto a computer, configure the computer to perform a method according to any preceding claim.

16. An apparatus for monitoring a network having a first apparatus and a second apparatus, comprising:

a circuit configured to:

receiving an IP packet containing media content from the first device on the network, the IP packet being sent to the second device;

analyzing the received IP packets to determine parameters of the media content;

analyzing the parameters of the media content and parameters associated with the second device;

wherein, in an instance in which the parameter of the media content is different from the parameter associated with the second apparatus, the circuitry is configured to:

comparing these parameters with properties of a configuration of at least one of the network, the first device and the second device, and

a predetermined action is performed.

17. The apparatus of item 16, wherein the parameter of the media content is a frame rate and/or a resolution and/or a bit depth and/or a chroma format of the media content.

18. The apparatus of item 16, wherein the parameter of the media content is a bandwidth of the media content.

19. The apparatus of item 16, wherein the parameter is that the video component, audio component, and metadata component of the media content are all destined for the second apparatus.

20. The apparatus of any of claims 16 to 19, wherein the predetermined action is providing a message to a user.

21. The apparatus of item 20, wherein the message is an alert or a suggestion.

22. The apparatus of claim 20 or 21, wherein the suggestion is a new configuration of at least one of the network, the first apparatus and the second apparatus.

23. The apparatus of any of claims 16 to 19, wherein the predetermined action is automatically applying a new configuration to at least one of the network, the first apparatus and the second apparatus.

24. An apparatus for monitoring a network having a first apparatus and a second apparatus, comprising:

a circuit configured to:

receiving an IP packet containing control data transmitted over the network;

analyzing the received IP packet to determine a source of the IP packet; and

in the case where the source of the IP packet is not a media device, the method comprises:

determining a time delay of the IP packet; and in the event that the time delay is above a threshold time delay, the circuitry is configured to:

a warning is provided to the user.

25. The apparatus of item 24, wherein the warning is a visual warning.

26. An apparatus for monitoring a network having a first apparatus and a second apparatus, comprising:

a circuit configured to:

receiving a control packet transmitted from the first apparatus to the second apparatus;

receiving a response to the control packet sent from the second apparatus to the first apparatus; and

in the event that the control packet is not received from the first apparatus or a response is not received from the second apparatus within a predetermined period of time, the circuitry is configured to:

measuring a characteristic of the control packet from the first apparatus and the control packet from the second apparatus;

comparing these characteristics to known characteristics of a configuration of at least one of the network, the first device, and the second device; and

a predetermined event is performed.

27. The apparatus of item 26, wherein the characteristic of the control packet is a time at which the control packet is transmitted and/or received.

28. The apparatus of item 26, wherein the control packet is an ARP packet or an IGMP packet.

29. The apparatus of item 28, wherein the known parameter of the system is a timeout event/period.