Patent Description:
Conventionally, a program production system that transmits video, audio, and synchronization information has been configured according to a signal transmission method using SDI (for example, see Non-Patent Literature <NUM>) or MADI (for example, see Non-Patent Literature <NUM>) developed for program production. A typical example of a program production system in the SDI and MADI signal format can be configured as illustrated in <FIG>, for example. A video transmitting device <NUM> that transmits the video of a photographing camera or the like transmits the video to an SDI router <NUM> as an SDI-format signal (SDI signal), and distributes and transmits the video from the SDI router <NUM> to a designated receiving device <NUM> such as a receiver. Further, an audio transmitting device <NUM> that transmits audio of a microphone or the like transmits the audio to the SDI router <NUM> via an audio router <NUM> as a MADI-format signal (MADI signal), and distributes and transmits the audio from the SDI router <NUM> to a designated receiving device <NUM>. The video transmitting device <NUM>, the audio transmitting device <NUM>, the SDI router <NUM>, the audio router <NUM>, and the receiving device <NUM> can be synchronized by a synchronization signal from a synchronization signal generator <NUM>.

On the other hand, in recent years, it has been studied to construct a program production system for storing video, audio, and synchronization information in Ethernet (registered trademark) frames (hereinafter, also referred to as "E-frames" in the present specification) and IP packets (in the present specification, E-frames and IP packets are collectively referred to as "packets") and transmitting the same (see, for example, Non-Patent Literature <NUM>). A typical example of a program production system constructed by an E-frame or IP packet network can be configured as illustrated in <FIG>, for example. A video transmitting device <NUM> that transmits the video of a photographing camera or the like stores the video in an E-frame or an IP packet, transmits the packet to a certain network switch <NUM>, and transmits the packet from the network switch <NUM> via another network switch <NUM> or directly to a designated receiving device <NUM> such as a receiver on the basis of the header information in the packet. Further, an audio transmitting device <NUM> that transmits audio of a microphone or the like stores the audio in an E-frame or an IP packet, transmits the packet to a certain network switch <NUM>, and transmits the packet from the network switch <NUM> via another network switch <NUM> or directly to a designated receiving device <NUM> on the basis of the header information in the packet.

One network switch <NUM> is connected to another network switch <NUM> and transmitting devices such as the video transmitting device <NUM> and the audio transmitting device <NUM> by a communication cable such as a LAN (Local Area Network) cable and has input ports for receiving packets from the other network switch <NUM> and a plurality of these transmitting devices. Further, one network switch <NUM> is connected to another network switch <NUM> and one or a plurality of receiving devices <NUM> by a communication cable, and has output ports for relaying and outputting packets transmitted to the other network switch <NUM> and one or a plurality of receiving devices <NUM>.

In a program production system constructed by an E-frame or IP packet network, network switches <NUM> are synchronized by a synchronization signal from a synchronization signal generator <NUM> so as to be able to cope with a case where video, audio, and synchronization information are transmitted in real-time. Although not illustrated, the synchronization signal is also transmitted to the video transmitting device <NUM> and the receiving device <NUM> via the network switch <NUM> so that all devices are synchronized.

In a program production system constructed by an E-frame or IP packet network, since the network switch <NUM> and the devices can be configured at a relatively low cost, and the transmission capacity of the network can be increased, it is expected to reduce equipment costs. In addition, since a general-purpose PC (Personal Computer) server can be configured to receive and process data via the network, it is expected to support communication service such as on-demand and realize advanced processing such as monitoring the flow of packets (packet flow) on the program production system.

As a technique of monitoring a packet flow on a general communication system, a monitoring server capable of acquiring quality information such as the number of output packets, the number of packets output or discarded from a network switch arranged in an IP network and the average bit rate at intervals of several minutes may be provided in each interface of the network switch arranged in the IP network. Further, as a technique of monitoring a packet flow on a general communication system, a monitoring system called sFlow is known (see, for example, Non-Patent Literature <NUM>). In sFlow, the amount of traffic in each packet flow can be estimated by sampling packets processed in the switch, inspecting the content of only some packets, and statistically processing the result.

A network switch in a general communication system usually has a function of replicating a packet to be transmitted. Therefore, in a general communication system, as illustrated in <FIG>, a dedicated analysis device that extracts the replicated packet from each network switch (the same reference numeral is assigned since the network switch <NUM> in the program production system illustrated in <FIG> can be similarly configured) and analyzing the packet flow may be provided. For example, a configuration may be adopted in which packets replicated in a plurality of network switches <NUM> are transmitted to the analysis device <NUM>, and the packets are analyzed so as to monitor each packet flow. In the case of collecting and analyzing replicated packets using such a packet replication function in the network switch, a plurality of communication cables connected to each of the replicate data transmission ports as many as the number of ports used for data transmission are used.

In general, the SMPTE ST <NUM>-<NUM> standard is defined when storing video signal data in packets and transmitting the same on an IP network (see, for example, Non-Patent Literature <NUM>), and the SMPTE ST <NUM>-<NUM> standard is defined when storing audio signal data in packets and transmitting the same on an IP network (see, for example, Non-Patent Literature <NUM>). Further, the SMPTE ST <NUM>-<NUM> standard is defined when storing video and audio information in packets and transmitting the same (see, for example, Non-Patent Literature <NUM>). As a representative example, <FIG> illustrates the signal format of the SMPTE ST <NUM>-<NUM> standard, and <FIG> illustrates the signal format of the SMPTE ST <NUM>-<NUM> standard, both of which are defined such that the designated header information and the payload that stores data are arranged in a designated number of bits.

Non-Patent Literature <NUM>) discloses that "Consequently, a new opportunity opens for flexible monitoring of specific network flows. NetAlytics allows a system administrator to specify a simple query defining types of traffic to monitor and data to gather, as well as how that data should be analyzed. The query is transformed into a set of SDN rules that direct the desired traffic to dynamically instantiated NFV monitors that efficiently extract the target data. This data is then aggregated and sent through a highly scalable streaming analytics engine, allowing system administrators to quickly get back meaningful insights about their networks and the applications running within them. " on page <NUM>, lines <NUM>-<NUM>; "ProtocolLib: implements common functions to work with Ethernet, IP, TCP and UDP headers, in addition to payload data. As a result, new parsers can be written with minimal code. For example, our HTTP GET parser requires only <NUM> lines of application-specific code. " on page <NUM>, paragraph ProtocolLib; <FIG>).

Patent Literature <NUM>) discloses an input control means 1a controls input of packets received by a communication device <NUM>. A temporary storage means 1b temporarily stores the received packets. An output control means 1c controls output of the received packets. A mirror output control means 1d controls output of mirror packets based upon the received packets. The input control means 1a performs control to write the received packets to the temporary storage means 1b. The mirror output control means 1d performs control to extract only some of the packets written to the temporary storage means 1b and to output mirror packets having some of the extracted packets.

When a failure occurs in a certain video signal during the operation of a program production system, it is necessary to perform quality measurement to confirm the state of the video signal. In a program production system of the SDI and MADI signal format, it is clear through which cable the video signal is transmitted, and a technique of measuring the quality of the video signal is established.

On the other hand, in a program production system constructed by an E-frame or IP packet network, packets are multiplexed by a network switch in the network, and the packet transmission path is autonomously determined by each network switch. Therefore, it is difficult to know through which LAN cable, the quality measurement target video signal is flowing, and it is also necessary to separate the video signal from other video signals and audio signals.

For example, as described above, as a technique of monitoring a packet flow on a general communication system, a monitoring server capable of acquiring quality information such as the number of output packets, the number of discarded packets, and the average bit rate at intervals of several minutes may be provided in each interface of the network switch arranged in an IP network. However, even if such a monitoring server is applied to the program production system illustrated in <FIG>, the value indicating the quality information acquired by the monitoring server is the total value of all packets in which packets storing the video signal and the audio signal are multiplexed, and there is a problem that it is impossible to know the quality of the measurement target video signal.

Further, on the basis of the sFlow technique disclosed in Non-Patent Literature <NUM>, the amount of traffic for each IP flow may be estimated by sampling the packets processed in the network switch to inspect the content of only some packets and statistically processing the inspection result. However, since sFlow does not measure all packets processed in the network switch, there is a problem that it is impossible to grasp the accurate amount of traffic and detect packet loss. In particular, in broadcast program production sites, since packet loss is directly linked to video deterioration, accurate monitoring that does not overlook even one payload or jitter such as checking all packets in real-time to detect packet loss and measuring jitter is required, and a more accurate monitoring technique than the packet flow monitoring performed in the conventional computer system is required. Therefore, even if sFlow is applied to the program production system, it is impossible to detect packet loss and measure jitter, which makes quality control difficult. In addition, monitoring all packets on the network switch increases the load as the speed of the network increases, which may adversely affect the original processing of the network switch.

Further, as described above, when the communication packet flow monitoring device <NUM> as illustrated in <FIG> is configured using the packet replication function in the network switch, a plurality of communication cables to be connected to the replication data transmission ports as many as the number of ports used for data transmission is required. That is, in this form, since all packets processed by the network switch are monitored, a number of ports the same as normal data transmission are required, which is not practical.

In view of the above problems, an object of the present invention is to provide a packet flow monitoring device, a packet data extraction device, an extraction data aggregation device, and a program for efficiently and highly accurately monitoring packet flow in a video or audio computer system constructed by an Ethernet (registered trademark) frame or IP packet network.

A packet flow monitoring device of the present invention is a packet flow monitoring device that monitors packet flow in a video or audio communication system constructed by an Ethernet (registered trademark) or IP (Internet Protocol) packet network, including: a packet data extraction device that replicates all passing packets that pass through one or a plurality of specific network switches on the network and extracts and aggregates some predetermined pieces of information in the replicated passing packets to form and output an extraction data report packet; and an extraction data aggregation device that receives the extraction data report packet, analyzes the extraction data report packet so as to aggregate the some predetermined pieces of information in the replicated passing packets included in the extraction data report packet for each packet flow, and records the aggregated information as aggregation data.

In the packet flow monitoring device of the present invention, the packet data extraction device and the extraction data aggregation device are connected by a communication cable using a single port.

In the packet flow monitoring device of the present invention, the extraction data report packet is composed of IP-format packets having a variable length within a range not exceeding a predetermined packet length, an IP header and a UDP header for performing transmission between the packet data extraction device and the extraction data aggregation device, an extraction data common header composed of items common to the aggregated, replicated passing packets, and packet-based extraction data composed of items individually extracted for the replicated passing packets are assigned to the extraction data report packet, and the packet-based extraction data is configured such that an extraction data individual header indicating information for identifying the extracted, replicated passing packets and extraction data that stores the some predetermined pieces of information in the extracted, replicated passing packets are paired with each other.

In the packet flow monitoring device of the present invention, the extraction data common header includes a value indicating a reception time of beginning data of the replicated passing packet in each packet flow, the extraction data individual header includes a passing packet length indicating a length of the replicated passing packet, a data type indicating a packet type of the replicated passing packet, and elapsed time information indicating a temporal difference from the beginning data described in the extraction data common header, and the packet type includes a value that identifies at least Ethernet (registered trademark), IP, and RTP (Real-time Transport Protocol).

In the packet flow monitoring device of the present invention, the packet type further includes a value that identifies IGMP (Internet Group Management Protocol), TCP (Transmission Control Protocol), UDP (User Datagram Protocol), and PTP (Precision Time Protocol).

In the packet flow monitoring device of the present invention, the pieces of information extracted by the packet data extraction device includes: extraction data for Ethernet (registered trademark) including a destination MAC address, a source MAC address, and a type number of an E-frame header, extraction data for IP network including a destination MAC address, a source MAC address, a source IP address, a destination IP address, and a protocol number of an IP header, extraction data for IGMP including a destination MAC address, a source MAC address, a source IP address, a destination IP address, a difference between a passing packet length and an IGMP payload length, and a predetermined amount of an IGMP payload from the beginning, extraction data for TCP or UDP including a destination MAC address, a source MAC address, a source IP address, a destination IP address, a source L4-port number, and a destination L4-port number, extraction data for PTP including a destination MAC address, a source MAC address, a source IP address, a destination IP address, a source L4-port number, a destination L4-port number, a difference between a passing packet length and a PTP header and payload length, and an entire part of a PTP header and PTP payload, and extraction data for RTP including a destination MAC address, a source MAC address, a source IP address, a destination IP address, a source L4-port number, a destination L4-port number, a difference between a passing packet length and a RTP payload length, a marker bit of an RTP header, a payload type of an RTP header, an RTP sequence number, an RTP timestamp value, and an SSRC that is an identifier indicating a source.

In the packet flow monitoring device of the present invention, the extraction data aggregation device analyzes the extraction data common header and the packet-based extraction data in each of the replicated passing packets in the extraction data report packet received sequentially to generate aggregation data for each packet flow according to a packet type, the aggregation data including: aggregation data for Ethernet (registered trademark) including a source MAC address, a destination MAC address, an E-frame type number, an average throughput, and a total number of received packets for each packet flow; aggregation data for IP including a source MAC address, a destination MAC address, a source IP address, a destination IP address, an IP header protocol number, an average throughput, and a total number of received packets for each packet flow; aggregation data for IGMP including a source MAC address, a destination MAC address, a source IP address, a destination IP address, an average throughput, a total number of received packets, a reception time, and a predetermined byte of IGMP payload from the beginning for each packet flow; aggregation data for TCP or UDP including a source MAC address, a destination MAC address, a source IP address, a destination IP address, a source L4-port number, a destination L4-port number, an average throughput, and a total number of received packets for each packet flow; aggregation data for PTP including a source MAC address, a destination MAC address, a source IP address, a destination IP address, a source L4-port number, a destination L4-port number, an average throughput, a total number of received packets, a transmission delay, a reception time, and an entire part of PTP header and payload for each packet flow; and aggregation data for RTP including a source MAC address, a destination MAC address, a source IP address, a destination IP address, a source L4-port number, a destination L4-port number, an average throughput, a total number of received packets, an RTP payload type number, an RTP SSRC, the number of packets with an RTP marker bit value of <NUM>, a packet reception interval, the number of packet losses, and a maximum number of burst losses for each packet flow.

In the packet flow monitoring device of the present invention, the packet data extraction device includes an RTP data extraction unit that determines whether a marker bit in an RTP header is <NUM> when extracting the pieces of information from the replicated passing packet related to RTP, and extracts the pieces of information so as to include <NUM> bytes of an RTP payload from the beginning when the marker bit is <NUM>, the extraction data aggregation device includes: an RTP payload determination unit that determines whether each of the replicated passing packets related to RTP complies with an SMPTE protocol of ST <NUM>-<NUM>, ST <NUM>-<NUM>, or ST <NUM>-<NUM> from the <NUM> bytes of the RTP payload from the beginning on the basis of predetermined determination information when aggregating, for each packet flow, the pieces of information in each of the replicated passing packets related to RTP included in the extraction data report packet; and a processing unit that acquires predetermined information characterized in ST <NUM>-<NUM>, ST <NUM>-<NUM>, or ST <NUM>-<NUM> from the <NUM> bytes of the payload from the beginning and adds the predetermined information to the aggregation data when the replicated passing packet complies with ST <NUM>-<NUM>, ST <NUM>-<NUM>, or ST <NUM>-<NUM> and the marker bit is <NUM>.

In the packet flow monitoring device of the present invention, the packet data extraction device includes: an extraction data compression unit that compresses extraction data to be stored in the same extraction data report packet received in the same packet flow when extracting the pieces of information from the replicated passing packet to create extraction data; and an extraction data report packet transmitting unit that inserts the compressed data, a data compression presence/absence flag indicating presence/absence of data compression, and a data compression position flag indicating a data position of data compression to generate and output the extraction data report packet, and the extraction data aggregation device includes an extraction data restoration unit that restores the compressed data by referring to the data compression presence/absence flag and the data compression position flag.

Further, a packet data extraction device of the present invention is a packet data extraction device used for monitoring packet flow in a video or audio communication system constructed by an Ethernet (registered trademark) or IP packet network, wherein the packet data extraction device replicates all passing packets passing through one or a plurality of specific network switches on the network, extracts and aggregates some predetermined pieces of information in the replicated passing packets to form an extraction data report packet, and outputs the extraction data report packet to external devices.

Further, an extraction data aggregation device of the present invention is an extraction data aggregation device which receives the extraction data report packet from the packet data extraction device of the present invention to analyze the pieces of information in the replicated passing packets included in the extraction data report packet so as to be aggregated for each packet flow, and records the aggregated information as aggregation data.

Further, a program of the present invention is configured as a program for causing a computer to function as the packet data extraction device in the packet flow monitoring device of the present invention.

Further, a program of the present invention is configured as a program for causing a computer to function as the extraction data aggregation device in the packet flow monitoring device of the present invention.

According to the present invention, it is possible to efficiently and highly accurately monitor packet flow in a video or audio communication system constructed by an Ethernet (registered trademark) frame or IP packet network. Preferably, it is possible to efficiently and highly accurately monitor and measure the quality related to the packet flow in a program production system for transmitting video and the like.

In particular, according to an aspect of the present invention, some predetermined pieces of information (including some pieces of information in the packet header, a part of the payload if the packet type is IGMP, and an entire part of the payload if the packet type is PTP) in the passing packet passing through an E-frame or IP packet network are extracted and aggregated to form the extraction data report packet. Therefore, it is possible to monitor and measure the quality of all packets even for information on traffic flowing through a high-throughput network (for example, signal transmission related to a <NUM>/<NUM> video system as a packet flow with a high transmission rate).

Further, according to an aspect of the present invention, when the some predetermined pieces of information in the passing packet are extracted, the packet type of the passing packet is determined, and the necessary information can be extracted according to the packet type. Therefore, it is possible to monitor detailed information such as throughput and a packet loss for each packet flow in real-time.

According to an aspect of the present invention, since the information extracted to be embedded in the extraction data report packet is compressed, it is possible to monitor and measure the quality related to more packet flows using one packet flow monitoring device.

Hereinafter, a packet flow monitoring device <NUM> of each embodiment according to the present invention will be described in detail with reference to the drawings.

<FIG> is a block diagram illustrating a schematic configuration of the packet flow monitoring device <NUM> according to the first embodiment of the present invention. The packet flow monitoring device <NUM> is a device for monitoring the quality related to packet flow of all passing packets passing through one or a plurality of specific network switches <NUM> on an E-frame or IP packet network illustrated in <FIG> in a program production system constructed by the E-frame or IP packet network to measure predetermined quality information to be described later. The packet flow monitoring device <NUM> includes a packet data extraction device <NUM> and an extraction data aggregation device <NUM>.

The packet data extraction device <NUM> illustrated in <FIG> is a device arranged between a plurality of specific network switches <NUM> illustrated in <FIG>, for example, to replicate passing packets passing between the plurality of network switches <NUM>, and replicates each packet, extract and aggregate some predetermined pieces of information (including some pieces of information in the packet header, a part of the payload if the packet type is IGMP, and an entire part of the payload if the packet type is PTP) in the replicated passing packets to form "extraction data report packet", and transmit the extraction data report packet to the extraction data aggregation device <NUM>. However, the packet data extraction device <NUM> may be mounted like a bridge device between a transmitting device such as the video transmission device <NUM> and the audio transmission device <NUM> illustrated in <FIG> and the network switch <NUM> or between the network switch <NUM> and the receiving device <NUM> and may be mounted in a specific network switch <NUM>.

The extraction data aggregation device <NUM> is a device that receives the "extraction data report packet" from the packet data extraction device <NUM>, and analyzes the "extraction data report packet" so as to aggregate the pieces of information in the replicated passing packets included in the "extraction data report packet" for each packet flow, and collectively records the aggregated information in a predetermined recording unit (an aggregation data recording unit <NUM> illustrated in <FIG>) as aggregation data. The extraction data aggregation device <NUM> is configured to be able to output the aggregation data to external devices so that it is possible to monitor the quality related to each packet flow and measure predetermined quality information to be described later.

The packet data extraction device <NUM> and the extraction data aggregation device <NUM> are connected by a communication cable such as a LAN cable using a single port, facilitating the installation thereof. Further, when the pieces of information in the passing packets of each packet flow are extracted by the packet data extraction device <NUM>, since the information is aggregated into the "extraction data report packet", even when a single communication cable is used, it is possible to handle the pieces of information in the passing packets of a number of packet flows and efficiently transmit the same to the extraction data aggregation device <NUM>.

As illustrated in <FIG>, the "extraction data report packet" is composed of IP-format packets having a variable length within a range not exceeding a predetermined packet length. Specifically, an IP header and a UDP header for performing transmission between the packet data extraction device <NUM> and the extraction data aggregation device <NUM>, an "extraction data common header" (see <FIG>) composed of items common to the aggregated, replicated passing packets, and "packet-based extraction data" composed of items individually extracted for the replicated passing packets are assigned to the "extraction data report packet". Each piece of "packet-based extraction data" is configured such that an "extraction data individual header" (see <FIG>) indicating information for identifying the extracted, replicated passing packet and "extraction data" that stores some predetermined pieces of information (see <FIG>) in the extracted, replicated passing packet are paired with each other.

As illustrated in <FIG>, a "device ID" for identifying the installed packet data extraction device <NUM>, a "timestamp value (seconds) synchronized with PTP during reception of beginning data" indicating the reception time of beginning data of the replicated passing packet in each packet flow, and a "timestamp value (nanoseconds) synchronized with PTP during reception of beginning data" are assigned to the "extraction data common header".

On the other hand, as illustrated in <FIG>, since the "extraction data individual header" only needs to indicate the relative relationship with the "extraction data common header", the amount of information for identifying the extracted passing packet is minimized. Following a reserve bit R (<NUM> bit), a "passing packet length" indicating the length of the replicated passing packet, a data type" indicating the packet type (a value for identifying E-frame/IP/IGMP/TCP/UDP/PTP/RTP) of the replicated passing packet, and a "reception port ID" for identifying each packet flow connected by ports are assigned. Furthermore, following the reserve bit R (<NUM> bit), an "elapsed time (nanoseconds) until the timestamp value of received PTP of beginning data from the timestamp value synchronized with PTP during reception of beginning data" indicating a temporal difference from the beginning data described in the "extraction data common header" in relation to the reception time of the passing packet extracted in the packet flow is assigned.

<FIG> is a block diagram illustrating a schematic configuration of the packet data extraction device <NUM> in the packet flow monitoring device <NUM> of the first embodiment according to the present invention.

The packet data extraction device <NUM> includes a number of packet replication units <NUM>, a number of data extraction units <NUM> and a number of switch processing units <NUM> corresponding to the number of extraction target ports, an extraction data transmitting unit <NUM>, and a PTP processing unit <NUM>.

The packet replication unit <NUM> temporarily stores the "reception time (timestamp value of the received PTP)" of the received passing packet in the extraction target packet flow, transmits the passing packet to the switch processing unit <NUM> and replicates the same, and outputs the replicated passing packet and the reception time information to the data extraction unit <NUM>.

The data extraction unit <NUM> extracts the information of the "extraction data common header" and "packet-based extraction data" illustrated in <FIG> and <FIG> from the header information of the replicated passing packet obtained from the packet replication unit <NUM> and the reception time information and outputs the same to the extraction data transmitting unit <NUM>.

The switch processing unit <NUM> outputs the original passing packet transmitted from the packet replication unit <NUM> along the path of the data flow. As a result, the normal processing of the network switch <NUM> is maintained.

Although <FIG> illustrates an example in which the packet replication unit <NUM>, the data extraction unit <NUM>, and the switch processing unit <NUM> are provided for each input port for inputting the packet flow, a single packet replication unit <NUM>, a single data extraction unit <NUM>, and a single switch processing unit <NUM> may collectively process a plurality of input ports.

The extraction data transmitting unit <NUM> uses the extraction data output from each data extraction unit <NUM> as "packet-based extraction data", obtains information necessary for forming a plurality of pieces of packet-based extraction data and the "extraction data common header" (see <FIG>) and the "extraction data individual header" (see <FIG>) from each data extraction unit <NUM> to form an "extraction data report packet", and outputs the same to the extraction data aggregation device <NUM>.

The PTP processing unit <NUM> is a processing unit that communicates with a PTP master device <NUM> (not illustrated in <FIG>) in the network according to PTP (Precision Time Protocol) and synchronizes the operating time of each packet replication unit <NUM> in the packet data extraction device <NUM> with the control time of the PTP master device <NUM>, and is similar to a general PTP processing mechanism.

<FIG> is a block diagram illustrating a schematic configuration of the data extraction unit <NUM> in the packet data extraction device <NUM> in the packet flow monitoring device <NUM> of the first embodiment according to the present invention.

The data extraction unit <NUM> includes a packet type determination unit <NUM>, an RTP extraction unit <NUM>, a PTP extraction unit <NUM>, an IGMP extraction unit <NUM>, an IP extraction unit <NUM>, a UDP extraction unit <NUM>, a TCP extraction unit <NUM>, and an E-frame extraction unit <NUM>.

The packet type determination unit <NUM> determines a packet type from the header information and the payload of the replicated passing packet obtained from the packet replication unit <NUM> and outputs the replicated passing packet and the reception time information to any one of the corresponding RTP extraction unit <NUM>, PTP extraction unit <NUM>, IGMP extraction unit <NUM>, IP extraction unit <NUM>, UDP extraction unit <NUM>, TCP extraction unit <NUM>, and E-frame extraction unit <NUM> according to the determination result.

The RTP extraction unit <NUM>, the PTP extraction unit <NUM>, the IGMP extraction unit <NUM>, the IP extraction unit <NUM>, the UDP extraction unit <NUM>, the TCP extraction unit <NUM>, and the E-frame extraction unit <NUM> are each configured to extract some predetermined pieces of information (see <FIG>) from the replicated passing packet as the "extraction data" and output the same to the extraction data transmitting unit <NUM>.

Further, the RTP extraction unit <NUM>, the PTP extraction unit <NUM>, the IGMP extraction unit <NUM>, the IP extraction unit <NUM>, the UDP extraction unit <NUM>, the TCP extraction unit <NUM>, and the E-frame extraction unit <NUM> are each configured to identify the information of "extraction data common header" (see <FIG>) and the "extraction data individual header" (see <FIG>) necessary for forming the "extraction data report packet" illustrated in <FIG> and <FIG> on the basis of the reception time information and output the same to the extraction data transmitting unit <NUM>.

That is, the RTP extraction unit <NUM>, the PTP extraction unit <NUM>, the IGMP extraction unit <NUM>, the IP extraction unit <NUM>, the UDP extraction unit <NUM>, the TCP extraction unit <NUM>, and the E-frame extraction unit <NUM> are each configured to identify the "device ID" for identifying the packet data extraction device <NUM> to which the unit belongs, the "timestamp value (seconds) synchronized with PTP during reception of beginning data" and the "timestamp value (nanoseconds) synchronized with PTP during reception of beginning data" related to the reception time of the extracted passing packet in the corresponding packet flow, the "passing packet length" indicating the length of the corresponding passing packet, the "data type" indicating the packet type of the corresponding passing packet, and the information of "reception port ID" for identifying each packet flow and output the same to the extraction data transmitting unit <NUM>.

As a result, the extraction data transmitting unit <NUM> uses the extraction data output from one or more data extraction units <NUM> as "packet-based extraction data", and can obtain information necessary for forming one or more pieces of packet-based extraction data and the "extraction data common header" (see <FIG>) and the "extraction data individual header" (see <FIG>) from the data extraction unit <NUM>, forms the "extraction data report packet" composed of IP format packets having a variable length within a range not exceeding the predetermined packet length illustrated in <FIG>, and outputs the same to the extraction data aggregation device <NUM>.

<FIG> is a flowchart illustrating a determination example of a packet type (data type) by the packet type determination unit <NUM> in the packet data extraction device <NUM> in the packet flow monitoring device <NUM> of the first embodiment according to the present invention.

Upon acquiring the replicate packet (step S1), the packet type determination unit <NUM> determines the packet type from the header information and the payload in the following procedure.

First, the packet type determination unit <NUM> determines whether the type number of the E-frame is indicated from the header information of the replicate packet, and whether the type number is 0x0800 when the type number of the E-frame is indicated (Step S2). The flow proceeds to step S3 if 0x0800 is indicated as the type number of the E-frame, and otherwise, the replicate packet is transmitted to the E-frame processing unit <NUM> (step S6).

When the flow proceeds to step S3, the packet type determination unit <NUM> determines whether the header information of the IP header is indicated from the header information of the replicate packet and whether the protocol number is 0x01, 0x06, or 0x11 when the header information of the IP header is indicated (step S3). The packet type determination unit <NUM> transmits the replicate packet to the IGMP processing unit <NUM> when 0x02 is indicated as the protocol number of the IP header (step S9) and transmits the replicate packet to the TCP processing unit <NUM> when 0x06 is indicated (step S8), and the flow proceeds to step S4 when 0x11 is indicated as the protocol number of the IP header, and otherwise, the replicate packet is transmitted to the IP processing unit <NUM> (step S7).

When the flow proceeds to step S4, the packet type determination unit <NUM> determines whether the UDP port number is indicated from the header information of the replicate packet, and determines whether the port number is <NUM>, <NUM>, <NUM> or greater when the UDP port number is indicated (step S4). The replicate packet is transmitted to the PTP processing unit <NUM> when the UDP port number is <NUM> or <NUM> (step S11). The flow proceeds to step S5 when the UDP port number is <NUM> or greater, and otherwise, the replicate packet is transmitted to the UDP processing unit <NUM> (step S10).

When the flow proceeds to step S5, the packet type determination unit <NUM> determines whether the first two bits are 0x2 from the payload information of the replicate packet (that is, the first two bits of the payload of UDP) (step S5). The packet type determination unit <NUM> transmits the replicate packet to the RTP processing unit <NUM> when 0x2 is indicated as the first two bits of the payload of UDP (step S12), and otherwise, the replicate packet is transmitted to the UDP processing unit <NUM> (step S10).

In this way, the packet type determination unit <NUM> can determine the packet type from the header information and the payload of the replicated passing packet obtained from the packet replication unit <NUM>.

<FIG> illustrate signal formats of packet-based extraction data type assigned in the "extraction data report packet" illustrated in <FIG> in the first embodiment.

As illustrated in <FIG>, the extraction data for the E-frame network includes a destination MAC address, a source MAC address, and a type number of an E-frame header.

As illustrated in <FIG>, the extraction data for the IP network includes a destination MAC address, a source MAC address, a source IP address, a destination IP address, and a protocol number of an IP header.

As illustrated in <FIG>, the extraction data for IGMP includes a destination MAC address, a source MAC address, a source IP address, a destination IP address, a difference (<NUM> byte) between a passing packet length, and an IGMP payload length, and <NUM> bytes of IGMP payload from the beginning.

As illustrated in <FIG>, the extraction data for TCP or UDP includes a destination MAC address, a source MAC address, a source IP address, a destination IP address, a source L4-port number, and a destination L4-port number.

As illustrated in <FIG>, the extraction data for PTP includes a destination MAC address, a source MAC address, a source IP address, a destination IP address, a source L4-port number, a destination L4-port number, a difference (<NUM> byte) between a passing packet length and (PTP header + passing packet length), and the entire part of the PTP header and the PTP payload.

As illustrated in <FIG>, the extraction data for RTP includes a destination MAC address, a source MAC address, a source IP address, a destination IP address, a source L4-port number, a destination L4-port number, a difference (<NUM> byte) between a passing packet length and an RTP payload length, a marker bit M (<NUM> bit) of the RTP header, a payload type PT (<NUM> bits) of the RTP header, an RTP sequence number, an RTP timestamp value, and SSRC (<NUM> bits) which is an identifier indicating the source.

As illustrated in <FIG>, for any of the seven types of packets, only some pieces of information which is a quality monitoring target related to packet flow is extracted as header information, the header information includes a part of the payload of IGMP when the packet type is IGMP and includes the entire payload of PTP when the packet type is PTP. Therefore, the extraction data aggregation device <NUM> described below can perform monitoring and quality measurement with higher convenience and higher accuracy.

<FIG> is a block diagram illustrating a schematic configuration of the extraction data aggregation device <NUM> in the packet flow monitoring device <NUM> of the first embodiment according to the present invention.

The extraction data aggregation device <NUM> includes an extraction data report packet receiving unit <NUM>, an extraction data aggregation unit <NUM>, and an aggregation data output unit <NUM>. Further, the extraction data aggregation unit <NUM> includes an extraction data type determination unit <NUM>, an RTP aggregation unit <NUM>, a PTP aggregation unit <NUM>, an IGMP aggregation unit <NUM>, an IP aggregation unit <NUM>, a UDP aggregation unit <NUM>, a TCP aggregation unit <NUM>, an E-frame aggregation unit <NUM>, and an aggregation data recording unit <NUM>.

Upon receiving the extraction data report packet from the extraction data totaling device <NUM>, the extraction data report packet receiving unit <NUM> extracts the extraction data common header and packet-based extraction data and outputs the same to the extraction data aggregation unit <NUM>.

The extraction data aggregation unit <NUM> analyzes the content (that is, data corresponding to each protocol) of the packet-based extraction data indicating some pieces of information in each replicated passing packet in the extraction data report packet sequentially received by the extraction data report packet receiving unit <NUM>, aggregates the same for each packet flow, and collectively records the same in the aggregation data recording unit <NUM> as aggregation data.

The aggregation data output unit <NUM> reads the aggregation data from the aggregation data recording unit <NUM> in the aggregation data aggregation unit <NUM> according to an external instruction, and outputs the aggregation data to external devices. The aggregation data output from the aggregation data output unit <NUM> can be written to another general storage device (not illustrated) or transmitted to a display device (not illustrated) in an IP packet format for display. As a result, the aggregation data can be output to external devices so that the quality related to each packet flow can be monitored and predetermined quality information described later can be measured.

Here, the details of the extraction data aggregation unit <NUM> will be described.

The extraction data type determination unit <NUM> determines the packet type from the data type described in the extraction data individual header in the packet-based extraction data in the extraction data report packet sequentially received by the extraction data report packet reception unit <NUM> through the extraction data type determination unit <NUM> and outputs the extraction data common header and the packet-based extraction data to any one of the corresponding RTP aggregation unit <NUM>, PTP aggregation unit <NUM>, IGMP aggregation unit <NUM>, IP aggregation unit <NUM>, UDP aggregation unit <NUM>, TCP aggregation unit <NUM>, and E-frame aggregation unit <NUM> according to the determination result.

The RTP aggregation unit <NUM> analyzes the extraction data common header and the packet-based extraction data in each replicated passing packet related to RTP in the extraction data report packet sequentially received by the extraction data report packet receiving unit <NUM> via the extraction data type determination unit <NUM> to read a source MAC address, a destination MAC address, a source IP address, a destination IP address, a source L4-port number, and a destination L4-port number, aggregates an average throughput, a total number of received packets, an RTP marker bit value (M), the number of packets where M indicates <NUM>, a packet reception interval (average/minimum/maximum), the number of packet losses, and the maximum number of burst losses using packets (replicated passing packets) of which the six items are the same as the same packet flow, generates aggregation data in which an RTP payload type number and an RTP SSRC value of the last replicated passing packet in each of the aggregated packet flows are added, and records the same in the aggregation data recording unit <NUM>.

The PTP aggregation unit <NUM> analyzes the extraction data common header and the packet-based extraction data in each replicated passing packet related to RTP in the extraction data report packet sequentially received by the extraction data report packet receiving unit <NUM> through the extraction data type determination unit <NUM> to read a source MAC address, a destination MAC address, a source IP address, a destination IP address, a source L4-port number, and a destination L4-port number, aggregates an average throughput, a total number of received packets, and a transmission delay (average/minimum/maximum) using packets (replicated passing packets) of which the six items are the same as the same packet flow, generates aggregation data in which the reception time and "PTP header and payload" of the last replicated passing packet in each of the aggregated packet flows are added, and records the same in the aggregation data recording unit <NUM>.

The IGMP aggregation unit <NUM> analyzes the extraction data common header and the packet-based extraction data in each replicated passing packet related to RTP in the extraction data report packet sequentially received by the extraction data report packet receiving unit <NUM> through the extraction data type determination unit <NUM> to read a source MAC address, a destination MAC address, a source IP address, and a destination IP address, aggregates an average throughput and a total number of received packets using packets (replicated passing packets) of which the four items are the same as the same packet flow, generates aggregation data in which the reception time and the IGMP payload of the last replicated passing packet in each of the aggregated packet flows are added, and records the same in the aggregation data recording unit <NUM>.

The IP aggregation unit <NUM> analyzes the extraction data common header and the packet-based extraction data in each passing packet related to RTP in the extraction data report packet sequentially received by the extraction data report packet reception unit <NUM> through the extraction data type determination unit <NUM> to read a source MAC address, a destination MAC address, a source IP address, a destination IP address, and an IP header protocol number, aggregates an average throughput and a total number of received packets using packets (replicated passing packets) of which the five items are the same as the same packet flow to generate aggregation data, and records the same in the aggregation data recording unit <NUM>.

The UDP aggregation unit <NUM> analyzes the extraction data common header and the packet-based extraction data in each passing packet related to RTP in the extraction data report packet sequentially received by the extraction data report packet reception unit <NUM> through the extraction data type determination unit <NUM> to read a source MAC address, a destination MAC address, a source IP address, a destination IP address, a source L4-port number, and a destination L4-port number, aggregates an average throughput and a total number of received packets using packets (replicated passing packets) of which the six items are the same as the same packet flow to generate aggregation data, and records the same in the aggregation data recording unit <NUM>.

The TCP aggregation unit <NUM> analyzes the extraction data common header and the packet-based extraction data in each passing packet related to RTP in the extraction data report packet sequentially received by the extraction data report packet reception unit <NUM> through the extraction data type determination unit <NUM> to read a source MAC address, a destination MAC address, a source IP address, a destination IP address, a source L4-port number, and a destination L4-port number, aggregates an average throughput and a total number of received packets using packets (replicated passing packets) of which the six items are the same as the same packet flow to generate aggregation data, and records the same in the aggregation data recording unit <NUM>.

The E-frame aggregation unit <NUM> analyzes the extraction data common header and the packet-based extraction data in each passing packet related to RTP in the extraction data report packet sequentially received by the extraction data report packet reception unit <NUM> through the extraction data type determination unit <NUM> to read a source MAC address, a destination MAC address, and an E-frame type number, aggregates an average throughput and a total number of received packets using packets (replicated passing packets) of which the three items are the same as the same packet flow to generate aggregation data, and records the same in the aggregation data recording unit <NUM>.

The "average throughput" can be calculated from the "passing packet length" illustrated in <FIG>, the "timestamp value synchronized with PTP during reception of beginning data", and the "elapsed time from timestamp value of received PTP of data from timestamp value synchronized with PTP during reception of beginning data".

The aggregation data recording unit <NUM> records the aggregation data (see <FIG>) aggregated for each data type by the RTP aggregation unit <NUM>, the PTP aggregation unit <NUM>, the IGMP aggregation unit <NUM>, the IP aggregation unit <NUM>, the UDP aggregation unit <NUM>, the TCP aggregation unit <NUM>, and the E-frame aggregation unit <NUM>.

As illustrated in <FIG>, among the pieces of aggregation data according to the first embodiment, the E-frame aggregation data includes the source MAC address, the destination MAC address, the E-frame type number, the average throughput, and the total number of received packets for each packet flow.

Further, the IP aggregation data includes the source MAC address, the destination MAC address, the source IP address, the destination IP address, the IP header protocol number, the average throughput, and the total number of received packets for each packet flow.

In addition, the IGMP aggregation data includes the source MAC address, the destination MAC address, the source IP address, the destination IP address, the average throughput, the total number of received packets, the reception time, and the IGMP payload (<NUM> bytes from the beginning) for each packet flow.

In addition, the TCP or UDP aggregation data includes the source MAC address, the destination MAC address, the source IP address, the destination IP address, the source L4-port number, the destination L4-port number, the average throughput, and the total number of received packets for each packet flow.

In addition, the PTP aggregation data includes the source MAC address, the destination MAC address, the source IP address, the destination IP address, the source L4-port number, the destination L4-port number, the average throughput, the total number of received packets, and the transmission delay (average/minimum/maximum), the reception time, and the PTP header and payload (entire part) for each packet flow.

In addition, the RTP aggregation data includes the source MAC address, the destination MAC address, the source IP address, the destination IP address, the source L4-port number, the destination L4-port number, the average throughput, the total number of received packets, the RTP payload type number, the RTP, SSRC, and RTP marker bit value (M), the number of packets in which M indicates <NUM>, the packet reception interval (average/minimum/maximum), the number of packet losses, and the maximum number of burst losses for each packet flow.

According to the packet flow monitoring device <NUM> of the first embodiment configured as described above, it is possible to efficiently obtain aggregation data related to the packet flow of all packets in the program production system constructed by an E-frame or IP packet network and monitor and measure the quality related to packet flow with high accuracy.

In particular, according to the packet flow monitoring device <NUM> of the first embodiment, some predetermined pieces of information (including some pieces of information in the packet header, a part of the payload if the packet type is IGMP, and an entire part of the payload if the packet type is PTP) in the passing packet passing through an E-frame or IP packet network are extracted and aggregated to form the extraction data report packet. Therefore, it is possible to monitor and measure the quality of all packets even for information on traffic flowing through a high-throughput network (for example, signal transmission related to a <NUM>/<NUM> video system as a packet flow with a high transmission rate).

Further, according to the packet flow monitoring device <NUM> of the first embodiment, when the some predetermined pieces of information in the passing packet are extracted, the packet type of the passing packet is determined, and the necessary information can be extracted according to the packet type. Therefore, it is possible to monitor detailed information such as throughput and a packet loss for each packet flow in real-time.

The schematic configuration of the packet flow monitoring device <NUM> of the second embodiment is the same as that illustrated in <FIG> and <FIG>. However, the second embodiment is different in that the RTP extraction unit <NUM> of the packet data extraction device <NUM> illustrated in <FIG> includes a marker bit inspection unit <NUM> and an RTP data extraction unit <NUM> as illustrated in <FIG>, and the RTP aggregation unit <NUM> of the extraction data aggregation device <NUM> illustrated in <FIG> includes an RTP data processing unit <NUM>, an RTP payload determination unit <NUM>, an ST <NUM>-<NUM> processing unit <NUM>, an ST <NUM>-<NUM> processing unit <NUM>, and an ST <NUM>-<NUM> processing unit <NUM> as illustrated in <FIG>.

<FIG> are block diagrams illustrating a schematic configuration of the RTP extraction unit <NUM> of the packet data extraction device <NUM> and the RTP aggregation unit <NUM> of the extraction data aggregation device <NUM> in the packet flow monitoring device <NUM> of the second embodiment according to the present invention, respectively. The same reference numbers are assigned to the same components as those in the first embodiment described above.

First, as illustrated in <FIG>, the RTP extraction unit <NUM> in the packet data extraction device <NUM> of the present embodiment includes a marker bit inspection unit <NUM> and an RTP data extraction unit <NUM>.

The marker bit inspection unit <NUM> receives the reception time information and the replicated passing packet via the packet type determination unit <NUM>, inspects whether the value of the marker bit M is <NUM> or <NUM> from the header information in the replicated passing packet, and outputs the reception time information and the replicated passing packet to the RTP data extraction unit <NUM> together with the value of the marker bit M.

The RTP data extraction unit <NUM> identifies the information of the "extraction data common header" (see <FIG>) and the "extraction data individual header" (see <FIG>) necessary for forming the "extraction data report packet" illustrated in <FIG> and <FIG> on the basis of the reception time information obtained through the packet type determination unit <NUM>, extracts some predetermined pieces of information from the replicated passing packet as the "extraction data" according to the value of the marker bit M, and outputs the same to the extraction data transmitting unit <NUM>.

Here, the RTP data extraction unit <NUM> according to the second embodiment extracts the "extraction data" illustrated in <FIG> similar to the first embodiment when the value of the marker bit M is <NUM>, and extracts the "extraction data" illustrated in <FIG> when the value of the marker bit M is <NUM>.

That is, in the "packet-based extraction data for RTP" illustrated in <FIG>, the "extraction data" is different from the "extraction data" illustrated in <FIG> according to the first embodiment in that <NUM> bytes of the "RPP payload" from the beginning are added. If the RTP payload stored in the replicated passing packet is less than <NUM> bytes, <NUM> is complemented as the "RPP payload" in the "extraction data" illustrated in <FIG>.

On the other hand, as illustrated in <FIG>, the RTP aggregation unit <NUM> in the extraction data aggregation device <NUM> of the present embodiment includes an RTP data processing unit <NUM>, an RTP payload determination unit <NUM>, an ST <NUM>-<NUM> processing unit <NUM>, an ST <NUM>-<NUM> processing unit <NUM>, and an ST <NUM>-<NUM> processing unit <NUM>.

When the value of the marker bit M is <NUM>, the RTP data processing unit <NUM> performs data aggregation by the same operation as in the first embodiment and outputs the aggregation data to the aggregation data recording unit <NUM> while omitting the processes of the RTP payload determination unit <NUM>, the ST <NUM>-<NUM> processing unit <NUM>, the ST <NUM>-<NUM> processing unit <NUM>, and the ST <NUM>-<NUM> processing unit <NUM>. However, when the value of the marker bit M is <NUM>, the RTP data processing unit <NUM> outputs the aggregation data to the aggregation data recording unit <NUM> through the processes of the RTP payload determination unit <NUM>, the ST <NUM>-<NUM> processing unit <NUM>, the ST <NUM>-<NUM> processing unit <NUM>, and the ST <NUM>-<NUM> processing unit <NUM>.

That is, when the value of the marker bit M is <NUM>, the RTP data processing unit <NUM> analyzes the extraction data common header and the packet-based extraction data in each replicated passing packet related to RTP in the extraction data report packet sequentially received by the extraction data report packet receiving unit <NUM> via the extraction data type determination unit <NUM> to read a source MAC address, a destination MAC address, a source IP address, a destination IP address, a source L4-port number, and a destination L4-port number, aggregates an average throughput, a total number of received packets, the number of packets where the RTP marker bit indicates <NUM>, a packet reception interval (average/minimum/maximum), the number of packet losses, and the maximum number of burst losses using packets (replicated passing packets) of which the six items are the same as the same packet flow, temporarily generates aggregation data in which the RTP payload type number and the RTP SSRC value of the last replicated passing packet in each of the aggregated packet flows are added, and outputs the same to the RTP payload determination unit <NUM> together with the replicated passing packets.

The RTP payload determination unit <NUM> compares the determination information given by an external instruction (a list in which the source IP address, the destination IP address, the source L4-port number, and the destination L4-port number are paired with information indicating to which SMPTE protocol of ST <NUM>-<NUM>, ST <NUM>-<NUM>, or ST <NUM>-<NUM>, the packet flow having of which the four items match corresponds) with the source IP address, the destination IP address, the source L4-port number, and the destination L4-port number of the packet being processed among the replicated passing packets obtained from the RTP data processing unit <NUM>. When the items match, the RTP payload determination unit <NUM> transmits the packet-based extraction data of the packet being processed to the ST <NUM>-<NUM> processing unit, the ST <NUM>-<NUM> processing unit, and the ST <NUM>-<NUM> processing unit of the corresponding SMPTE protocol together with the temporarily generated aggregation data.

The RTP payload determination unit <NUM> discards the packet being processed of which the items do not match, and outputs the aggregation data temporarily aggregated by the RTP data processing unit <NUM> to the aggregation data recording unit <NUM> as it is.

The ST <NUM>-<NUM> processing unit <NUM> analyzes the packet-based extraction data of the packet being processed, which is input from the RTP payload determination unit <NUM> to acquire predetermined information related to video and synchronization characterized by the SMPTE ST <NUM>-<NUM>, adds the same to the aggregation data temporarily aggregated by the RTP data processing unit <NUM>, and outputs the same to the aggregation data recording unit <NUM>.

The ST <NUM>-<NUM> processing unit <NUM> analyzes the packet-based extraction data of the packet being processed, which is input from the RTP payload determination unit <NUM> to acquire predetermined information related to audio and synchronization characterized by the SMPTE ST <NUM>-<NUM>, adds the same to the aggregation data temporarily aggregated by the RTP data processing unit <NUM>, and outputs the same to the aggregation data recording unit <NUM>.

The ST <NUM>-<NUM> processing unit <NUM> analyzes the packet-based extraction data of the packet being processed, which is input from the RTP payload determination unit <NUM> to acquire predetermined information related to video, audio, and synchronization characterized by SMPTE ST <NUM>-<NUM>, adds the same to the aggregation data temporarily aggregated by the RTP data processing unit <NUM>, and outputs the same to the aggregation data recording unit <NUM>.

<FIG> are block diagrams illustrating a schematic configuration of the ST <NUM>-<NUM> processing unit <NUM> and the ST <NUM>-<NUM> processing unit <NUM> of the extraction data aggregation device <NUM> in the packet flow monitoring device <NUM> of the second embodiment according to the present invention, respectively.

First, as illustrated in <FIG>, the ST <NUM>-<NUM> processing unit <NUM> includes a delay calculation unit <NUM>, a resolution calculation unit <NUM>, a frame rate calculation unit <NUM>, and a video scanning method identification unit <NUM>.

The delay calculation unit <NUM> operates when the value of the marker bit M is <NUM>, and calculates a transmission delay time (a delay time indicating average/minimum/maximum) from the RTP timestamp value (in the extraction data) and the packet reception time (the received PTP time in the extraction data individual header) in the packet-based extraction data of the packet being processed obtained from the RTP payload determination unit <NUM> by the following calculation, adds the same to the aggregation data temporarily aggregated by the RTP data processing unit <NUM>, and outputs the same to the aggregation data recording unit <NUM>.

The resolution calculation unit <NUM> operates when the value of the marker bit M is <NUM>, analyzes the RTP payload in the packet-based extraction data of the packet being processed obtained from the RTP payload determination unit <NUM> as the ST <NUM>-<NUM> header, reads the last number of lines included in the header, determines the height of an image, acquires the width of the image using the height of the image as a key from a table held in advance, obtains the height and width of the image, and outputs the same to the aggregation data recording unit <NUM> so as to be added to the aggregation data temporarily aggregated by the RTP data processing unit <NUM>.

More specifically, the value of the 49th bit from the beginning of the ST <NUM>-<NUM> header (the value of "C" illustrated in <FIG>, but will be referred to as a Cont value herein) is checked. If this Cont value is <NUM>, since the next Cont value is present <NUM> bits behind, the Cont value is sequentially checked until the Cont value becomes <NUM>. When the Cont value is <NUM>, the value of the 17th bit before the Cont value is the number of lines to be read ("Line No" illustrated in <FIG>).

Then, from the header information according to ST <NUM>-<NUM> illustrated in <FIG>, the height of the image can be obtained on the basis of the interlace information of the packet flow to be aggregated (the value of F in the 33rd bit of the ST <NUM>-<NUM> header), the next F value, and the number of lines read. When the height of the image is obtained, the width of the image can be obtained using the height of the image as a key from a predetermined table, and the height and the width of the image can be obtained.

The frame rate calculation unit <NUM> operates when the value of the marker bit M is <NUM> and the value of F in the 33rd bit of the ST <NUM>-<NUM> header is <NUM>, calculates the frame rate from the RTP timestamp value in the packet-based extraction data of the packet being processed obtained from the RTP payload determination unit <NUM>, and outputs the same to the aggregation data recording unit <NUM> so as to be added to the aggregation data temporarily aggregated by the RTP data processing unit <NUM>.

More specifically, the RTP timestamp value (initial value is <NUM>) in the aggregation data temporarily aggregated is read, and the difference from the RTP timestamp value of the processing target packet is calculated. The frame rate is <NUM> fps, <NUM> fps, <NUM> fps, <NUM> fps, <NUM> fps, and <NUM> fps when this difference is <NUM>, <NUM>, <NUM>, <NUM>, <NUM> or <NUM>, and <NUM>, respectively. The frame rate values are recorded in the aggregation data recording unit <NUM> so as to be added to the aggregation data temporarily aggregated. Further, the frame rate calculation unit <NUM> updates the RTP timestamp value of the aggregation data recorded in the aggregation data recording unit <NUM> with the read RTP timestamp value.

The video scanning method identification unit <NUM> operates when the value of the marker bit M is <NUM>, and analyzes the RTP payload in the packet-based extraction data of the packet being processed obtained from the RTP payload determination unit <NUM> as the ST <NUM>-<NUM> header, determines from the header whether the video frame is interlaced or progressive, and outputs the determination result to the aggregation data recording unit <NUM> so as to be added to the aggregation data temporarily aggregated by the RTP data processing unit <NUM>.

Next, as illustrated in <FIG>, the ST <NUM>-<NUM> processing unit <NUM> includes a delay calculation unit <NUM>, a sampling frequency calculation unit <NUM>, a packet time identification unit <NUM>, and a payload length update unit <NUM>.

The sampling frequency calculation unit <NUM> operates when the value of the marker bit M is <NUM>, examines the RTP timestamp value (in the extraction data) in the packet-based extraction data of the packet being processed obtained from the RTP payload determination unit <NUM>, calculates the sampling frequency by calculating a difference TSdiff of the recorded RTP timestamp (initial value <NUM>) of one second before by the following calculation when the value of the second of the reception time of ST <NUM>-<NUM> is changed from the recorded RTP timestamp (initial value <NUM>) before one second, and outputs the same to the aggregation data recording unit <NUM> so as to be added to the aggregation data temporarily aggregated by the RTP data processing unit <NUM>. Further, the sampling frequency calculation unit <NUM> updates the RTP timestamp value of the aggregation data recorded in the aggregation data recording unit <NUM> with the read RTP timestamp value.

α is a parameter corresponding to network jitter, and normally, network jitter can be sufficiently covered by setting α to <NUM> seconds. Therefore, in this example, the sampling frequency calculation unit <NUM> sets α = <NUM> and updates the RTP timestamp of one second before of the aggregation data recording unit with the RTP timestamp value of the packet in which the value of the second of the reception time has increased.

The packet time identification unit <NUM> operates when the value of the marker bit M is <NUM>, examines the RTP timestamp value (in the extraction data) in the packet-based extraction data of the packet being processed obtained from the RTP payload determination unit <NUM>, calculates the packet time from a present RTP timestamp value (RTPtimestampnow), a previous RTP timestamp value (RTPtimestamppre) of the aggregation data recorded in the aggregation data recording unit <NUM>, and the sampling frequency recorded in the aggregation data recording unit <NUM> by the following calculation, adds the same to the aggregation data temporarily aggregated by the RTP data processing unit <NUM>, and outputs the same to the aggregation data recording unit <NUM>.

The packet time identification unit <NUM> does not calculate the packet time when the sampling frequency is indefinite.

The delay calculation unit <NUM> is substantially the same as the operation of the delay calculation unit <NUM> described above, operates when the value of the marker bit M is <NUM>, calculates the transmission delay time (a delay time indicating the average/minimum/maximum value) from the RTP timestamp value (in the extraction data) in the packet-based extraction data of the packet being processed obtained from the RTP payload determination unit <NUM> and the packet reception time (the received PTP time in the extraction data individual header) by the following calculation, and outputs the same to the aggregation data recording unit <NUM> so as to be added to the aggregation data temporarily aggregated by the RTP data processing unit <NUM>.

The delay calculation unit <NUM> does not calculate the transmission delay time (delay time indicating the average/minimum/maximum value) when the sampling frequency is indefinite.

The payload length update unit <NUM> operates when the value of the marker bit M is <NUM>, calculates the difference between the "passing packet length" (in the extraction data individual header)" in the packet-based extraction data of the packet being processed obtained from the RTP payload determination unit <NUM> and the "difference between passing packet length and RTP passing packet length" (in the extraction data) included in the extraction data in the case of RTP, and outputs the same to the aggregation data recording unit <NUM> so as to update the payload length in the aggregation data temporarily aggregated by the RTP data processing unit <NUM> with the calculated payload length.

The ST <NUM>-<NUM> processing unit operates when the value of the marker bit M is <NUM>, analyzes the RTP payload in the packet-based extraction data of the packet being processed obtained from the RTP payload determination unit <NUM> as the ST <NUM>-<NUM> header (<FIG>), extract the values of MAP, FRAME, FRATE, SAMPLE, and R included in the header, and outputs the same to the aggregation data recording unit <NUM> so as to update the payload length in the aggregation data temporarily aggregated by the RTP data processing unit <NUM>.

Therefore, the aggregation data recording unit <NUM> according to the present embodiment adds and records the aggregation data to the aggregation data of the first embodiment individually according to the SMPTE protocols of ST <NUM>-<NUM>, ST <NUM>-<NUM>, and ST <NUM>-<NUM> as RTP aggregation data (see <FIG>) with the aid of the RTP aggregated unit <NUM> illustrated in <FIG>.

That is, as illustrated in <FIG>, the data on the right side of the figure is aggregated data added to the aggregation data of the first embodiment on the left side of the figure.

More specifically, for (ST <NUM>-<NUM>), the respective values of data output by RTP, a resolution, a frame rate, identification of interlaced/progressive, and transmission delay (average/minimum/maximum) are added to the aggregation data.

For (ST <NUM>-<NUM>), the respective values of data output by RTP, a sampling frequency, a packet time, a payload length, and transmission delay (average/minimum/maximum) are added to the aggregation data.

Regarding (ST <NUM>-<NUM>), the data output by RTP, the MAP value in ST <NUM>-<NUM>, the frame value in ST <NUM>-<NUM>, the FRATE value in ST <NUM>-<NUM>, the SAMPLE value in ST <NUM>-<NUM>, and the R-value in ST <NUM>-<NUM> are added to the aggregation data.

According to the packet flow monitoring device <NUM> of the second embodiment configured as described above, in addition to the effects of the first embodiment, more detailed information such as the delay of the video or audio signal used in the program production system, the video resolution, and the like can be monitored in real-time.

The schematic configuration of the packet flow monitoring device <NUM> of the third embodiment is the same as that illustrated in <FIG> and <FIG>, and is an example in which data can be compressed before forming the extraction data report packet. However, the third embodiment is different in that the extraction data transmitting unit <NUM> of the packet data extraction device <NUM> illustrated in <FIG> includes a number of extraction data compression unit <NUM> and extraction data storage units <NUM> corresponding to the number of extraction target ports, and an extraction data report packet transmitting units <NUM> as illustrated in <FIG>, and the extraction data report packet receiving unit <NUM> of the extraction data aggregation device <NUM> illustrated in <FIG> includes an extraction data restoration unit <NUM> and an extraction data storage unit <NUM> as illustrated in <FIG>.

Since the packet flow monitoring device <NUM> of the third embodiment can be configured as a modified example of the first embodiment and further as a modified example of the second embodiment, an example in which the packet flow monitoring device <NUM> is configured as a modified example of the second embodiment will be described.

That is, in order to facilitate the understanding of the configuration according to the third embodiment, "packet-based extraction data for RTP" will be described as a representative example. However, the "packet-based extraction data for RTP" according to the third embodiment is different from the "RTP packet-based extraction data" according to the second embodiment illustrated in <FIG> in that as illustrated in <NUM>, a data compression presence/absence flag C indicating the presence/absence of data compression and data compression position flags DM, SM, SI, DI, SP, DP, TS, and SS indicating the data position of data compression are assigned to predetermined positions.

The data compression presence/absence flag C indicates <NUM> when data compression is performed in the extraction data, and <NUM> when data compression is not performed.

The data compression position flag DM indicates <NUM> when data is omitted with respect to the destination MAC address, and <NUM> when data is not omitted.

The data compression position flag SM indicates <NUM> when data is omitted with respect to the source MAC address, and <NUM> when data is not omitted.

The data compression position flag SI indicates <NUM> when data is omitted with respect to the source IP address, and <NUM> when data is not omitted.

The data compression position flag DI indicates <NUM> when the data is omitted with respect to the destination IP address, and <NUM> when the data is not omitted.

The data compression position flag SP indicates <NUM> when data is omitted with respect to the source L4-port number, and <NUM> when data is not omitted.

The data compression position flag DP indicates <NUM> when data is omitted with respect to the destination L4-port number, and <NUM> when data is not omitted.

The data compression position flag TS indicates <NUM> when the data is omitted with respect to the RTP timestamp value, and <NUM> when the data is not omitted.

The data compression position flag SS indicates <NUM> when data is omitted for SSRC, and <NUM> when data is not omitted.

<FIG> are block diagrams illustrating the schematic configuration of the extraction data transmitting unit <NUM> of the packet data extraction device <NUM> and the extraction data report packet receiving unit <NUM> of the extraction data aggregation device <NUM> in the packet flow monitoring device <NUM> of the third embodiment of the present invention, respectively. The same reference numbers are assigned to the same components as those in the above-described embodiments.

First, as illustrated in <FIG>, the extraction data transmitting unit <NUM> of the packet data extraction device <NUM> of the present embodiment includes a number of extraction data compression units <NUM> and extraction data storage units <NUM> corresponding to the number of extraction target ports and an extraction data report packet transmitting unit <NUM>. The extraction data compression units <NUM> as many as the number of extraction target ports are arranged in respective input ports of the packet data extraction device <NUM>, and are configured such that data compression is performed before forming an extraction data report packet for each input port. That is, when the packet data extraction device <NUM> creates the extraction data, the data compression is performed for the extraction data to be stored in the same extraction data report packet received on the same port (same packet flow).

The extraction data compression unit <NUM> sequentially stores the data received from the data extraction unit <NUM> in a built-in queue (not illustrated). When data that can be output to the extraction data report packet transmitting unit <NUM> is not present in the queue, the extraction data compression unit <NUM> notifies the extraction data report packet transmitting unit <NUM> of the fact that data is not present.

Then, when the data that can be output to the extraction data report packet transmitting unit <NUM> is present in the queue, the extraction data compression unit <NUM> reads the beginning data of the queue in the following procedure to generate the packet-based extraction data and outputs the same to the extraction data report packet transmitting unit <NUM>.

Here, when a state where data can be output to the extraction data aggregation device <NUM> as an "extraction data report packet" is created, the extraction data report packet transmitting unit <NUM> outputs "compressibility information," "maximum data length", and "reception time (timestamp value of received PTP based on reception of beginning data illustrated in <FIG>)" to the extraction data compression unit <NUM> as compression request information, and requests the extraction data compression unit <NUM> to output "packet-based extraction data" serving as a transmission target.

First, when the compressibility information is "non-compressible", the extraction data compression unit <NUM> sets the 33rd bit (C) of the extraction data individual header to <NUM>, creates packet-based extraction data corresponding to the data type from the beginning data of the queue, and temporarily stores the same in the extraction data storage unit <NUM>, and outputs the same to the extraction data report packet transmitting unit <NUM>.

On the other hand, when the compressibility information is "compressible", the extraction data compression unit <NUM> compares the "destination MAC address", "source MAC address", "destination IP address", "source MAC address," "destination L4-port number", "source L4-port number", "RTP timestamp", and "RTP SSRC" of the beginning data of the queue with these eight items temporarily stored in the extraction data storage unit <NUM>. If at least one of these items is the same, the extraction data compression unit <NUM> sets the 33rd bit (data compression presence/absence flag C) of the extraction data individual header to <NUM>, and inserts the data compression position flag (<NUM> byte) immediately after the extraction data individual header (see <FIG>).

After inserting the data compression position flag (<NUM> byte), the extraction data compression unit <NUM> creates packet-based extraction data corresponding to the data type by setting the corresponding bits of the data compression position flag to <NUM> for items in which the value of the data temporarily stored in the extraction data storage unit <NUM> is the same as the beginning data of the queue without including the data of the items having the same value in the extraction data and setting the corresponding bit of the data compression position flag to <NUM> for items having different values while including the data of the items having different values.

At this time, the extraction data compression unit <NUM> performs the same processing as in the case where compression is not possible when there is no same item. If the beginning data of the queue is, for example, data output from the IP extraction unit <NUM>, this data does not include the RTP timestamp value. As described above, the extraction data compression unit <NUM> sets the corresponding bits of the data compression position flag to <NUM> for items that are not included depending on the data type.

Further, when the data length of the packet-based extraction data is equal to or less than the "maximum data length" indicated by the compression request received from the extraction data report packet transmitting unit <NUM>, the extraction data compression unit <NUM> outputs the packet-based extraction data to the extraction data report packet transmitting unit <NUM>, temporarily stores the items included in the beginning data of the queue among the eight items in the extraction data storage unit <NUM>, and discards the beginning data of the queue.

On the other hand, when the data length of the packet-based extraction data is larger than the "maximum data length" indicated by the compression request received from the extraction data report packet transmitting unit <NUM>, the extraction data compression unit <NUM> notifies the extraction data report packet transmitting unit <NUM> of the fact that the data cannot be output.

As described above, when a state where data can be output to the extraction data aggregation device <NUM> as an "extraction data report packet" is created, the extraction data report packet transmitting unit <NUM> outputs "compressibility information," "maximum data length", and "reception time (timestamp value of received PTP based on reception of beginning data illustrated in <FIG>)" to the extraction data compression unit <NUM> as compression request information, and requests the extraction data compression unit <NUM> to output "packet-based extraction data" serving as a transmission target.

This compressibility information is "non-compressible" when the data request to the extraction data compression unit <NUM> which is a request destination is the first request after the extraction data report packet transmitting unit <NUM> transmits the extraction data report packet to the extraction data aggregation device <NUM>, and is "compressible" when the data request is the second request.

The maximum data length is the difference between a predetermined maximum payload length of the extraction data report packet and the sum of the data length of the packet-based extraction data that the extraction data report packet transmitting unit <NUM> has already acquired from the respective extraction data compression unit <NUM>.

Further, if the extraction data report packet transmitting unit <NUM> has not yet acquired the packet-based extraction data that can be transmitted to the extraction data aggregation device <NUM>, the "reception time" of the packet-based extraction data at the beginning of the extraction data report packet is a value indicating the effect (for example, "-<NUM>"). If there is already the packet-based extraction data that can be transmitted, the "reception time" is the reception time of the beginning data.

The extraction data report packet transmitting unit <NUM> outputs the extraction data report packet to the extraction data aggregation device <NUM> when a predetermined time has elapsed after receiving the notification that extraction is not possible from the extraction data compression unit <NUM> or acquiring the beginning data.

As illustrated in <FIG>, the extraction data report packet receiving unit <NUM> of the extraction data aggregation device <NUM> illustrated in <FIG> includes the extraction data restoration unit <NUM> and the extraction data storage unit <NUM>.

Upon receiving the extraction data report packet from the packet data extraction device <NUM> according to the present embodiment, the extraction data restoration unit <NUM> reads the extraction data common header and the packet-based extraction data from the extraction data report packet, executes a process of restoring the extraction data when the data is compressed, and outputs the execution result to the extraction data aggregation unit <NUM>.

More specifically, when the 33rd bit (data compression presence/absence flag C) of the extraction data individual header of the packet-based extraction data in the received extraction data report packet is <NUM>, first, the extraction data storage unit <NUM> stores items included in the packet-based extraction data among the "source MAC address", "destination MAC address", "source IP address", "destination IP address", "source L4-port number", "destination L4-port number", "RTP timestamp value," and "RTP SSRC" in the extraction data storage unit <NUM> using the device ID and the reception port ID as a key.

Subsequently, when the 33rd bit (data compression presence/absence flag C) of the extraction data individual header of the packet-based extraction data is <NUM>, the extraction data storage unit <NUM> reads items in which the data compression presence/absence flag C is <NUM> among the "source MAC address", "destination MAC address", "source IP address", "destination IP address", "source L4-port number", "destination L4-port number", "RTP timestamp value", and "RTP SSRC" using the device ID and the reception port ID as a key and complements the packet-based extraction data. After this complementation, the extraction data storage unit <NUM> stores the items included in the packet-based extraction data among the eight items in the extraction data storage unit <NUM>, and outputs the packet-based extraction data after processing and the extraction data common header to the extraction data aggregation unit <NUM>.

According to the packet flow monitoring device <NUM> of the third embodiment configured as described above, in addition to the effects of the first embodiment, further, in addition to the effects of the second embodiment, it is possible to efficiently transmit a packet flow composed of a large number of IP packets having the same IP address and port number and the like, like MPTE ST <NUM>, for example, to the extraction data aggregation unit <NUM>.

With respect to the examples of the above-described embodiments, a computer may be configured to function as the packet data extraction device <NUM> or the extraction data aggregation device <NUM>. Specifically, the functions of the packet data extraction device <NUM> or the extraction data aggregation device <NUM> can be realized by causing a central processing unit (CPU) in the computer to read and execute a program stored in the computer or an external storage unit. Further, the program for realizing the functions of the packet data extraction device <NUM> or the extraction data aggregation device <NUM> can be configured as a part of the software on the OS used in the computer. Further, the program for realizing the functions of the packet data extraction device <NUM> or the extraction data aggregation device <NUM> can be recorded and carried on a computer-readable recording medium. Further, the functions of the packet data extraction device <NUM> or the extraction data aggregation device <NUM> can be configured as a part of hardware or software, and can be realized by a combination thereof.

Although the present invention has been described by way of examples of specific embodiments, the present invention is not limited to the examples of the above-described embodiments, and various modifications can be made without departing from the technical idea. For example, in the above-described example of the third embodiment, the data compression related to the RTP extraction data has been described as a representative example. However, when the data compression related to the extraction data of another packet type (data type) is performed, the data compression presence/absence flag and the data compression position flag can be similarly utilized.

Further, in the example of the above-described embodiment, an example of monitoring the packet flow in the program production system for transmitting video or the like by applying the packet flow monitoring device according to the present invention has been described, but the present invention can be applied to any video or audio communication system. That is, the packet flow monitoring device according to the present invention can be configured as a device for monitoring packet flow in a video or audio communication system constructed by an Ethernet (registered trademark) or IP packet network. Therefore, the present invention is not limited to the examples of the above-described embodiments, but is limited only by the scope of claims.

Claim 1:
A packet flow monitoring device (<NUM>) that monitors packet flow in a video or audio communication system constructed by an Ethernet (registered trademark) or IP (Internet Protocol) packet network, comprising:
a packet data extraction device (<NUM>) that replicates all passing packets that pass through one or a plurality of specific network switches on the network and extracts and aggregates some predetermined pieces of information in the replicated passing packets to form and output an extraction data report packet; and
an extraction data aggregation device (<NUM>) that receives the extraction data report packet, analyzes the extraction data report packet so as to aggregate the some predetermined pieces of information in the replicated passing packets included in the extraction data report packet for each packet flow, and records the aggregated information as aggregation data, wherein
the extraction data report packet is composed of IP-format packets having a variable length within a range not exceeding a predetermined packet length,
an IP header and a UDP header for performing transmission between the packet data extraction device (<NUM>) and the extraction data aggregation device (<NUM>), an extraction data common header composed of items common to the aggregated, replicated passing packets, and packet-based extraction data composed of items individually extracted for the replicated passing packets are assigned to the extraction data report packet, and
the packet-based extraction data is configured such that an extraction data individual header indicating information for identifying the extracted, replicated passing packets and extraction data that stores the some predetermined pieces of information in the extracted, replicated passing packets are paired with each other, wherein
the extraction data common header includes a value indicating a reception time of beginning data of the replicated passing packet in each packet flow,
the extraction data individual header includes a passing packet length indicating a length of the replicated passing packet, a data type indicating a packet type of the replicated passing packet, and elapsed time information indicating a temporal difference from the beginning data described in the extraction data common header, and
the packet type includes a value that identifies at least Ethernet (registered trademark), IP, and RTP (Real-time Transport Protocol).