JP5526723B2 - Large-capacity data distribution system for narrowband networks - Google Patents

Description

  The present invention relates to a large-volume data distribution technique for distributing large-volume data such as a plurality of video streams from a broadband network such as an optical fiber network to a narrow-band network such as a micro network. The present invention can be applied, for example, to a video distribution system in which high-rate media information such as a video stream flows from a broadband network at a time in a configuration in which a broadband network and a narrowband network are connected at a plurality of locations.

  In a river video management network managed by the Ministry of Land, Infrastructure, Transport and Tourism, etc., a video distribution system that collects camera videos and the like at many points through a broadband network has been constructed. Such a network needs to collect important camera images and the like in the event of a disaster. For this reason, a narrow-band network constituted by a microwave network or the like is required as a final redundant path having a meaning as a backup line when a failure occurs in the broadband network.

  As the current usage situation, only a data system and a voice system can communicate from a broadband network to a narrow band network, and video is regulated because of the narrow band. For this reason, the bandwidth on the narrow-band network is surplus and is not effectively used. However, originally, video information should be necessary only in case of emergency, and a technique for flowing video information from a broadband network to a narrowband network is required. In this case, it is impossible to use a narrow-band network in terms of bandwidth with the same usage method (video of the same rate) as a broadband network such as an optical network. For this reason, a function for realizing video shaping in the entire narrowband network is required.

On the premise of the background more than the prior art related to the inflow control to the narrowband network, there are the following techniques as the prior art for performing the inflow control from the wideband network to the narrowband network.

  The total capacity of the video stream transmitted from one broadband network to the narrowband network to be connected needs to flow without exceeding the bandwidth capacity of the narrowband network. Therefore, a router apparatus such as a layer 3 switch (hereinafter referred to as an “L3 switch”) or a layer 2 switch (hereinafter referred to as an “L2 switch”) or the like is fixed to a specific stream before video information flows into the narrowband network. Restricted (destroyed). Thus, a conventional technique for reducing the number of video streams transmitted to a narrowband network is known.

  Also known is a prior art of an apparatus called an auto transcoder that automatically transcodes (decodes / encodes) a video stream (multicast) flowing through a network to lower the transfer rate of the video stream.

Prior Art Related to Control of Entire Narrow Band Network Next, there are the following techniques as conventional techniques for controlling the entire narrow band network.
Since the narrow-band network is used for the backup line, the video distribution system needs to be aware of redundant switching of the network, and it is necessary to reduce the number of distribution streams when switching to the backup line. Therefore, a conventional technique is known in which video stream filtering is set in the L3 switch or the L2 switch, and the number of inflows is fixedly limited to the narrowband network.

In addition, a conventional technique is known in which an arbitrary video stream flows into a narrowband network by converting a multicast address into a specific permitted address.
In addition, for a video stream at one inflow point from a broadband network to a narrowband network, one group of auto transcoders consisting of multiple units is used to limit the inflow amount to a low rate in order (first-come-first-served basis). A conventional technique for converting to a video stream is known.

Prior Art Related to Stream Selection Next, as the prior art for selecting a stream flowing from a wideband network to a narrowband network, there are the following techniques.
A conventional technique is known in which a specific video stream is fixedly or manually selected by a filtering function in an L2 switch or an L3 switch.

Further, there is known a conventional technique in which a specific video stream is selected by an L2 switch or an L3 switch by setting definition data from a server.
Furthermore, a conventional technique for reserving a transcode of a specific video stream by priority control setting in an auto transcoder is known.

Prior Art for Ensuring Reliability As a prior art for ensuring reliability in connection between a broadband network and a narrowband network, there are the following technologies.

  In the video stream (multicast) transmitted from the broadband network to the narrowband network, the inflow location to the narrowband network changes depending on the path change situation, and the inflow point of each video stream may be indefinite. In consideration of such a case, a conventional technique is known in which a stream is filtered redundantly by a plurality of L2 switches or L3 switches.

  Also, a conventional technique is known in which a stream is filtered redundantly by a plurality of L2 switches or L3 switches in consideration of a failure of the L2 switch or L3 switch.

JP 2005-184387 A JP 2002-84525 A JP-A-11-225168

Problems related to inflow control to narrowband network Problems related to the prior art for performing inflow control from a wideband network to a narrowband network include the following points.

  When filtering is performed with the L2 / L3 switch between the broadband network and the narrowband network, there is a problem that the number of video streams that can flow through the narrowband network becomes extremely small. For example, 400 video streams of 6 Mbps (megabits / second) can flow through a 2.4 Gbps (gigabit / second) optical network, but only 6 video streams of 6 Mbps can flow through a 52 Mbps micronetwork (narrowband network).

  Further, the conventional auto transcoder transcodes only 4 streams of 6 Mbps MPEG2 (Moving Picture Experts Group 2) in one group, so that the use efficiency of the narrowband network is poor.

To increase the number of incoming video streams, simply lower the video rate with the transcoder,
Further, in the conventional auto transcoder that lowers the transfer rate of the video stream, the multicast address is converted. For this reason, there has been a problem that there is a risk of inconsistency with the management information of the video distribution (switching) system (differing from the registered contents of the video switching server database), and failure of the video distribution system may occur. .

Issues related to control of the entire narrowband network Problems related to the prior art for controlling the entire narrowband network include the following.

  When a large number of video data flows from a wideband network to a narrowband network at a plurality of locations, it is necessary to manage the amount of inflow at the plurality of locations. In the case of controlling the video that flows dynamically, it is necessary to manage the current video stream in real time, and there is a problem in that it takes time to obtain the video selection status from the video management server.

  In addition, if a redundant configuration is built on the broadband network side, it is not known from which group the video stream will flow, so it is necessary to set the filter to the L2 / L3 switch before all groups, and management is complicated Had the problem of becoming.

  In addition, if a filter setting is made so that only a specific video stream flows so that the video flows only within the bandwidth of the narrow-band network, the narrow-band network is switched off when the permitted video stream does not flow. It had a problem that it could not be used effectively.

  Further, consider a case where a video stream rate conversion device such as an auto transcoder is installed at the entrance of a narrowband network and the rate conversion is performed unconditionally. In this case, since each autotranscoder transcodes independently of each other, there is a problem that it is impossible to control the inflow amount in a plurality of groups.

Problems related to stream selection The following are the problems of the prior art for selecting a stream flowing from a broadband network to a narrowband network.

  When the redundant configuration is adopted on the broadband network side, it is not known from which point of the narrowband network the video stream flows. For this reason, when performing the filtering setting in the L2 / L3 switch, there is a problem that the same setting must be made in all of the L2 / L3 switches at a plurality of entrances to the narrowband network.

For the same reason, when the redundant configuration is adopted for the other connection devices, there is a problem in that it is necessary to make the same setting for all the devices constituting the redundancy.
In addition, the current autotranscoder can convert the transfer rate of the video stream, but cannot flow important video into the narrowband network with high image quality. Accordingly, there has been a problem that rate switching (image quality switching) is not possible, such as monitoring an image with a high image quality by selecting an important image while viewing a low rate image.

  Furthermore, when the auto transcoder is used, MPEG2 multicast other than the video stream being transcoded is discarded, and thus there is a problem that high-quality video cannot be received.

Issues related to ensuring reliability The following are the problems of the prior art for ensuring reliability in the connection between a broadband network and a narrowband network.

In the case where a redundant configuration is adopted with an L3 switch in consideration of the inflow and failure of video streams from a plurality of locations, there is a problem that the cost increases.
Further, in the configuration using the auto transcoder, when a failure occurs in the auto transcoder, the high-traffic MPEG2 video stream flows as it is to the narrowband network, which may cause a bandwidth overflow of the narrowband network. When such a situation occurs, there is a problem in that packet dropout may occur in all video streams flowing through the narrowband network.

  Further, when the video stream is detoured to the narrow band network, consider a case where the narrow band network is divided and QoS (Quality of Service) control is performed therein. In this case, there is a problem in that the bandwidth may be exceeded at the moment when the narrowband network is restored from the division, and the entire video stream may be affected.

  As described above, the problem of the inflow control of a large amount of data such as a video stream from the broadband network to the narrowband network is as follows. In other words, in a control where the available bandwidth allocated to the inflow location is fixed and transcoding of multiple streams is simply performed, there is a possibility that the allocated bandwidth will be insufficient or wasted in an environment where the inflow location may be biased. It had the problem that it cannot be denied.

In addition, in order to perform inflow control by a router device such as an L2 / L3 switch, there is a problem that it is necessary to set all the routers.
Therefore, in one aspect of the present invention, without setting inflow control in the router, based on the usable bandwidth of the entire narrowband network, an available bandwidth is assigned to each inflow location, and large-capacity data is transcoded. The purpose is to allow inflow. In addition, preferably, the specified video data is allowed to flow in at a high rate.

In one example, the present invention is realized as a large-capacity data distribution system that distributes a plurality of large-capacity data from a broadband network to a narrow-band network, and has the following configuration.
First, a rate conversion device that performs rate conversion of large-capacity data is mounted, and a rate conversion control device that controls the rate conversion device is connected in multiple stages to form a group that takes in inflow of large-capacity data from a broadband network.

The rate conversion control device includes the following units.
First, the transcoding control unit, when it cannot rate-convert large-capacity data by its own rate conversion control device, in order to rate-convert the large-capacity data by another rate conversion control device in the same group, Control to make data transparent.

The transmission information management unit performs control to transmit specified large-capacity data without performing rate conversion by all rate conversion control devices in the group.
The intra-group information management unit exchanges and sets the control state of the transcode control unit and the transmission information management unit as its own group transcode status information with other rate conversion control devices in the group.

With the multistage connection configuration of the rate conversion control device, it is possible to control so that large-capacity data such as a video stream flowing into the narrowband network does not exceed the bandwidth.
In addition, it is possible to provide high-quality video by passing specified large-capacity data through a narrow band at the original rate.

  Furthermore, information on the rate conversion status and the amount of large-capacity data flowing into the narrowband network is shared among each group and among a plurality of groups, so that each rate conversion control device within a group and between groups can cooperate. In addition, it is possible to perform inflow control to a narrow band.

  Furthermore, the redundant configuration of the rate conversion control device enables a spare transcoder to take over the state and transcode even if one system goes down.

1 is an overall system configuration diagram of an embodiment. It is a figure which shows the connection form of an auto transcoder. It is a functional block diagram of an auto transcoder. It is an operation | movement flowchart which shows the master selection process at the time of starting common to all the nodes. It is an operation | movement flowchart which shows the master selection information response process at the time of operation common to all the nodes. It is an operation | movement flowchart which shows the MC data reception process at the time of operation common to all the nodes. It is an operation | movement flowchart (the 1) which shows the control operation of a sub main master node. It is an operation | movement flowchart (the 2) which shows the control operation of a sub main master node. It is an operation | movement flowchart (the 3) which shows the control operation of a sub main master node. FIG. 10 is an operation flowchart (part 4) illustrating a control operation of the sub-main master node. FIG. 10 is an operation flowchart (No. 5) showing the control operation of the sub-main master node. FIG. 10 is an operation flowchart (No. 6) showing a control operation of a sub-main master node. FIG. FIG. 10 is an operation flowchart (No. 7) showing a control operation of a sub-main master node. FIG. It is an operation | movement flowchart (the 1) which shows the control operation of a slave node. It is an operation | movement flowchart (the 2) which shows the control operation of a slave node. 12 is an operation flowchart (part 3) illustrating a control operation of the slave node. FIG. 10 is an operation flowchart (part 4) illustrating the control operation of the slave node. FIG. FIG. 10 is an operation flowchart (part 5) illustrating the control operation of the slave node. FIG. It is an operation | movement flowchart (the 1) which shows the control operation of a main master node. It is an operation | movement flowchart (the 2) which shows the control operation of a main master node. 12 is an operation flowchart (part 3) illustrating a control operation of the main master node. It is a figure which shows the data structural example of a group common definition file. It is explanatory drawing of each parameter of a group common definition file. It is a figure which shows the data structural example of own group transcode status information and own group traffic inflow information. It is a figure which shows the data structural example of an own group management table. It is a figure which shows the data structural example of a priority (emergency) table. It is a figure which shows the example of a data structure of the interruption | blocking (discard) table. It is a figure which shows the data structural example of a transparent table. It is a figure which shows the data structural example of the transcoding status information between groups.

Hereinafter, embodiments for carrying out the present invention will be described in detail with reference to the drawings.
FIG. 1 is an overall system configuration diagram of the embodiment.
The broadband side L3 (Layer 3) switch (denoted as “L3SW” in the figure) 103 connected to the broadband network 106 has rate conversion that operates as five slave devices # 1 to # 5 that normally function as slave devices. An auto transcoder 101, which is a control device, is connected vertically. Also, the autotranscoder 101 of # 5 is connected to one autotranscoder 101 that normally operates as a master device and a standby system. The autotranscoder 101 is connected to a narrowband L3 switch (denoted as “μL3SW” in the figure) 104 connected to the narrowband network 107. Each autotranscoder 101 can be connected to up to four transcoders 102 as rate conversion devices. Each transcoder 102 converts one video stream flowing from the camera 105 on the broadband network 106 side via the broadband L3 switch 103 into a transfer rate from MPEG2 to MPEG4. The transfer rate of MPEG2 is, for example, 6 Mbps, and the transfer rate of MPGE4 is, for example, 26 kbps (kilobits / second) to 519 kbps. Therefore, one auto transcoder 101 can convert the rate of up to four video streams. The above-described six auto transcoders 101 including five slave devices # 1 to # 5 and one master device, and a group of transcoders 102 connected to each of them are one group of a narrowband network connection. Form. In one narrowband network connection group, the rate conversion of up to 20 video streams can be performed by the five auto transcoders 101 operating as the active system.

  In FIG. 1, four narrowband network connection groups are connected to one wideband L3 switch 103 in the wideband network 106 and one narrowband L3 switch 104 in the narrowband network 107, respectively. Therefore, in the case of FIG. 1, it is possible to perform rate conversion on a video stream of up to 20 × 4 groups = 80 flowing from each camera 105 on the broadband network 106 side and to flow into the narrowband network 107. Become. The bandwidth of the narrowband network 107 is, for example, 48 Mbps.

  In FIG. 1, the Web maintenance terminal 108 can control each auto transcoder 101 by a Web interface via the wideband side L3 switch 103 or the narrowband side L3 switch 104.

  As shown in FIG. 2, each auto transcoder 101 in the group is connected to a main line 202 connecting one broadband L3 switch 103 and one narrowband L3 switch 104 via a switch box 201. Connected. During normal operation, the switch box 201 captures the video stream flowing in from the main line 202 into the auto transcoder 101 and causes the transcoder 102 under its control to execute rate conversion processing, as indicated by the normal path 203. On the other hand, when a failure occurs in the auto transcoder 101, the switch box 201 disconnects the connection to the auto transcoder 101 and passes the signal on the main line 202 to the subsequent auto transformer as indicated by the failure path 204. The light is transmitted through the coder 101.

The schematic operation of the embodiment having the above configuration will be described below.
First, an outline of control within a group will be described.

Intra-group transcoding control As described above, in one narrowband network connection group, six auto transcoders 101 are connected in series (in series) by the switch box 201 (FIG. 2).

  At the time of system startup, one master device and five slave devices are determined in the group in order to share information within the group. In addition, five active devices and one standby device are determined. In the example of FIG. 1, # 1 to # 5 autotranscoders 101 are assigned to the slave device / active device, and the remaining one autotranscoder 101 is assigned as the master device / standby device. These assignments can be dynamically changed independently of the master device / slave device and the active / standby system depending on the operation state.

In the following description, the auto transcoder 101 may be referred to as a node, the master device may be referred to as a master node, and the slave device may be referred to as a slave node.
Each auto transcoder 101 in the group exchanges priority (node priority) with other auto transcoders 101 in the group, and selects a master device.

  The master device manages the number of transcode processes of the slave device. The master device notifies the conversion rate (number of video streams) to the slave device. The slave device periodically notifies the master device of the transcoding status as its own group transcoding status information (see FIGS. 3 and 24 described later). Notification processing executed between the master device and the slave device is called a health check. The master device monitors the amount of MPEG4 traffic flowing in from the broadband network 106 and counts the amount of traffic flowing into the narrowband network 107.

  The master device executes health check processing on the slave device at intervals of 2 seconds, for example. Through the health check, information in the own group management table (transcode information) (see FIGS. 3 and 25) described later is shared between the master device and the slave device.

  In the health check transmitted from the master device, information of the transcode management table 312 of all the auto transcoders 101 in the group is notified, and in the health check returned from the slave device, the own device (the slave device itself) Information of the transcode management table 312 is notified.

The transcoding of the video stream within the group is executed in order from the node 1 (# 1 auto-transcoder 101 in FIG. 1), and the video stream that cannot be transcoded by one node is transferred to the next node. .
If the master device goes down, another slave device transitions to the master device.

Intra-group priority control In the present embodiment, a video stream to be preferentially transferred from the broadband network 106 to the narrowband network 107 can be designated. Control for this is priority control. This control is set and executed for each group.

  The priority control can be set from the group common definition file 310 (see FIGS. 3, 22, and 23) and the Web maintenance terminal 108. The setting in the group common definition file 310 is fixed, and the setting from the Web maintenance terminal 108 can be set dynamically.

When priority control is set by the Web maintenance terminal 108, the control is executed in the order of the Web maintenance terminal 108 → the master device → the intra-group auto transcoder 101.
In the priority control, the master device selects the auto transcoder 101 to which the priority control is applied, and issues a priority setting command to the selected auto transcoder 101. At this time, priority setting is performed in order from the autotranscoder 101 having the lowest node priority if the transcoder 102 has a free space.

  When the auto transcoder 101 under priority control goes down, the master device sets the priority setting set in the down auto transcoder 101 to the other auto transcoder 101.

  Each autotranscoder 101 checks the priority table every 0.5 seconds, discards the priority stream of the autotranscoder 101 located upstream (broadband network 106 side) from its own device, Transcoding is performed, and the priority stream of the downstream auto transcoder 101 is transferred (transmitted).

Intra-group specific MPEG2 transmission control In this embodiment, a specific MPEG2 wideband video stream flowing from the wideband network 106, for example, a stream such as a helicopter TV video, can be transmitted to the narrowband network 107 side without rate conversion. The control for that is specific MPEG2 transparency control. This control is set and executed for each group.

The specific MPEG2 transparency control can be fixedly set by the group common definition file 310 (see FIGS. 3, 22, and 23).
For example, a 6 Mbps video stream band designated for transmission is statically secured even if it does not actually flow.

Intra-group specific MPEG2 / 4 blocking control In this embodiment, a specific MPEG2 or MPEG4 video stream flowing from the broadband network 106 can be blocked. Control for that is specific MPEG2 / 4 blocking control. This control is set and executed for each group.

  The specific MPEG2 / 4 blocking control can be set from the group common definition file 310 (see FIGS. 3, 22, and 23) and the Web maintenance terminal 108. The setting in the group common definition file 310 is fixed, and the setting from the Web maintenance terminal 108 can be set dynamically.

Intra-group traffic inflow control In this embodiment, control is performed to grasp the traffic inflow of an MPEG2 / 4 video stream passing through a group.

An inflow threshold value can be set for each group. The inflow amount threshold value can be set in the group common definition file 310 (see FIGS. 3, 22, and 23). The threshold value of the inflow amount is set to a default value in the group common definition file 310 definition file, and then a new threshold value adjusted between groups is dynamically set.
When the traffic inflow amount exceeds the threshold, the excess traffic is blocked.

More than sharing transcode information between groups is the outline of control within the group. Next, an outline of control between groups will be described.

In the control between groups, first, transcoding information is shared.
One of the master devices in the plurality of groups operates as a main master device.
The main master device collects transcoding status, inflow information, etc. from a representative node (sub-main master device) of each group as a part of inter-group transcoding status information 317 (see FIGS. 3 and 29). The main master device distributes inter-group transcode status information 317 regarding all groups to the sub-main master devices of each group by the health check function (inter-group status information notification / response yesterday). Thereby, each group can share transcoding information and the like of the entire system.

  Also, the main master device collects MC address setting information that allows the autotranscoder 101 to be transmitted or blocked at 6 Mbps from each group as part of the inter-group transcoding status information 317 (see FIGS. 3 and 29). Share information between groups.

The inflow amount control main master device between the narrowband networks 107 between groups collects inflow amount information from the sub main master devices of each group in order to control the flow rate flowing into the narrowband network 107.

  The main master device refers to the inflow information of each group, and shifts (redistributes) the reserved bandwidth of the surplus group to the group that is likely to exceed the threshold, thereby adjusting the overall inflow amount and narrowband network 107 is used efficiently. Redistribution is performed by collecting information by health check processing and notifying information by health check processing. The information notification time is, for example, about 10 seconds.

  If the main master device cannot detect a sub-main master device of a group described in the group common definition file 310 (see FIGS. 3, 22, and 23), the reserved bandwidth cannot be adjusted with that group. Reserve the bandwidth. As a result, the bandwidth of the narrowband network 107 can be prevented from being exceeded even when the narrowband network 107 is recovered from ring division or the like.

  Specific processing functions of the embodiment that realizes the above-described schematic operation will be described in detail below.

  FIG. 2 is a functional configuration diagram of the auto transcoder 101 of FIG. The functions of the auto transcoder 101 include an MC data reception management unit 301, a transcode control unit 302, a transcode unit 303, an intra-group information management unit 304, an intra-group communication unit 305, an inter-group information management unit 306, and an inter-group communication unit. 307, the transparency / discard MC information management unit 308, and the Web screen control unit 309. The auto transcoder 101 also includes a group common definition file 310, received MC data management information 311, transcode management table 312, intra-group management information 313, priority (emergency) table 314, transparency table 315, and block (discard) table 316. Each information of the inter-group management information 317, the own group transcode status information 318, and the own group traffic inflow information 319 is managed.

  The control operation for realizing each of the functional units 301 to 309 is shown as processing in the operation flowcharts of FIGS. These processes are realized as an operation in which a central processing unit (not shown) executes a control program stored in a memory (not shown).

  FIG. 4 is an operation flowchart showing master selection processing at the time of activation, which is common to all the nodes (auto transcoder 101). This operation flowchart realizes a part of the function of the in-group information management unit 304 of FIG.

  First, a setting is made to transmit (through) all received multicast packets (hereinafter referred to as “MC”) to the filter function of the MC data reception management unit 301 (FIG. 3) in the device itself (step). S401).

  Next, to the node in the own group defined in the group common definition file 310 having the data configuration example shown in FIGS. 3, 22 and 23, the master is transmitted via the intra-group communication unit 305 in FIG. A selection information request (startup mode) is transmitted (step S402). Specifically, a master selection information request (startup mode) having a predetermined packet format with the IP address of each node indicated by CTL_NODE1 to CTL_NODE6 (see FIGS. 22 and 23) in the group common definition file 310 as the destination address Is sent.

  Next, a master selection information response waiting timer (start-up mode) is started (step S403). This timer is realized as a hardware timer or software timer (not shown).

  Next, it enters a waiting state as to whether or not a new information reception event has occurred via the intra-group communication unit 305 (step S404). During this time, when a master selection information response is received from any node, the identification information of the node that transmitted the response is recorded in a memory (not shown) as the source address of the packet corresponding to the response.

  After waiting for occurrence of an event for a predetermined time (step S404), the identification information of the node is checked to determine whether or not a master selection information response has been received from all nodes (step S405).

If the determination in step S405 is NO, it is determined whether or not the master selection information response wait timer (start-up mode) started in step S403 has timed out (step S406).
If the determination in step S406 is no, the process returns to step S404 and a new event waiting state is repeated.

  When the master selection information response is received from all nodes and the determination in step S405 is YES, or when the master selection information response waiting timer (start-up mode) times out and the determination in step S406 is YES, the following processing is executed.

First, the master selection information response waiting timer (startup mode) is terminated (step S407).
Next, based on the identification information of each node recorded in the memory in step S404, the priority information of the node that received the response from the group common definition file 310 is acquired, and the priority of each node is the priority of the own node. Comparison is made (step S408). Specifically, PRIORITY values (see FIGS. 22 and 23) for each node address in the group common definition file 310 are compared.

Then, it is determined whether or not the priority of the own node is the highest (step S409).
If the priority of the own node is the highest and the determination in step S409 is YES, the own node is transitioned to the operating state of the master device (step S410). Thereafter, the processing of the operation flowchart of FIG. 4 ends. The auto transcoder 101 that has transitioned to the operation state of the master device is shown in FIGS. 5, 6, 7 to 13 (both sub-main master device and main master device), and FIGS. 19 to 21 (main master device). Only) is executed.

  If the priority of the own node is not the highest and the determination in step S409 is NO, the own node is transitioned to the operating state of the slave device (step S411). Thereafter, the processing of the operation flowchart of FIG. 4 ends. The autotranscoder 101 that has transitioned to the operation state of the slave device executes the processing of the operation flowcharts of FIGS. 5, 6, and 14 to 18 described later.

  FIG. 5 is an operation flowchart showing master selection information response processing during operation, which is common to all nodes (autotranscoder 101). This operation flowchart realizes a part of the function of the in-group information management unit 304 of FIG.

First, it is determined whether or not a master selection information request has been received via the intra-group communication unit 305 in FIG. 3 (step S501).
If the determination in step S501 is NO, the operation in which the determination in step S501 is executed again after a predetermined time is repeated.

  If the determination in step S501 is YES, a master selection information response packet is returned to the source IP address of the received master selection information request packet (step S502). Thereafter, the process returns to the determination process in step S501.

  The node that transmitted the master selection information request in step S402 of FIG. 4 by the processing of the operation flowchart of FIG. 5 receives a master selection information response corresponding to the request from each node in step S404 of FIG. Can do.

  FIG. 6 is an operation flowchart showing a reception process of multicast data of a video stream during operation, which is common to all nodes (auto transcoder 101). This operation flowchart realizes a part of the function of the MC data reception management unit 301 of FIG.

First, it is determined whether or not multicast data (MC) has been received (step S601).
If the determination in step S601 is NO, the operation in which the determination in step S601 is executed again is repeated.

  If the determination in step S601 is YES, the first 64 bytes of the i-picture part of the received MPEG2 data are copied to a reception queue in the memory (not shown) (step S602). Thereafter, the process returns to the determination process in step S601.

The auto transcoder 101 can receive the MPEG2 data of the video stream by the processing of the operation flowchart of FIG.
7 to 13 are operation flowcharts showing the control operation of the auto transcoder 101 that operates as a sub-main master device (node).

  First, an intra-group health check timer, an inter-group health check timer, a main selection information request transmission timer, and an MC data reception check timer are started (step S701). These timers are realized as hardware timers or software timers (not shown).

Next, it enters a waiting state as to whether or not a new information reception event has occurred (step S702).
Subsequently, the processing of steps S703 to S709 is performed when a node set with a higher priority than that of its own node is activated and transitions to the master device, and a health check is transmitted (see step S802 in FIG. 8). It is a process to show. This process realizes a part of the function of the in-group information management unit 304 in FIG.

First, it is determined whether a health check has been received (step S703).
If the determination in step S703 is YES, the own group transcoding status information 318 in the own device is updated with the own group transcoding status information 318 included in the received packet (step S704).
Next, with reference to the updated own group transcoding status information 318 and the group common definition file 310, the priority of the own node and the newly activated node are compared (step S705).

Then, it is determined whether or not the priority of the own node is the highest (step S706).
If the determination in step S706 is YES, the state of the master device is maintained (step S707). Thereafter, the process returns to the event standby process in step S702.

  On the other hand, if the determination in step S706 is NO, a health check response is transmitted (step S708). At this time, the own group transcode status information 318 of the own node is notified.

After that, the slave device transits to the operation state (step S709), and the processing of the operation flowchart of FIG.
If the determination in step S703 is NO, it is next determined whether a transcode setting request has been received (step S710).

  If the determination in step S710 is yes, the following steps S711 and S712 are executed. These processes realize part of the function of the transcode control unit 302 in FIG.

First, the following setting is executed for the multicast data (MC) designated by the received transcode setting request (step S711).
(A) When transcoding is specified in a node upstream from the node itself (node on the broadband network 106 side), the following settings are made. That is, the filter function of the MC data reception management unit 301 is set so that MPEG2 data with the same multicast address is discarded and MPEG4 data with the same multicast address is transmitted.

  (B) When transcoding is specified in a downstream node (node on the narrowband network 107 side) from the own node, the following settings are made. That is, a setting is made so that both the MPEG2 data and the MPEG4 data having the same multicast address are transparent to the filter function of the MC data reception management unit 301.

  (C) When transcoding is specified at the own node, the following settings are made. In other words, the filter function of the MC data reception management unit 301 is set to transfer MPEG2 data having the same multicast address to the transcoder 102 unit (see FIG. 3) of the designated port from # 1 to # 4. The

  Thereafter, a transcode setting response is transmitted to the node (self) that transmitted the transcode setting request (step S712). Thereafter, the process returns to the event standby process in step S702.

  Next, when the determination in step S710 is NO, the operation flowchart of FIG. 8 is obtained, and it is determined whether or not the intragroup health check timer set in step S701 of FIG. 7 has timed out. (Step S801).

  If the determination in step S801 is YES, the following series of processing from step S802 to S804 is executed. This process realizes a part of the function of the in-group information management unit 304 in FIG.

  First, a health check is transmitted to all slaves (step S802). At this time, the own group transcoding status information 318 (see FIG. 24) of all nodes in the group is notified.

Next, the intra-group health check timer is reset (step S803).
Thereafter, a health check response timer is started (step S804). This timer is realized as a hardware timer or software timer (not shown). Thereafter, the process returns to the event standby process in step S702 of FIG.

  If the determination in step S801 is NO, it is determined whether a response to the health check transmitted in step S802 has been returned (step S805).

  If the determination in step S805 is YES, the following series of processing from step S806 to S808 is executed. This process realizes a part of the function of the in-group information management unit 304 in FIG.

First, the own group transcode status information 318 in the own device is updated with the own group transcode status information 318 included in the received response packet (step S806).
Next, it is determined whether the health check response has been received from all the slave nodes (step S807).

If the determination in step S807 is NO, the process returns to the event standby process in step S702 of FIG.
If the determination in step S807 is YES, the health check response timer is terminated (step S808). Thereafter, the process returns to the event standby process in step S702 of FIG.

  If the determination in step S806 is NO, it is determined whether the intragroup health check response timer set in step S804 has timed out (step S809).

  If the determination in step S809 is YES, the following series of processing from step S810 to S814 is executed. This process realizes a part of the function of the transcode control unit 302 of FIG.

First, it is determined whether or not the node for which the health check response has timed out has multicast data (MC) being transcoded (step S810).
If the determination in step S810 is no, the process returns to the event standby process in step S702 of FIG.

  If the determination in step S810 is YES, by referring to the transcode management table 312 (see FIGS. 3 and 25), an idle node (autotransform) that can newly transcode the multicast data determined in step S810. The coder 101) (X) and its subcoder 102 (Y) are searched (step S811).

  Next, for the multicast data determined in step S810 (hereinafter referred to as designated MC), a transcode setting request having the following setting contents is created (step S812).

  (A) For the node upstream of the node (X) (the node on the broadband network 106 side), a setting is required to transmit both MPEG2 data and MPEG4 data of the designated MC.

  (B) For the node downstream from the node (X) (the node on the narrowband network 107 side), the MPEG2 data of the designated MC is discarded and a setting for transmitting the MPEG4 data of the designated MC is requested.

  (C) The node (X) is requested to transfer MPEG2 data of the designated MC to the transcoder 102 (see FIG. 3) of the port corresponding to the transcoder (Y) among # 1 to # 4. To do.

Next, it is determined whether there is any other multicast data (MC) determined in step S810 (step S813).
If the determination in step S813 is YES, steps S811 and S812 are further executed to create a transcode setting request corresponding to the multicast data.

  If the determination in step S813 is NO, the created one or more transcode setting requests are transmitted to each slave device (step S814). Thereafter, the process returns to the event standby process in step S702 of FIG.

  Next, when the determination in step S809 described above is NO, the operation flowchart of FIG. 9 is obtained, and a transcode start request for predetermined multicast data (MC) has been received from the Web maintenance terminal 108 of FIG. It is determined whether or not (step S901).

  If the determination in step S901 is YES, the following series of processing from step S902 to S904 is executed. This process realizes a part of the function of the in-group information management unit 304 in FIG.

  First, as in the case of step S811 in FIG. 8, by referring to the transcode management table 312 (see FIGS. 3 and 25), an idle node (autotranscoder) that can transcode designated multicast data. 101) (X) and the transcoder 102 (Y) under its control are searched (step S902).

  Next, for the multicast data determined in step S902 (hereinafter referred to as designated MC), a transcode setting request having the same setting contents as in step S812 of FIG. 8 is created (step S903).

Then, the created transcode setting request is transmitted to each slave device (step S904). Thereafter, the process returns to the event standby process in step S702 of FIG.
Next, when the determination in step S901 described above is NO, the operation flowchart of FIG. 10 is obtained, and it is determined whether or not the MC data reception check timer started in step S701 of FIG. 7 has timed out. (Step S1001).

  If the determination in step S1001 is YES, the following steps S1002 to S1017 and steps S1101 to S1111 in FIG. 11 are executed. This process realizes some functions of the MC data reception management unit 301, the transcode control unit 302, the intra-group information management unit 304, and the transparency / discard MC information management unit 308 in FIG.

First, the reception queue on the memory updated in step S602 in FIG. 6 is polled (step S1002).
Next, it is determined whether or not packets are stored in the reception queue (step S1003).

If the determination in step S1003 is NO, the process returns to the event standby process in step S702 of FIG.
If the determination in step S1003 is YES, the packet is taken from the reception queue (step S1004).

  Next, it is determined whether or not the priority (emergency) table 314 of FIG. 3 has a priority multicast data (MC) address setting (step S1005). A data configuration example of the priority (emergency) table 314 is shown in FIG. The “PrMCAdd” field in this table is checked.

If the determination in step S1005 is NO, the process proceeds to step S1014.
If the determination in step S1005 is YES, it is determined whether or not the priority MC address is entered in the own group management table (step S1006). The own group management table is managed as a part of the own group transcoding status information 318 as shown in FIG. The own group management table has a data configuration example shown in FIG. 25, and includes a transcode management table 312, intra-group management information 313, and received MC data management information 311.

If the determination in step S1006 is YES, the own group management table setting is retained as it is (step S1007).
If the determination in step S1006 is NO, it is determined whether or not a priority MC address entry can be added to the own group management table, that is, whether or not there is a free entry (step S1008).

If the determination in step S1008 is NO, the entry of the youngest port in the own group management table is deleted (step S1009).
If the determination in step S1008 is YES or after the process in step S1009,
First, as in the case of step S811 in FIG. 8, by referring to the transcode management table 312 (see FIGS. 3 and 25), an idle node (autotranscoder 101) (transcoder 101) that can transcode the priority MC ( X) and subordinate transcoders 102 (Y) are searched (step S1010).

  Next, for the multicast data corresponding to the priority MC (hereinafter referred to as “designated MC”), a transcode setting request having the same setting contents as in step S812 in FIG. 8 is created (step S1011).

Thereafter, the priority MC entry to be transcoded is added to the transcode management table 312 (see FIG. 25) (step S1012).
Then, the created transcode setting request is transmitted to each slave device (step S1013). Thereafter, the process returns to the event standby process in step S702 of FIG.

  If the determination in step S1005 is NO or after the processing in step S1007, it is determined whether or not the blocking multicast data (MC) address is set in the blocking (discarding) table 316 in FIG. S1014). A data configuration example of the blocking (discarding) table 316 is shown in FIG. The “BlockMCAdd” field in this table is checked.

If the determination in step S1014 is NO, the process proceeds to step S1016.
If the determination in step S1014 is YES, an entry for blocking MC is added to the own group management table (see FIG. 25). Then, a discard registration notification is transmitted to the slave device. Also, the filter function of the MC data reception management unit 301 of the own node is set to discard the blocked MC packet (step S1015). Thereafter, the process returns to the event standby process in step S702 of FIG.

  If the determination in step S1014 is NO, it is determined whether or not the transparent table 315 in FIG. 3 has a transparent multicast data (MC) address setting (step S1016). An example of the data structure of the transparency table 315 is shown in FIG. The “ThroughMCAdd” field in this table is checked.

  If the determination in step S1016 is YES, a transparent MC entry is added to the own group management table (see FIG. 25). Then, a transparent registration notification is transmitted to the slave device. Further, the filter function of the MC data reception management unit 301 of the own node is set to transmit the transparent MC packet (step S1017). Thereafter, the process returns to the event standby process in step S702 of FIG.

  Next, if the determination in step S1016 is NO, that is, if the received multicast data (MC) is not a priority MC, a blocked MC, or a transparent MC, the process proceeds to the operation flowchart of FIG.

First, the own group management table (see FIG. 25) is searched using the MC address acquired in step S1004 of FIG. 10 as a search key (step S1101).
As a result of this search, it is determined whether or not the acquired MC address is in the own group management table (step S1102).

  If the determination in step S1102 is YES, the time stamp field “TimeStamp” of the transcode management table 312 in the own group management table is updated (step S1103). Thereafter, the process returns to the event standby process in step S702 of FIG.

If the determination in step S1102 is NO, it is determined whether or not there is a vacancy in the transcode state of the device itself (step S1104).
If the determination in step S1104 is YES, a transcode start instruction signal is output to the transcode unit 303 in which a vacancy is detected (step S1105).

  Subsequently, an instruction is issued from the transcoding unit 303 to the MC data reception management unit 301, and multicast data (MC) transfer setting is made to the transcoder connection port corresponding to the transcoding unit 303 (step S1106).

Further, a transcode start / stop command is issued from the transcode unit 303 to the transcoder 102 (step S1107).
Then, the transcoding unit 303 updates and reflects the command response result and transcoding state acquired from the transcoder 102 in the own group management table (FIG. 25) (step S1108). Thereafter, the process returns to the event standby process in step S702 of FIG.

  If the determination in step S1104 is NO, a transcode setting request having the same setting contents as in step S812 of FIG. 8 is created for multicast data corresponding to the processed MC (hereinafter referred to as designated MC). (Step S1109).

Thereafter, the entry of the MC to be transcoded is added to the transcode management table 312 (see FIG. 25) (step S1110).
Then, the created transcode setting request is transmitted to each slave device (step S1111). Thereafter, the process returns to the event standby process in step S702 of FIG.

  Next, when the determination in step S1018 is NO, the operation flowchart of FIG. 12 is obtained, and it is determined whether or not the main selection information request timer started in step S701 of FIG. 7 has timed out. (Step S1201).

  If the determination in step S1201 is YES, the following steps S1202 and S1203 are executed. This process realizes a part of the function of the inter-group information management unit 306 in FIG.

  First, a main selection information request is transmitted to the node having the highest priority of each group defined in the group common definition file 310 (see FIGS. 22 and 23) (step S1202).

  Next, the main selection information response timer is started (step S1203). This timer is realized as a hardware timer or software timer (not shown). Thereafter, the process returns to the event standby process in step S702 of FIG.

If the determination in step S1201 is NO, it is determined whether a main selection information request has been received (step S1204).
If the determination in step S1204 is YES, the following process in step S1205 is executed. This process realizes a part of the function of the inter-group information management unit 306 in FIG.

  That is, the priority of the own node is returned via the inter-group communication unit 307 (step S1205). The own group transcoding status information 318 is also notified. Thereafter, the process returns to the event standby process in step S702 of FIG.

If the determination in step S1204 is NO, it is determined whether a main selection information response has been received (step S1206).
If the determination in step S1206 is YES, the following processes in steps S1207 to S1213 are executed. These processes realize some functions of the inter-group information management unit 306 in FIG.

  First, from the main selection information response received via the inter-group communication unit 307, the priority of the transmission source node and the own group transcoding status information 318 of the group to which the transmission source node belongs are acquired, and the inter-group transcoding is performed. The status information 317 is set (step S1207).

Thereafter, it is determined whether or not there is a response from all nodes (step S1208).
If the determination in step S1208 is no, the process returns to the event standby process in step S702 of FIG.

If the determination in step S1208 is YES, the main selection information response timer is terminated (step S1209).
Next, the priority of the node that transmitted the main selection information response is compared with the priority of the own node (step S1210).

Then, it is determined whether or not the priority of the own node is the highest (step S1211).
If the determination in step S1211 is YES, the state transits to the operation state of the main device (step S1212), and the processing of the operation flowcharts of FIGS.

  On the other hand, if the determination in step S1211 is NO, the sub-main apparatus transitions to the operating state (maintains the current state) (step S1213), and then returns to the event standby process in step S702 of FIG.

  If the determination in step S1206 is NO, it is determined whether or not the main selection information response timer started in step S1203 has timed out (step S1214).

  If the determination in step S1214 is YES, the same processing as in steps S1209 to S1213 described above is executed. These processes realize some functions of the inter-group information management unit 306 in FIG.

  In this case, even if the main selection information response is not obtained from all the nodes, the transition to the main master device or the sub-main master device is executed using the priority of the node obtained up to now. (Steps S1214 → S1209 to S1213).

  Next, if the determination in step S1214 of FIG. 12 is NO, the operation flowchart of FIG. 13 is obtained, and it is determined whether an intergroup health check has been received via the intergroup communication unit 307. (Step S1301).

  If the determination in step S1301 is YES, the following series of processing from step S1302 to S1305 is executed. This process realizes a part of the function of the inter-group information management unit 306 in FIG.

First, the priority of the main master device and the priority of the own node are compared (step S1302).
Then, it is determined whether or not the own node has a higher priority (step S1303).

  If the determination in step S1303 is YES, a transition is made to the operating state of the main master device (step S1304). Thereafter, the processing of the operation flowcharts of FIGS.

If the determination in step S1303 is NO, a health check response is transmitted to the main master device (step S1305).
Thereafter, the inter-group health check timer is reset (step S1306), and the process returns to the event waiting process in step S702 of FIG.

  If the determination in step S1301 is NO, it is determined whether the intergroup health check timer started in step S701 in FIG. 7 has timed out (step S1307).

  If the main master device fails and the inter-group health check is not received and the determination in step S1307 is YES, the following series of processing from step S1308 to S1314 is executed. These processes realize some functions of the inter-group information management unit 306 in FIG.

First, it is determined whether or not the QoS maximum value (allowable amount) of the own group remains the default value (step S1308).
If the determination in step S1308 is yes, the process proceeds to step S1312.

If the determination in step S1308 is NO, the QoS maximum value is returned to the default value (step S1309).
Next, an entry of multicast data other than the priority multicast data and the transparent setting multicast data is selected and deleted from the transcode management table 312 (step S1310).

Next, it is determined whether or not the narrowband inflow amount of the own group is within the QoS maximum value (step S1311).
If the determination in step S1311 is NO, the process returns to step S1310 to further delete the multicast data entry.

If the determination in step S1311 is YES, a stop instruction is issued to the other node by a transcode request for the deleted multicast data (step S1312).
Then, the main selection information request is transmitted to the master device of each group (step S1313).
Thereafter, the inter-group health check timer is reset (step S1306), and the process returns to the event waiting process in step S702 of FIG.

  14 to 18 are operation flowcharts showing the control operation of the auto transcoder 101 operating as a slave device (node).

First, a health check reception timer is started (step S1401). This timer is realized as a hardware timer or software timer (not shown).
Next, it enters a waiting state as to whether or not a new information reception event has occurred (step S1402).

Subsequently, the processing in steps S1403 to S1409 realizes a part of the function of the in-group information management unit 304 in FIG.
First, it is determined whether a health check has been received (step S1403).

If the determination in step S1403 is YES, the health check reception timer is terminated (step S1404).
Next, the own group transcode status information 318 in the own device is updated with the own group transcode status information 318 included in the received packet (step S1405).
Next, by referring to the updated own group transcoding status information 318 and the group common definition file 310, the priority of the own node and the newly activated node are compared (step S1406).

Then, it is determined whether or not the priority of the own node is the highest (step S1407).
If the determination in step S1407 is YES, the operation state of the master device is transitioned (step S1408). The process of the operation flowchart of FIG. 14 ends.

  On the other hand, if the determination in step S1407 is NO, a health check response is transmitted (step S1409). At this time, the own group transcode status information 318 of the own node is notified.

Thereafter, the current operation state of the slave device is maintained, and the process returns to step S1401.
If the determination in step S1403 is NO, the process proceeds to the operation flowchart of FIG. 15 to determine whether the health check reception timer has timed out (step S1501).

  If the determination in step S1501 is YES, the following steps S1502 to S1505 are executed. These processes realize some functions of the in-group information management unit 304 of FIG.

  First, the own group transcoding status information 318 and the group common definition file 310 are referred to, and the priority of the own node is compared with the priority of the active node (step S1502).

As a result, it is determined whether or not the priority of the own node is the highest (step S1503).
If the determination in step S1503 is YES, the operation state of the master device is transitioned (step S1504).

If the determination in step S1503 is NO, the operating state of the slave device is maintained (step S1505). Thereafter, the process returns to step S1401 in FIG.
If the determination in step S1501 is NO, the process proceeds to the operation flowchart of FIG. 16, and it is determined whether a transcode setting request is received (step S1601).

  If the determination in step S1601 is YES, the following steps S1602 and S1603 are executed. These processes realize some functions of the transcode control unit 302 of FIG.

  First, on the basis of the transcode setting request, settings such as blocking / transmission are set for the filter function of the MC data reception management unit 301. Also, the own group transcode status information 318 is updated (step S1602).

  Next, the transcoding unit 303 specified by the transcode setting request is instructed to execute transcoding from MPEG2 to MPEG4 (step S1603). Thereafter, the process returns to the event waiting process in step S1402 of FIG.

  Next, if the determination in step S1601 is NO, the operation flowchart of FIG. 17 is obtained, and it is determined whether the MC data reception check timer started in step S1401 of FIG. 14 has timed out. (Step S1701).

  If the determination in step S1701 is YES, the following steps S1702 to S1711 and steps S1801 to S1808 in FIG. 18 are executed. This process realizes some functions of the MC data reception management unit 301, the transcode control unit 302, the intra-group information management unit 304, and the transparency / discard MC information management unit 308 in FIG.

First, the reception queue on the memory updated in step S602 in FIG. 6 is polled (step S1702).
Next, it is determined whether or not packets are accumulated in the reception queue (step S1703).

If the determination in step S1703 is NO, the process returns to step S1401 in FIG.
If the determination in step S1703 is YES, the packet is taken from the reception queue (step S1704).

  Next, it is determined whether or not the priority (emergency) table 314 in FIG. 3 has a priority multicast data (MC) address setting (step S1705). A data configuration example of the priority (emergency) table 314 is shown in FIG. The “PrMCAdd” field in this table is checked.

If the determination in step S1705 is no, the process proceeds to step S1708.
If the determination in step S1705 is YES, it is determined whether or not the priority MC address is entered in the own group management table (see FIG. 25) (step S1706).

If the determination in step S1706 is NO, the process proceeds to step S1708.
If the determination in step S1706 is YES, the own group management table setting is retained as it is (step S1707).

  If the determinations in steps S1705 and S1706 are NO, or after the processing in step S1707, is it determined whether or not the blocking multicast data (MC) address is set in the blocking (discarding) table 316 in FIG. (Step S1708). A data configuration example of the blocking (discarding) table 316 is shown in FIG. The “BlockMCAdd” field in this table is checked.

If the determination in step S1708 is no, the process proceeds to step S1710.
If the determination in step S1708 is YES, an entry for blocking MC is added to the own group management table (see FIG. 25). Then, the filter function of the MC data reception management unit 301 of the own node is set to discard the blocked MC packet (step S1711). Thereafter, the process returns to the event waiting process in step S1402 of FIG.

  If the determination in step S1708 is NO, it is determined whether or not the transparent table 315 in FIG. 3 has a transparent multicast data (MC) address setting (step S1710). An example of the data structure of the transparency table 315 is shown in FIG. The “ThroughMCAdd” field in this table is checked.

  If the determination in step S1710 is YES, a transparent MC entry is added to the own group management table (see FIG. 25). Then, the filter function of the MC data reception management unit 301 of the own node is set to transmit the transparent MC packet (step S1711). Thereafter, the process returns to the event waiting process in step S1402 of FIG.

  Next, if the determination in step S1710 is NO, that is, if the received multicast data (MC) is not a priority MC, a blocked MC, or a transparent MC, the process proceeds to the operation flowchart of FIG.

First, the own group management table (see FIG. 25) is searched using the MC address acquired in step S1704 of FIG. 17 as a search key (step S1801).
As a result of this search, it is determined whether or not the acquired MC address is in the own group management table (step S1702).

  If the determination in step S1102 is NO, a transcode setting request is transmitted to the master device (step S1809). Thereafter, the process returns to the event waiting process in step S1402 of FIG.

  If the determination in step S1102 is YES, the time stamp field “TimeStamp” of the transcode management table 312 in the own group management table is updated (step S1803).

Next, it is determined whether or not transcoding is set for the node (step S1804).
If the determination in step S1804 is YES, the transcoding process is continued and the process returns to the event waiting process in step S1402 of FIG.

If the determination in step S1804 is NO, a transcode start instruction signal is output to the transcode unit 303 in which a vacancy is detected (step S1805).
Subsequently, an instruction is issued from the transcoding unit 303 to the MC data reception management unit 301, and multicast data (MC) transfer setting to the transcoder connection port corresponding to the transcoding unit 303 is performed (step S1806).

Further, a transcode start / stop command is issued from the transcode unit 303 to the transcoder 102 (step S1807).
Then, the transcode unit 303 updates and reflects the command response result and transcode state acquired from the transcoder 102 in its own group management table (FIG. 25) (step S1808). Thereafter, the process returns to the event waiting process in step S1402 of FIG.

FIGS. 19 to 21 are operation flowcharts showing the control operation of the auto transcoder 101 that operates as a main master device (node).
First, an inter-group health check transmission timer is started (step S1901).

Next, it enters a waiting state as to whether or not a new information reception event has occurred (step S1902).
Subsequently, the processing in steps S1903 to S1905 realizes a part of the function of the inter-group information management unit 306 in FIG.

  First, it is determined whether or not the inter-group health check transmission timer has expired (step S1903).

  If the determination in step S1903 is YES, an intergroup health check is transmitted to the master of each group (step S1904). At this time, inter-group transcoding status information 317 is transmitted. As shown in FIG. 29, the inter-group transcoding status information 317 is information that is obtained by combining the group transcoding status information 318 of each group.

  Next, a health check response timer is started (step S1905). This timer is realized as a hardware timer or software timer (not shown). Thereafter, the process returns to the event waiting process in step S1902 of FIG.

If the determination in step S1903 is NO, the process proceeds to the process of the operation flowchart in FIG. 20, and it is determined whether a health check response has been received (step S2001).
If the determination in step S2001 is YES, the following series of processing from step S2002 to S2011 is executed. These processes realize some functions of the inter-group information management unit 306 in FIG.

First, it is determined whether or not the priority of the own node is the highest (step S2002).
Next, the inter-group transcode status information 317 is updated according to the content of the received health check response (step S2003).

  Next, it is determined whether or not the response content of the received health check response is an inflow amount exceeding a predetermined threshold (%) (step S2004). As the threshold value for each group, the current QoS threshold value (inflow rate threshold value) in the inter-group transcoding status information 317 illustrated in FIG. 29 is used.

If the determination in step S2004 is YES, it is determined whether or not there is a group with an inflow amount equal to or less than “threshold-adjustment rate” (step S2005).
If the determination in step S2005 is no, the process returns to the event standby process in step S1902 of FIG.

If the determination in step S2005 is YES, the group with the smallest inflow amount is extracted (step S2006).
Next, a health check for instructing to lower the threshold value of the extracted group is generated (step S2007).

On the other hand, if the determination in step S2004 is NO, it is determined whether or not there is a response to the health check including an instruction to lower the threshold (step S2008).
If the determination in step S2008 is no, step S2010 is executed.

If the determination in step S2008 is YES, a health check is generated that instructs the group (A) to increase the threshold by the amount that the threshold is decreased (step S2009).
After the process of step S2007 or S2009, it is determined whether or not there is a response from all masters (step S2010).

If the determination in step S2010 is no, the process returns to the event standby process in step S1902 of FIG.
If the determination in step S2010 is YES, the health check response timer is terminated (step S2011), and then the process returns to the event waiting process in step S1902 of FIG.

  If the determination in step S2001 described above is NO, the process proceeds to the process of the operation flowchart in FIG. 21, and it is determined whether the health check response timer started in step S1905 in FIG. 19 has timed out (step S2101).

  If the determination in step S2101 is YES, the following series of processing from step S2102 to S2112 is executed. These processes realize some functions of the inter-group information management unit 306 in FIG.

First, it is determined whether the time-out group has changed the QoS maximum value (step S2102).
If the determination in step S2102 is NO, the process returns to the event waiting process in step S1902 of FIG.

If the determination in step S2102 is YES, it is determined whether the time-out group has decreased the QoS maximum value (step S2103).
If the determination in step S2103 is YES, it is determined whether the QoS maximum value (allowable amount) of the own group remains the default value (step S2104).

If the determination in step S2104 is YES, the process proceeds to step S2109.
If the determination in step S2104 is NO, the QoS maximum value is returned to the default value (step S2105).

  Next, an entry of multicast data other than the priority multicast data and the transparent setting multicast data is selected and deleted from the transcode management table 312 (step S2106).

Next, it is determined whether or not the narrowband inflow amount of the own group is within the QoS maximum value (step S2107).
If the determination in step S2107 is NO, the process returns to step S2106 to further delete the multicast data entry.

  If the determination in step S2107 is YES, a stop instruction is issued to the node in the own group by a transcode request for the deleted multicast data (step S2108).

Thereafter, the transcode response timer is started, and the process returns to the event waiting process in step S1902 of FIG.
When the determination in step S2103 described above is NO, a process of increasing (returning to the default value) the QoS maximum value of the group that has been decreased by the amount corresponding to the increase of the QoS maximum value by the group that has timed out is executed (step S2103). Step S2110).

Next, inter-group transcoding status information 317 in which the QoS maximum value is reset is transmitted (step S2111).
Thereafter, the health check response timer is started (step S2112), and the process returns to the event waiting process in step S1902 of FIG.

  According to the embodiment described above, it is possible to control so that large-capacity data such as a video stream flowing into the narrowband network does not exceed the bandwidth by the multi-stage connection configuration of the autotranscoder.

In addition, it is possible to provide a high-quality video by passing a designated video stream or the like through a narrow band at the original rate.
In addition, information on the transcoding status and the amount of inflow into the narrowband network, such as video streams, is shared within each group and between multiple groups, so that each autotranscoder within and between groups collaborates. Inflow control to the narrow band can be performed.

Furthermore, the redundant configuration of the auto transcoder allows the spare auto transcoder to take over the state and transcode even if one system goes down.
In addition, when a clear video is required as a result of watching the monitor video, it is possible to perform control such that the transcode rate is increased and the narrowband network is passed through with priority.

  In addition, it is possible to control so that unnecessary video does not use the narrowband network.

101 Autotranscoder 102 Transcoder 103 Wideband L3 Switch 104 Narrowband L3 Switch 105 Camera 106 Wideband Network 107 Narrowband Network 108 Web Maintenance Terminal 201 Switch Box 301 MC Data Reception Management Unit 302 Transcode Control Unit 303 Transcode Unit 304 In-group information management unit 305 In-group communication unit 306 Inter-group information management unit 307 Inter-group communication unit 308 Transparent / discard MC information management unit 309 Web screen control unit 310 Group common definition file 311 Received MC data management information 312 Transcode management table 313 Intra-group management information 314 Priority (emergency) table 315 Transparent table 316 Blocking (discard) table 317 Inter-group transcoding De status information 317
318 Own group transcode status information 319 Own group traffic inflow information

Claims (4)

A Lud over data delivery system to deliver a multiple of data in the narrow-band network from a broadband network,
Before mounting the rate conversion apparatus which performs rate conversion of Kide over data form a group to take the inflow of pre Kide over data from multistage connection to the broadband network rate conversion controller for controlling the rate converter ,
The rate conversion control device is
If you can not rate conversion previous Kide over data in the own rate conversion controller, in order to rate convert 該De over data in other rate conversion control apparatus for the same of the group, control for transmitting 該De over data A transcode control unit for performing
The specified data, and transmitting information management unit for performing control to transmit without rate conversion in all rate conversion control apparatus in the group,
An intra-group information management unit that exchanges and sets the control status of the transcode control unit and the transmission information management unit as other group transcoding status information with other rate conversion control devices in the group;
Only including,
Each rate conversion control device in the group exchanges its own group traffic inflow information indicating an inflow state of data flowing from the group into the narrowband network through the intra-group information management unit, data distribution system of the narrowband network inflow of the data and controls so as not to exceed the allowable values specified for the group that flows into the narrowband network from a group. A plurality of groups formed by the multistage connected rate conversion control devices are formed between the broadband network and the narrowband network,
Each one of the plurality of rate conversion control devices in each group operates as a master device,
When the own device operates as the master device, the rate conversion control device converts the own group transcoding status information corresponding to the group to which the own device belongs to each rate conversion that operates as each master device in each other group. by replacing the transcoding status information between groups with the control device further includes inter-group information management unit to increase or decrease adjust the tolerance of the inflow amount before Kide over data between respective groups,
Data distribution system of the narrowband network according to claim 1, characterized in that. When a predetermined one of the rate conversion control devices connected in multiple stages in each group is a standby system device, the other rate conversion control device is an active system device, and the current rate conversion control device fails, The intra-group information management unit executes control in which the standby rate conversion control device takes over the rate conversion status of the failed rate conversion control device.
Data distribution system of the narrowband network according to claim 1 or 2, characterized in that. By connecting the standby rate conversion control device to the most downstream of the multi-stage connected rate conversion control device group, the high-speed conversion that has not been rate-converted when the active transcoding device fails. that remain data rate flows into the narrowband network, the spare system rate conversion control apparatus is prevented,
Data distribution system of the narrowband network according to claim 3, characterized in that.

Images