JP7373369B2 - In-building transmitter, in-building receiver and program - Google Patents

Description

The present invention relates to an in-building transmitting device, an in-building receiving device, and a program for providing IP (Internet Protocol) broadcasting services in cable television.

Conventionally, cable television has provided broadcasting services such as rebroadcasting of terrestrial and satellite broadcasting, multi-channel broadcasting, and communication services such as Internet connection and VOD (Video On Demand).

If the transmission path from the cable TV station (CATV station) to the subscriber's home (receiver's home) is an HFC (Hybrid Fiber Coaxial) transmission path, the transmission method for the broadcasting service is a transmodulation method that remodulates with 64QAM or 256QAM. used. Further, in the case of an FTTH (Fiber To The Home) transmission line, a pass-through method or the like is used.

On the other hand, in the case of communication services such as the Internet, a communication method such as the DOCSIS3.0 (Data Over Cable Service Interface Specifications 3.0) standard (see, for example, Non-Patent Documents 1 and 2) is used in the HFC transmission path. In the FTTH transmission path, communication methods such as G-EPON (Gigabit Ethernet Passive Optical Network) and 10G-EPON (10 Gigabit Ethernet Passive Optical Network) are used.

In recent years, cable television operators have also been considering IP broadcasting that provides broadcasting services by IP multicast by using communication equipment (for example, see Non-Patent Document 3). In addition, the new 4K8K satellite broadcasting that started in 2018 uses MMT (MPEG Media Transport) as a multiplexing method, and has a packet structure that assumes broadcasting and communication cooperation services or rebroadcasting over IP transmission channels. There is.

In cable television or IPTV, video services are becoming increasingly high-definition, and it is expected that multi-channel broadcasting that provides video at 2K resolution will shift to 4K8K in the future. Therefore, it is thought that 4K8K IP broadcasting services will use a communication system such as 10G-EPON, which has a transmission capacity of 10 Gbps, on an FTTH transmission line capable of wideband transmission instead of an HFC transmission line.

By the way, when a cable television operator converts a transmission line to an FTTH transmission line, it is relatively easy to convert the transmission line to an optical fiber transmission line up to each subscriber's house in a detached house. However, in apartment complexes, etc., the transmission lines within the building are outside the jurisdiction of the cable television operator, so it is difficult to optically connect the building to each subscriber's home.

Many of the transmission lines in buildings such as apartment complexes are only equipped with transmission lines such as coaxial cables or telephone lines, and there is no space to install new optical fibers, and the procedures for optical conversion construction are complicated. It is thought that it will take time and money.

Therefore, in order to provide communication services in apartment complexes, etc. where it is difficult to switch to optical fiber, the FTTH section up to the entrance of the building uses 10G-EPON communication method for IP transmission using optical fiber, and the inside of the building uses C-DOCSIS or local Means for IP transmission using the 5G communication system are being considered.

C-DOCSIS installs DOCSIS standard equipment, which has traditionally been used by cable operators for HFC transmission lines, in an MDF (Main Distribution Frame) room in an apartment complex, and uses coaxial cables to perform IP communications. (See Non-Patent Document 4).

Local 5G is a 5th generation mobile communication system installed in a limited area such as inside a building by a cable operator, etc., rather than by a national mobile carrier, and performs IP communication using wireless (non-patent technology). (see reference 5).

Both communication methods are currently being used or considered for Internet communication. In order to deliver video services such as 4K8K by IP multicast, there are issues such as how to guarantee bandwidth for multi-channel programs and how to take measures against packet loss.

In order to solve this problem, we developed an IP encapsulation method, which is a method that dynamically assigns an IP address for distribution to a selected program to a DOCSIS 3.0 standard device (DOCSIS transmission device) and transmits it. have been studied (see Non-Patent Document 6).

However, while prototyping and experimenting with a device using this IP encapsulation method, the following new implementation issues (1) and (2) became clear.
(1) Some DOCSIS transmission devices support an MTU (Maximum Transmission Unit) of only 1500 bytes. Therefore, when IP encapsulation is performed on a video signal packet, the IP packet length may exceed 1500 bytes.
(2) Some DOCSIS transmission devices support an MTU of up to 1500 bytes. Therefore, if AL-FEC (Application Layer-Forward Error Correction) is applied to video signal packets to prevent packet loss, the IP packet length will exceed 1500 bytes due to the FEC header. There are cases.

FIG. 14 is a diagram showing the format and size of an IP packet when a conventional IP encapsulation method or the like is used. The original IP packet shown in FIG. 14A is composed of an IPv6 header, a UDP header, an MMTP header, and video/audio/data, and has a structure in which the MMTP packet is encapsulated with the UDP header and the IPv6 header. The maximum length of this IP packet is 1500 bytes.

The IP encapsulated IP packet shown in FIG. 14(b) is composed of an IPv6 header, an IPv6 header, a UDP header, an MMTP header, and video/audio/data. This IP encapsulated IP packet has a structure in which the original IP packet shown in FIG. 14(a) is encapsulated with an IPv6 header. The IPv6 header length is 40 bytes, and the maximum length of an IP encapsulated IP packet is 1540 bytes.

The IP packet after AL-FEC (repair packet) shown in FIG. 14(c) is composed of an IPv6 header, a UDP header, an MMTP header, an FEC header, and an FEC payload. This repair packet is a packet that has been subjected to AL-FEC encoding using the Pro MPEG method. The FEC header length is 17 bytes, and the maximum length of the repair packet is 1517 bytes.

As shown in FIG. 14(b), when IP encapsulation is performed on an original IP packet, the IP packet length may exceed the MTU of 1500 bytes (issue (1) described above). Furthermore, as shown in Figure 14(c), when AL-FEC encoding is performed on the original IP packet, the IP packet length may exceed the MTU of 1500 bytes (issue (2) ).

Both of the above issues (1) and (2) require that the MTU handled by CMTS (Cable Modem Termination System) and CM (Cable Modem), which are DOCSIS transmission equipment, exceeds 1500 bytes. This is due to restrictions that cannot be changed.

When there is a restriction on the MTU in this way, normal IP communication is considered to be processed as follows. When using IPv6, the source node checks the MTU between routes in advance using the route MTU discovery protocol (RFC1191), and fragments the IP packet so that the packet length of the IP packet is less than or equal to the MTU. Send.

Furthermore, when using IPv4, the source node similarly uses the route MTU discovery protocol to reduce the packet length of the IP packet to less than or equal to MTU, or each node between the routes performs fragment processing to reduce the length of the IP packet. Change the packet length as appropriate. When IPv6 is used, fragment processing is not performed at intermediate nodes in order to reduce complicated processing at routers between routes.

In the case of IP rebroadcasting of new 4K8K satellite broadcasting, there are problems with these methods. First, the maximum IP packet length of the source node is 1500 bytes, and the operational regulations are set to broadcast using IPv6 (see Non-Patent Document 7, Volume 3 242p 5.5.5 Packet operational rules) ).

The simplest approach to solving this problem is to change the IP packet length in source mode to be smaller than 1500 bytes, such as 1400 bytes. However, with this method, it is difficult to change the settings of broadcasting equipment that is already in operation.

Furthermore, if the cable television station and receiver that are the source of the IP rebroadcast perform fragment processing, the cost associated with the fragment processing increases.

Furthermore, when fragment processing is performed on IP packets carrying MMT packets, one IP packet no longer corresponds to one MMT packet, and AL-FEC encoding such as Pro MPEG, which uses MMT sequence numbers, The decoding process becomes impossible (see Non-Patent Documents 8 and 9). In other words, when the MMTP header is divided into multiple IP packets by fragment processing, the order of the IP packets becomes unknown, making it impossible to perform FEC encoding processing using MMT.

When fragment processing is performed and AL-FEC encoding processing such as Pro MPEG is performed, it is necessary to add a new MMTP header and RTP header to the fragmented IP packet and write a sequence number. There will be waste.

In this way, in response to MTU constraints in DOCSIS transmission equipment, it is not possible to change the packet length at the source, and existing fragment processing increases costs, so a more efficient solution is desired. It had been.

CableLabs DOCSIS 3.0 specifications Yoshitake Osawa, “The beginning of the next generation CATV standard COCSIS 3.1”, [online], Net One System Co., Ltd., [searched on September 10, 2019], Internet <URL: https://www.netone. co.jp/report/column/column1/20150819a.html＞ “Current status of the cable industry and thoughts on IP broadcasting”, [online], Japan Cable Television Federation, [Retrieved September 10, 2019], Internet <URL: http://www.soumu.go. jp/main_content/000519215.pdf＞ “Japan Cable Lab Apartment Housing Communication High Speed Working Group Activities Status (C-DOCSIS)”, [online], Japan Cable Lab, General Incorporated Association, [Retrieved September 10, 2019], Internet <URL: http://www .jlabs.or.jp/archives/20344＞ “Local 5G Investigation Working Group Report Outline (Draft)”, [online], Ministry of Internal Affairs and Communications, General Communications Infrastructure Bureau, Radio Department, Mobile Communications Division, [Retrieved September 10, 2019], <Internet URL: http:// www.soumu.go.jp/main_content/000604240.pdf＞ Kusunoki et al., “Development and performance evaluation of in-building transmission equipment using DOCSIS standard for 4K/8K multi-channel IP broadcasting”, Institute of Image Information and Television Engineers Technical Report vol.43, no.17, BCT2019-48, 2019, p.1-4 Advanced Wideband Satellite Digital Broadcasting Operation Regulations ARIB TR-B39 1.2 version “Pro-MPEG Forum Code of Practice 3 Release 2”, Transmission of Professional MPEG-2 Transport Streams Over IP Networks ISO/IEC 23008-1, “High efficiency coding and media delivery in heterogeneous environments: MPEG media transport”

By introducing in-building transmission equipment such as DOCSIS transmission equipment, which performs IP encapsulation or AL-FEC encoding to guarantee bandwidth and prevent packet loss, into the in-building transmission system of cable TV apartment complexes, 4K and 8K multi-band transmission systems can be implemented. It is possible to realize intra-building transmission of channel broadcasts.

However, since the maximum packet length exceeds 1500 bytes, which is the MTU handled by the in-building transmission equipment, there is a problem that the in-building transmission equipment cannot be directly installed in the in-building transmission system of a cable TV apartment complex. was there.

Therefore, in order to realize intra-building transmission of 4K8K multi-channel broadcasting, a new method that does not require changing the maximum packet length or perform fragment processing and suppresses costs has been desired.

Therefore, the present invention has been made to solve the above problems, and its purpose is to prevent the maximum packet length from exceeding the MTU handled by the intra-building transmission equipment, eliminate the need for fragment processing, and support 4K8K multi-channel broadcasting. An object of the present invention is to provide an in-building transmitting device, an in-building receiving device, and a program that can realize intra-building transmission at low cost.

In order to solve the above problem, the in-building transmitting device according to claim 1 includes: an ONU (optical line terminal unit) installed in an MDF (main distribution frame) room, an in-building transmitting device, a first in-building transmitting device, It also consists of a second in-building transmission device, an in-building receiving device, an IP-STB (set-top box), and a TV (television) installed in each of a plurality of recipient homes, and transmits data from a CATV station via an FTTH transmission line. The intra-building transmitting device in the intra-building transmission system that transmits IP packets containing video signals distributed by IP multicast, the intra-building transmitting device including an IPv6 header containing a predetermined IPv6 address and an IPv4 address corresponding to the IPv6 header. A first memory in which an IP header conversion table consisting of a combination of headers is stored, and the IP header conversion table stored in the first memory are used to generate the information contained in the IP packet transmitted from the CATV station. a first IP header conversion processing unit that converts the IPv6 header into the IPv4 header and generates the IP packet having the IPv4 header, the IPv4 header generated by the first IP header conversion processing unit; The IP packet having the header is transmitted from the first intra-building transmission device to all the second intra-building transmission devices with guaranteed bandwidth using a predetermined bonding signal, and from the second intra-building transmission device, The present invention is characterized in that the video signal is transmitted to the in-building receiving device that has received a request to view the program.

The in-building transmitting device according to claim 2 is the in-building transmitting device according to claim 1, further comprising an IP header processing unit, and a program viewing request for the program tuned by a user at the recipient's house. is transmitted from the in-building receiving device to the in-building transmitting device via the second in-building transmitting device and the first in-building transmitting device, the IP header processing unit: Based on the IPv4 address that can be used to distribute the video signal, the transmission capacity for the program corresponding to the notification, and the remaining bandwidth for each bonding signal whose bandwidth is guaranteed, so as not to exceed the bandwidth of the bonding signal, determine the bonding signal and the IPv4 address to be actually used, generate a combination of the IPv6 header containing the IPv6 address of the program corresponding to the notification and the IPv4 header containing the IPv4 address as update data; Update data is added to the IP header conversion table stored in the first memory, and all intra-building transmission devices are added to the IP header conversion table stored in the first memory. It is characterized in that it is transmitted to a receiving device.

Further, the in-building transmitting device according to claim 3 is the in-building transmitting device according to claim 2, which further includes program transmission capacity information including transmission capacity for each program, transmission capacity for each bonding signal, and bandwidth guarantee. a second memory storing IPv4 address allocation information including an IPv4 address, remaining bandwidth, and an IPv6 address, IPv4 address, and distribution destination regarding the program being distributed; The usable IPv4 address is specified based on the bandwidth guarantee IPv4 address included in the stored IPv4 address allocation information and the IPv4 address related to the program being distributed, and is stored in the second memory. The transmission capacity of the program corresponding to the notification is acquired from the program transmission capacity information, the remaining bandwidth of the bonding signal is acquired from the IPv4 address allocation information, and the usable IPv4 address and the program are acquired. Based on the transmission capacity of the bonding signal and the remaining band of the bonding signal, the bonding signal to be actually used is determined so as not to exceed the band of the bonding signal, and the usable IPv4 for the bonding signal is determined. The method is characterized in that the IPv4 address to be actually used is determined from among the addresses.

Furthermore, the in-building receiving device according to claim 4 includes an ONU (optical line terminal unit) installed in an MDF (main distribution board) room, an in-building transmitting device and a first in-building transmitting device according to claim 1, and a plurality of in-building transmitting devices. It consists of a second in-building transmission device, an in-building receiving device, an IP-STB (set-top box), and a TV (television) installed in each of the recipient's homes. The intra-building receiving device in the intra-building transmission system that transmits IP packets including multicast video signals, which includes an IPv6 header containing a predetermined IPv6 address and an IPv4 header containing an IPv4 address corresponding to the IPv6 header. a third memory that stores an IP header conversion table that is the same as the IP header conversion table held by the in-building transmitter; The IPv6 header included in the packet is converted to the IPv4 header, and the IP packet having the IPv4 header is sent to the intra-building receiving device via the first intra-building transmission device and the second intra-building transmission device. When the IP packet is transmitted, the IPv4 header included in the IP packet is converted to the IPv6 header using the IP header conversion table stored in the third memory, and the IP packet having the IPv6 header is A second IP header conversion processing unit that generates an IP header.

Further, the in-building receiving device according to claim 5 includes an ONU (optical line terminal unit) installed in an MDF (main distribution board) room, an in-building transmitting device according to claim 2 or 3, and a first in-building transmitting device, It also consists of a second in-building transmission device, an in-building receiving device, an IP-STB (set-top box), and a TV (television) installed in each of a plurality of recipient homes, and transmits data from a CATV station via an FTTH transmission line. The intra-building receiving device in the intra-building transmission system that transmits IP packets including video signals distributed by IP multicast via a third memory storing an IP header conversion table that is the same as the IP header conversion table held by the transmitting device; and the IPv6 header included in the IP packet transmitted from the CATV station by the in-building transmitting device. is converted into the IPv4 header, and the IP packet having the IPv4 header is transmitted to the intra-building receiving device via the first intra-building transmission device and the second intra-building transmission device. , using the IP header conversion table stored in the third memory to convert the IPv4 header included in the IP packet to the IPv6 header, and generate the IP packet having the IPv6 header; When the IP header conversion processing unit and the user at the recipient's home request to view the selected program, the IPv6 address of the program is present in the IP header conversion table stored in the third memory. If it is determined that the IPv6 address of the program does not exist in the IP header conversion table, a notification of a program viewing request for the program tuned by the user at the recipient's home is output, and the A signal processing unit that transmits a notification to the intra-building transmission device via the second intra-building transmission device and the first intra-building transmission device, and the intra-building transmission device transmits the IPv6 When a combination of the header and the IPv4 header is generated as update data, and the update data is transmitted to the intra-building receiving device via the first intra-building transmission device and the second intra-building transmission device. The apparatus further comprises: an IP header conversion table updating section that adds the updated data to the IP header conversion table stored in the third memory.

Furthermore, the program according to claim 6 causes a computer to function as the in-building transmitting device according to any one of claims 1 to 3.

Moreover, the program according to claim 7 causes a computer to function as the in-building receiving device according to claim 4 or 5.

As described above, according to the present invention, the maximum packet length does not exceed the MTU handled by the intra-building transmission device, fragment processing is not required, and intra-building transmission of 4K8K multi-channel broadcasting is realized at low cost. becomes possible.

1 is a schematic diagram showing an example of the overall configuration of an in-building transmission system in an apartment complex including an in-building transmitting device and an in-building receiving device according to an embodiment of the present invention. FIG. 1 is a block diagram showing an example of the configuration of an in-building transmitter according to an embodiment of the present invention. FIG. 3 is a diagram showing an example of an IP header conversion table. 3 is a flowchart illustrating an example of processing by an IP header processing unit. FIG. 3 is a diagram showing an example of program transmission capacity information. FIG. 3 is a diagram showing an example of DOCSIS transmission capacity information. FIG. 3 is a diagram illustrating an example of IPv4 address assignment information. FIG. 1 is a block diagram showing a configuration example of an in-building receiving device according to an embodiment of the present invention. 3 is a flowchart illustrating an example of processing by a join signal processing unit. 7 is a diagram illustrating an operation when there is a request to view program 1. FIG. 7 is a diagram illustrating an operation when there is a request to view program 2 at another home (receiver's home 3-2) while program 1 is being viewed. FIG. 7 is a diagram illustrating an operation when there is a request to view program 1 at another house (receiver's house 3-3) while programs 1 and 2 are being viewed. FIG. FIG. 3 is a diagram illustrating a situation in which program 1 is viewed at recipient's homes 3-1 and 3-3, and program 2 is viewed at recipient's home 3-2. FIG. 2 is a diagram showing the format and size of an IP packet when a conventional IP encapsulation method or the like is used. FIG. 3 is a diagram showing the format and size of an IP packet when using an IP header conversion method according to an embodiment of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments for carrying out the present invention will be described in detail using the drawings. The in-building transmitter of the present invention converts an IPv6 header into an IPv4 header using an IP header conversion table for an IP packet containing a video signal transmitted from a CATV station, and transmits the IP packet having the IPv4 header. It is characterized by Further, the in-building receiving device of the present invention receives an IP packet transmitted from the in-building transmitting device via an in-building transmitting device conforming to the DOCSIS standard, and converts an IPv4 header into an IPv6 header using an IP header conversion table. It is characterized by converting.

The IP packet converted by the in-building receiving device is transmitted to an IP-STB (Set Top Box), and the video signal included in the IP packet is output to a TV (Television).

The IP header conversion table is composed of a combination of the IPv6 header of the program currently being viewed and the corresponding IPv4 header for distribution, and is dynamically changed according to the viewing status of the program.

The in-building transmitting device of the present invention is also applicable when performing AL-FEC encoding processing on IP packets, and the in-building receiving device of the present invention is applicable to AL-FEC encoding processing that corresponds to AL-FEC encoding processing. - It is also applicable when performing FEC decoding processing.

FIG. 15 is a diagram showing the format and size of an IP packet when using the IP header conversion method according to the embodiment of the present invention. The original IP packet shown in FIG. 15(a) has the same configuration as the original IP packet shown in FIG. 14(a), and the maximum length of the IP packet is 1500 bytes. Here, as shown in FIG. 14(b), the IPv6 header length is 40 bytes.

The IP packet after IP header conversion shown in FIG. 15(b) is composed of an IPv4 header, a UDP header, an MMTP header, and video/audio/data. The IPv4 header length is 20 bytes, and the maximum length of the IP packet after IP header conversion is 1480 bytes. This is because this IP packet has a structure converted from a 40-byte IPv6 header to a 20-byte IPv4 header.

The IP packet after AL-FEC (repair packet) shown in FIG. 15(c) is composed of an IPv4 header, a UDP header, an MMTP header, an FEC header, and an FEC payload. This repair packet is a packet in which AL-FEC is added to the IP packet after IP header conversion. The FEC header length is 17 bytes, and the maximum length of the repair packet is 1497 bytes.

As shown in Figure 15(b), when converting the IPv6 header to an IPv4 header for the original IP packet, the IP packet length becomes less than 1500 bytes, which is the MTU, and the above-mentioned problem (1) can be solved. . Furthermore, as shown in FIG. 15(c), even if AL-FEC encoding processing is performed on the IP packet after IP header conversion, the IP packet length will be less than 1500 bytes, which is the MTU, and the above-mentioned problem ( 2) can be solved.

In this way, the intra-building transmitter converts the IPv6 header into an IPv4 header using the IP header conversion table, so the maximum length of the IP packet does not exceed the MTU handled by the DOCSIS transmitter or the like. The same applies when performing AL-FEC encoding processing. In other words, the maximum packet length does not exceed the MTU handled by DOCSIS transmission equipment, etc., and fragment processing is not required, making it possible to realize intra-building transmission of 4K8K multi-channel broadcasting at low cost.

[In-building transmission system]
First, the intra-building transmission system will be explained. FIG. 1 is a schematic diagram showing an example of the overall configuration of an in-building transmission system in an apartment complex including an in-building transmitting device and an in-building receiving device according to an embodiment of the present invention.

This in-building transmission system 1 includes each device installed in the MDF room 2 in the apartment complex, each device installed in the receiver's house 3-1, ..., each device installed in the receiver's house 3-X. The device includes a signal branching device and a signal splitter 4. X indicates the number of recipient homes in the apartment complex and is a positive integer.

In the MDF room 2, an ONU (Optical Network Unit) 10, an in-building transmitter 11, and a CMTS 12 are installed.

In the recipient's house 3-1, a CM 20-1, an in-building receiving device 21-1, an IP-STB 22-1, and a TV 23-1 are installed. Similarly, a CM 20-X, an in-building receiving device 21-X, an IP-STB 22-X, and a TV 23-X are installed in the recipient's house 3-X.

The CMTS 12 installed in the MDF room 2 and the CMs 20-1, . . . 20-X installed in the recipient homes 3-1, . Connected by cable.

Hereinafter, the receiver's houses 3-1, ..., 3-X will be collectively referred to as receiver's house 3, the CM20-1, ...20-X will be collectively referred to as CM20, and the in-building receiving device 21-1. , . . , 21-X are collectively referred to as the in-building receiving device 21. Furthermore, the IP-STBs 22-1, . . . , 22-X are collectively referred to as IP-STB 22, and the TVs 23-1, . . . , 23-X are collectively referred to as TV 23.

4K/8K IP multicast signals using 10G-EPON are distributed from the CATV station via the optical fiber of the FTTH transmission line. The intra-building transmission system 1 receives IP packets containing video signals distributed by IP multicast from a CATV station.

The intra-building transmission system 1 converts the IPv6 header into an IPv4 header in the intra-building transmitting device 11 of the MDF room 2, and transmits the IP packet within the building via the DOCSIS transmission devices of the CMTS 12 and CM 20. Then, the in-building transmission system 1 converts the IPv4 header into an IPv6 header in the in-building receiving device 21 of the recipient's house 3, transmits the IP packet to the IP-STB 22, and outputs the video signal to the TV 23.

The ONU 10 receives an IP packet containing a video signal multicast distributed from a CATV station, and transmits the IP packet as an Ethernet (registered trademark) signal to the in-building transmitter 11. Further, when a new program viewing request is made by a user who is a recipient, the ONU 10 receives a join signal (multicast join signal) for the program viewing request from the in-building transmitter 11, and sends the join signal to the CATV. Send to station.

The in-building transmitter 11 receives the IP packet Ethernet signal from the ONU 10, and converts the IPv6 header into an IPv4 header using the IP header conversion table for the IP packet of the program being viewed on the TV 23 of the recipient's home 3. Performs IP header conversion processing. Then, the intra-building transmitter 11 performs AL-FEC encoding processing and transmits the Ethernet signal of the IP packet after the AL-FEC encoding processing to the CMTS 12.

Furthermore, when the user requests to view a new program, the in-building transmitting device 11 adds a new IPv6 header and a corresponding IPv4 header as update data to the IP header conversion table, and sends the updated data to the CMTS 12 and It is transmitted to the in-building receiving device 21 via the CM 20. Then, the in-building transmitter 11 receives the Join signal transmitted from the in-building receiver 21 via the CM 20 and the CMTS 12, and transmits the Join signal after the IP header conversion process to the CATV station via the ONU 10. . Details of the intra-building transmitter 11 will be described later.

The CMTS 12 receives an IP packet Ethernet signal from the in-building transmitter 11, modulates the Ethernet signal, and sends it to all CMs 20-1 as a DOCSIS standard RF (Radio Frequency) signal via the signal splitter 4 and coaxial cable. ~Send to 20-X. In this case, the IP packet transmitted from the CMTS 12 to all CMs 20 as a DOCSIS standard RF signal is an IP packet converted into an IPv4 header. Further, transmission parameters are set in the CMTS 12 and all CMs 20 so that this IP packet is preferentially transmitted using a bonding signal with a guaranteed band.

The CM 20 receives a DOCSIS standard RF signal from the CMTS 12, demodulates the RF signal, and transmits it to the in-building receiving device 21 as an IP packet Ethernet signal.

The in-building receiving device 21 receives the IP packet Ethernet signal from the CM 20 and performs AL-FEC decoding processing. Then, the in-building receiving device 21 performs an IP header conversion process on the Ethernet signal of the IP packet after the AL-FEC decoding process to convert the IPv4 header into the original IPv6 header using the IP header conversion table. The in-building receiving device 21 transmits the Ethernet signal of the IP packet after the IP header conversion process to the IP-STB 22 .

Here, the IP packet after the IP header conversion has returned to the same IP signal format as when a detached house receives a 4K/8K IP multicast signal from a CATV station via an optical fiber of an FTTH transmission line.

Further, when the user requests to view a new program, the in-building receiving device 21 transmits a notification of the new program viewing request to the in-building transmitting device 11 via the CM 20 and CMTS 12, and Receive update data for the IP header conversion table. Then, the in-building receiving device 21 transmits the join signal after the IP header conversion process to the in-building transmitting device 11 via the CM 20 and CMTS 12. Details of the in-building receiving device 21 will be described later.

The IP-STB 22 receives the IP packet Ethernet signal from the in-building receiving device 21, decodes the IP packet video signal, and outputs it to the TV 23 as a video signal in HDMI (registered trademark) format or the like.

[In-building transmitter 11]
Next, the in-building transmitter 11 shown in FIG. 1 will be explained in detail. FIG. 2 is a block diagram showing an example of the configuration of the in-building transmitter 11 according to the embodiment of the present invention. This in-building transmitter 11 includes input/output interfaces 30 and 36, an IP header conversion processing section 31, memories 32 and 34, an IP header processing section 33, and an AL-FEC encoding section 35.

The input/output interface 30 receives an IP packet containing a video signal from the CATV station via the ONU 10 using the IPv6 protocol. Then, the input/output interface 30 performs Ethernet input/output interface processing on the IP packet, and outputs the IP packet having an IPv6 header to the IP header conversion processing section 31 .

The input/output interface 30 also receives a join signal for a program viewing request from the IP header conversion processing section 31 . Then, the input/output interface 30 performs Ethernet input/output interface processing on the Join signal, and transmits the Join signal requesting program viewing to the CATV station via the ONU 10 using the MLDv2 protocol.

The IP header conversion processing unit 31 receives an IP packet having an IPv6 header from the input/output interface 30. Then, the IP header conversion processing unit 31 extracts an IPv4 header corresponding to the IPv6 header of the input IP packet from the IP header conversion table stored in the memory 32, and converts the IPv6 header of the IP packet into an IPv4 header. The IP header conversion processing unit 31 generates an IP packet having an IPv4 header, and outputs the IP packet having the IPv4 header to the AL-FEC encoding unit 35.

Further, the IP header conversion processing unit 31 inputs a Join signal for a program viewing request from the input/output interface 36, and extracts an IPv6 header corresponding to the IPv4 header of the input Join signal from an IP header conversion table stored in the memory 32. and converts the IPv4 header of the Join signal into an IPv6 header. The IP header conversion processing unit 31 generates a Join signal having an IPv6 header, and outputs the Join signal having the IPv6 header to the input/output interface 30.

Note that the value of the payload length of the IP packet differs for each IP packet. Therefore, the IP header conversion processing unit 31 calculates the payload length during the IP header conversion process, and stores the value of the payload length in a predetermined location of the IPv4 header or the IPv6 header. The same applies to the IP header conversion processing unit 42 in FIG. 8, which will be described later.

The memory 32 stores an IP header conversion table. The IP header conversion table is stored in the memory 32 by the IP header processing unit 33.

FIG. 3 is a diagram showing an example of an IP header conversion table. This IP header conversion table is composed of a combination of the IPv6 header of the program and the corresponding IPv4 header for distribution. The IPv6 header consists of a destination address that is an IPv6 address, a source address, and various header information, and the IPv4 header consists of a destination address that is an IPv4 address, a source address, and various header information.

In this example, the IP header conversion table includes an IPv6 header consisting of an IPv6 address ff02::1, etc., and an IPv4 header consisting of a corresponding IPv4 address 239.0.0.1, etc. The IP header conversion table also includes an IPv6 header consisting of an IPv6 address ff02::2, etc., and an IPv4 header consisting of a corresponding IPv4 address 239.0.0.11, etc.

Using this IP header conversion table, an IPv6 header of an IP packet is converted to a corresponding IPv4 header, and an IPv4 header of an IP packet is converted to a corresponding IPv6 header.

This IP header conversion table is dynamically updated in accordance with the notification of a new program viewing request from the in-building receiving device 21, and is stored in the memory 32 shown in FIG. 2, and is also stored in the memory 45 shown in FIG. is also stored. In other words, the IP header conversion table is for the in-building transmitting device 11 of the MDF room 2, the in-building receiving device 21-1 of the recipient's house 3-1, ... and the in-building receiving device 21 of the recipient's house 3-X. - They are synchronized at X and always match. The in-building transmitting device 11, the in-building receiving device 21-1, . . . , and the in-building receiving device 21-X hold IP header conversion tables with the same contents.

Note that the IPv6 header and the IPv4 header include a payload length. The payload length is calculated during the IP header conversion process as described above. Specifically, the payload length of the IPv4 header is calculated during the conversion process from the header IPv6 header to the IPv4 header, and the payload length of the IPv6 header is calculated during the conversion process from the header IPv4 header to the IPv6 header. Ru.

Returning to FIG. 2, the IP header processing unit 33 receives a notification of a new program viewing request from the input/output interface 36. Then, the IP header processing unit 33 uses the program transmission capacity information, DOCSIS transmission capacity information, and IPv4 address allocation information stored in the memory 34 to perform IP header conversion for the new program viewing request notification using an IP header allocation determination algorithm. Generate table update data.

The IP header processing unit 33 adds the updated data to the IP header conversion table stored in the memory 32 and outputs it to the input/output interface 36. Further, the IP header processing unit 33 updates the remaining bandwidth and the program information being distributed with respect to the IPv4 address allocation information stored in the memory 34. Details of the program transmission capacity information, DOCSIS transmission capacity information, and IPv4 address allocation information will be described later.

Note that, as shown in FIGS. 6 and 7, which will be described later, the IPv4 address allocation information includes DOCSIS transmission capacity information, so the IP header processing unit 33 does not necessarily need to use the DOCSIS transmission capacity information.

The IP header allocation decision algorithm sets in advance the available IPv4 addresses for distribution as IP addresses to which IP packets are preferentially transmitted in the CMTS 12, and selects a new one from among them so as not to exceed the bonding signal band. This is the process of determining the bonding signal and IPv4 address that will actually be used for program distribution.

FIG. 4 is a flowchart showing an example of processing by the IP header processing unit 33. The IP header processing unit 33 receives a notification of a new program viewing request from the input/output interface 36 (step S401). Then, the IP header processing unit 33 performs the following steps S402 to S409 using an IP header allocation determination algorithm.

The IP header processing unit 33 identifies usable IPv4 addresses using the IPv4 address allocation information stored in the memory 34 (step S402). Specifically, the IP header processing unit 33 obtains a bandwidth guaranteed IPv4 address, which is a bandwidth guaranteed IP address, and information on the program being distributed, for each bonding signal, from IPv4 address allocation information (see FIG. 7 described later). get. The IP header processing unit 33 identifies, as usable IPv4 addresses, addresses other than the IPv4 addresses included in the program information being distributed among the IPv4 addresses for bandwidth guarantee. In other words, the usable IPv4 address is an address that is not currently in use among the IPv4 addresses for bandwidth guarantee.

Note that, as described above, the IP header processing unit 33 may specify an available IPv4 address upon input of a notification of a new program viewing request, or may identify an available IPv4 address prior to inputting a notification of a new program viewing request. , usable IPv4 addresses may be specified in advance.

In the example of FIG. 7, which will be described later, for bonding signal 1, the IPv4 addresses for band guarantee are 239.0.0.1 to 239.0.0.10, and the IPv4 address included in the program information being distributed is 239. .0.0.1. Therefore, usable IPv4 addresses for bonding signal 1 are 239.0.0.2 to 239.0.0.10. Furthermore, regarding bonding signal 2, the IPv4 address for band guarantee is 239.0.0.11 to 239.0.0.20, and the IPv4 address included in the program information being distributed is 239.0.0.11. It is. Therefore, usable IPv4 addresses for bonding signal 2 are 239.0.0.12 to 239.0.0.20. Further, regarding bonding signal 3, the IPv4 address for band guarantee is 239.0.0.21 to 239.0.0.30, and there is no IPv4 address included in the program information being distributed. Therefore, usable IPv4 addresses for bonding signal 3 are 239.0.0.21 to 239.0.0.30.

Moving from step S402, the IP header processing unit 33 determines the IPv6 address of the program included in the notification of the new program viewing request from the program transmission capacity information stored in the memory 34 (see FIG. 5, which will be described later). The necessary transmission capacity is acquired (step S403).

The IP header processing unit 33 acquires the remaining bandwidth for each bonding signal from the IPv4 address assignment information (see FIG. 7 described later) (step S404).

The IP header processing unit 33 determines the band of the bonding signal based on the usable IPv4 address specified in step S402, the transmission capacity of the program obtained in step S403, and the remaining band for each bonding signal obtained in step S404. Determine the bonding signal actually used for distributing the program included in the notification of a new program viewing request so as not to exceed the IPv4 address actually used from among the available IPv4 addresses of the bonding signal. is determined (step S405).

The IP header processing unit 33 converts the data consisting of the IPv6 address of the program and various IPv6 header information included in the notification of the new program viewing request, the IPv4 address determined in step S405, and the various IPv4 header information into IP It is generated as update data for the header conversion table (step S406).

The IP header processing unit 33 adds the update data generated in step S406 to the IP header conversion table stored in the memory 32 (step S407), and outputs it to the input/output interface 36 (step S408).

As a result, the update data of the IP header conversion table is transmitted to all the in-building receiving devices 21 via the CMTS 12 and CM 20, and the IP header conversion table held in the in-building transmitting device 11 and all the in-building receiving devices 21 is updated. will be updated to the same data.

The IP header processing unit 33 updates the remaining bandwidth of the IPv4 address allocation information stored in the memory 34 and the program information being distributed (step S409).

Specifically, the IP header processing unit 33 subtracts the acquired program transmission capacity from the current remaining band of the bonding signal determined for notification of a new program viewing request regarding the IPv4 address allocation information, and uses the subtraction result as a new Update to the remaining bandwidth. Furthermore, regarding the IPv4 address allocation information, the IP header processing unit 33 adds the IPv6 address of the program included in the notification of the new program viewing request, the determined IPv4 address, and the distribution destination to the currently distributed program information corresponding to the bonding signal. information about recipient's house 3 is added.

Note that if the DOCSIS transmission devices of the CMTS 12 and CM 20 support only unicast transmission, the IP header processing unit 33 determines the IPv4 unicast address that corresponds to the IPv6 multicast address.

The memory 34 stores program transmission capacity information, DOCSIS transmission capacity information, and IPv4 address allocation information. Program transmission capacity information and DOCSIS transmission capacity information are set in advance, and IPv4 address allocation information is updated by the IP header processing unit 33.

FIG. 5 is a diagram showing an example of program transmission capacity information. This program transmission capacity information is composed of the IP broadcast program, the IPv6 address of the program, and the transmission capacity [Mbps] required for transmitting the video signal of the program.

In this example, the program transmission capacity information includes the IPv6 address ff02::1 of program 1 and the transmission capacity 100 [Mbps] required for program 1 as information about program 1. Also, as information on program 2, the IPv6 address ff02::2 of program 2 and the transmission capacity 100 [Mbps] required for program 2, ..., as information on program N, the IPv6 address ff02::N and The transmission capacity required for program N is 15 [Mbps]. N is a positive integer.

When a user selects a program from N types, the IP multicast signal transmitted from the CATV station is transmitted to the in-building receiving device 21 via the ONU 10, in-building transmitting device 11, CMTS 12, and CM 20. . In the example of program transmission capacity information shown in Figure 5, the transmission capacity required to transmit the video signal of the program is 100 Mbps for 8K video, 33 Mbps for 4K video, and 15 Mbps for 2K video. It is something.

This program transmission capacity information is stored in the memory 34 as preset information, and in accordance with notification of a new program viewing request from the in-building receiving device 21, the program, the IPv6 address of the program, and the transmission capacity required for the program are stored in the memory 34 as preset information. Used to obtain .

FIG. 6 is a diagram illustrating an example of DOCSIS transmission capacity information. This DOCSIS transmission capacity information is composed of a bonding signal that is a DOCSIS downlink signal, a transmission capacity [Mbps] of the bonding signal, and an IPv4 address that is an IP address for band guarantee.

The DOCSIS standard includes a method of performing IP communication between the CMTS 12 and CM 20 using only one bonding signal, and a method of performing IP communication using a plurality of bonding signals. In the latter case, since the CM 20 can only receive one bonding signal at a time, it performs an operation called DBC (Dynamic Bonding Change) to switch the bonding signals to be received.

In the embodiment of the present invention, it is assumed that the CM 20 switches the bonding signal received under the operation of the DBC depending on the program to be viewed. Furthermore, there are three bonding signals that are DOCSIS downlink signals, and the transmission capacity of each is assumed to be 160 Mbps. In the example of FIG. 6, ten IPv4 addresses for bandwidth guarantee are set for the bonding signal, which is a DOCSIS downlink signal, and the bandwidth is guaranteed and priority transmission is performed. These IP addresses correspond to destination addresses included in the converted IPv4 header when the IPv6 header of the IP packet is converted into an IPv4 header by the IP header conversion processing unit 31.

In the example of FIG. 6, the DOCSIS transmission capacity information includes, for bonding signal 1, its transmission capacity of 160 Mbps and 10 IPv4 addresses 239.0.0.1, ..., 239.0.0.10. . Furthermore, the bonding signal 2 includes a transmission capacity of 160 Mbps and ten IPv4 addresses 239.0.0.11, . . . , 239.0.0.20. Furthermore, the bonding signal 3 includes a transmission capacity of 160 Mbps and ten IPv4 addresses 239.0.0.21, . . . , 239.0.0.30.

This DOCSIS transmission capacity information is stored in the memory 34 as preset information. The DOCSIS transmission capacity information is created by the IP header processing unit 33 identifying usable IPv4 addresses in accordance with notification of a new program viewing request from the in-building receiving device 21, and selecting a program from among them so as not to exceed the band of the bonding signal. used to determine the IPv4 address of

FIG. 7 is a diagram showing an example of IPv4 address allocation information. This IPv4 address allocation information includes, in addition to the DOCSIS transmission capacity information shown in FIG. 6, the remaining bandwidth [Mbps] of the bonding signal and information on the program being distributed. The program information being distributed includes the program being distributed, the IPv6 address of the program, the IPv4 address used to distribute the program, and information on the recipient's home 3 at the distribution destination where the program is being received.

In this example, the IPv4 address allocation information includes information on the remaining bandwidth of 60 Mbps for bonding signal 1 and information on program 1 being distributed, and regarding bonding signal 2, information on the remaining bandwidth of 60 Mbps and information on program 2 being distributed. included. Further, in this example, information on bonding signal 3 does not exist.

The information about program 1 being distributed is that the IPv6 address of program 1 is ff02::1, the IPv4 address used for distributing program 1 is 239.0.0.1, and that program 1 is being received. This shows that the recipient homes currently located are recipient homes 3-1 and 3-3. In addition, the information about program 2 being distributed is that the IPv6 address of program 2 is ff02::2, the IPv4 address used for distribution of program 2 is 239.0.0.11, and program 2 is being received. This indicates that the recipient's home that is marked is recipient's home 3-2.

This IPv4 address allocation information is dynamically updated in accordance with notification of a new program viewing request from the in-building receiving device 21. The IPv4 address allocation information is determined by the IP header processing unit 33 identifying usable IPv4 addresses in accordance with notification of a new program viewing request from the in-building receiving device 21, and assigning a program from among them so as not to exceed the band of the bonding signal. used to determine the IPv4 address of

Returning to FIG. 2, the AL-FEC encoding unit 35 inputs an IP packet having an IPv4 header from the IP header conversion processing unit 31, and assigns FEC by performing AL-FEC encoding processing on the IP packet. do. Then, the AL-FEC encoding unit 35 outputs the IP packet having the IPv4 header subjected to the AL-FEC encoding process to the input/output interface 36. This takes measures against packet loss.

The input/output interface 36 inputs an IP packet having an IPv4 header subjected to AL-FEC encoding processing from the AL-FEC encoding unit 35. Then, the input/output interface 36 performs Ethernet input/output interface processing on the IP packet, and transmits the IP packet containing the video signal to the in-building receiving device 21 via the CMTS 12 and CM 20 using the IPv4 protocol. Specifically, this IP packet is transmitted to all CMs 20 via the CMTS 12, and from the CM 20 to the in-building receiving device 21 that has made the viewing request.

The input/output interface 36 also receives update data for the IP header conversion table from the IP header processing section 33 . Then, the input/output interface 36 performs Ethernet input/output interface processing on the updated data of the IP header conversion table, and sends the updated data of the IP header conversion table to all receiving devices in the building via the CMTS 12 and all CMs 20. Send to 21.

The input/output interface 36 also receives a join signal requesting program viewing from the in-building receiving device 21 via the CM 20 and CMTS 12 using the IGMPv3 protocol. Then, the input/output interface 36 performs Ethernet input/output interface processing on the Join signal, and outputs the Join signal of the program viewing request to the IP header conversion processing section 31 .

The input/output interface 36 also receives a notification of a new program viewing request from the in-building receiving device 21 via the CM 20 and CMTS 12. Then, the input/output interface 36 performs Ethernet input/output interface processing on the notification of the new program viewing request, and outputs the notification of the new program viewing request to the IP header processing section 33 .

[In-building receiving device 21]
Next, the in-building receiving device 21 shown in FIG. 1 will be explained in detail. FIG. 8 is a block diagram showing an example of the configuration of the in-building receiving device 21 according to the embodiment of the present invention. This in-building receiving device 21 includes input/output interfaces 40 and 46, an AL-FEC decoding section 41, an IP header conversion processing section 42, a join signal processing section 43, an IP header conversion table updating section 44, and a memory 45.

The input/output interface 40 receives an IP packet containing a video signal from the in-building transmitter 11 via the CMTS 12 and CM 20 using the IPv4 protocol. Then, the input/output interface 40 performs Ethernet input/output interface processing on the IP packet containing the video signal, and outputs the IP packet having an IPv4 header to the AL-FEC decoding section 41. The input/output interface 40 receives update data of the IP header conversion table from the in-building transmitter 11 via the CMTS 12 and CM 20. Then, the input/output interface 40 performs Ethernet input/output interface processing on the updated data of the IP header conversion table, and outputs the updated data of the IP header conversion table to the IP header conversion table update section 44 .

The input/output interface 40 also receives a join signal for a program viewing request from the IP header conversion processing section 42 . The input/output interface 40 then performs Ethernet input/output interface processing on the join signal requesting program viewing, and sends the join signal requesting program viewing to the in-building transmitter 11 via the CM 20 and CMTS 12 using the IGMPv3 protocol. Send. The input/output interface 40 receives a notification of a new program viewing request from the join signal processing section 43. Then, the input/output interface 40 performs Ethernet input/output interface processing on the notification of the new program viewing request, and transmits the notification of the new program viewing request to the in-building transmitting device 11 via the CM 20 and CMTS 12.

The AL-FEC decoding unit 41 receives an IP packet having an IPv4 header from the input/output interface 40, and performs AL-FEC decoding processing on the IP packet. Then, the AL-FEC decoding unit 41 outputs the IP packet having the IPv4 header subjected to the AL-FEC decoding process to the IP header conversion processing unit 42. This recovers lost packets.

The IP header conversion processing section 42 receives an IP packet having an IPv4 header from the AL-FEC decoding section 41. Then, the IP header conversion processing unit 42 extracts the IPv6 header corresponding to the IPv4 header of the input IP packet from the IP header conversion table stored in the memory 45, and converts the IPv4 header of the IP packet into an IPv6 header. The IP header conversion processing unit 42 generates an IP packet having an IPv6 header, and outputs the IP packet having the IPv6 header to the input/output interface 46.

Further, the IP header conversion processing unit 42 receives the join signal requesting program viewing from the join signal processing unit 43, and converts the IPv4 header corresponding to the IPv6 header of the input join signal from the IP header conversion table stored in the memory 45. and converts the IPv6 header of the Join signal into an IPv4 header. The IP header conversion processing unit 42 generates a Join signal having an IPv4 header, and outputs the Join signal having the IPv4 header to the input/output interface 40.

FIG. 9 is a flowchart showing a processing example of the join signal processing section 43. The join signal processing unit 43 receives a join signal requesting to view a program from the input/output interface 46 (step S901).

The join signal processing unit 43 determines whether the program included in the join signal of the program viewing request is a program being distributed and being viewed on the TV 23 (step S902). Specifically, the join signal processing unit 43 determines whether the IPv6 address of the program included in the join signal of the program viewing request exists in the IP header conversion table stored in the memory 45. If the program included in the Join signal of the program viewing request is being distributed, the IPv6 address of the program exists (registered) in the IP header conversion table. On the other hand, if the program included in the Join signal of the program viewing request is not being distributed, the IPv6 address of the program does not exist in the IP header conversion table (is not registered).

If the join signal processing unit 43 determines in step S902 that the program is being distributed (step S902: Y), that is, if it determines that the IPv6 address of the program exists in the IP header conversion table, the process proceeds to step S905. Transition.

On the other hand, if the join signal processing unit 43 determines in step S902 that the program is not being distributed (step S902: N), that is, if it determines that the IPv6 address of the program does not exist in the IP header conversion table, the join signal processing unit 43 adds a new A notification of the program viewing request is output to the input/output interface 40 (step S903).

As a result, the intra-building transmitting device 11 that receives the notification of the new program viewing request generates update data for the IP header conversion table, and the IP header conversion table held by the intra-building transmitting device 11 and the intra-building receiving device 21 is updated. is updated.

The join signal processing unit 43 determines whether the IP header conversion table stored in the memory 45 has been updated (step S904). That is, the join signal processing unit 43 determines whether update data of the IPv6 address of the program and the corresponding IPv4 address included in the join signal of the program viewing request has been added to the IP header conversion table.

If the join signal processing unit 43 determines in step S904 that the IP header conversion table has been updated (the IPv6 address, etc. has been added) (step S904: Y), the process proceeds to step S905. On the other hand, if the join signal processing unit 43 determines in step S904 that the IP header conversion table has not been updated (the IPv6 address, etc. has not been added) (step S904: N), the IP header conversion table is not updated. wait until

The join signal processing unit 43 moves from step S902 (Y) or step S904 (Y) and outputs a Jion signal requesting to view the program to the IP header conversion processing unit 42 (step S905).

As a result, a join signal for a program viewing request transmitted using the MLDv2 protocol is converted into a joining signal for a program viewing request transmitted using the IGMPv3 protocol using the IP header conversion table. Then, the join signal for the program viewing request is transmitted to the CATV station via the in-building transmitter 11, etc., and the video signal corresponding to the join signal for the program viewing request is transmitted from the CATV station.

Returning to FIG. 8, the IP header conversion table update unit 44 inputs the update data of the IP header conversion table from the input/output interface 40 and adds the updated data to the IP header conversion table stored in the memory 45.

As a result, the combination of the IPv6 address of the program included in the join signal of the program viewing request and the corresponding IPv4 address is added to the IP header conversion table stored in the memory 45, and the IP header conversion table is updated. .

The memory 45 stores an IP header conversion table. The updated data of the IP header conversion table is stored in the memory 45 by the IP header conversion table update section 44.

The input/output interface 46 receives an IP packet having an IPv4 header from the IP header conversion processing section 42 . Then, the input/output interface 46 performs Ethernet input/output interface processing on the IP packet having an IPv4 header, and transmits the IP packet containing the video signal to the IP-STB 22 using the IPv6 protocol.

The input/output interface 46 also receives a join signal requesting program viewing from the IP-STB 22 using the MLDv2 protocol. The input/output interface 46 then performs Ethernet input/output interface processing on the join signal requesting program viewing, and outputs the join signal requesting program viewing to the join signal processing section 43 .

[Distribution operation when there is a program viewing request]
Next, the distribution operation of each device when there is a program viewing request will be explained.

(If there is a request to view program 1)
First, the distribution operation when there is a request to view program 1 will be explained. FIG. 10 is a diagram explaining the operation when there is a request to view program 1. Program 1 (IPv6 address ff02::1) is selected from programs 1 to N by the user at recipient's home 3-1. This shows the operation when a call is received.

The in-building receiving device 21-1 of the recipient's house 3-1 receives a join signal for a program viewing request for program 1 (IPv6 address ff02::1) from the IP-STB 22-1 in accordance with the user's operation (step S1001).

The in-building receiving device 21-1 determines whether or not program 1 is currently being distributed, that is, whether or not information about the IPv6 address ff02::1 of program 1 exists in the IP header conversion table. Here, it is assumed that program 1 is not being distributed and information about the IPv6 address ff02::1 of program 1 does not exist in the IP header conversion table.

The in-building receiving device 21-1 determines that information about the IPv6 address ff02::1 of program 1 does not exist in the IP header conversion table (step S1002). Then, the in-building receiving device 21-1 transmits a notification of a new program viewing request for program 1 (IPv6 address ff02::1) to the in-building transmitting device 11 via the CM 20-1 and the CMTS 12 (step S1003). .

The in-building transmitter 11 receives a notification of a new program viewing request for program 1 (IPv6 address ff02::1). Then, the in-building transmitter 11 uses the IPv4 address allocation information and the program transmission capacity information to determine the bonding signal and IPv4 address to be actually used, generates update data for the IP header conversion table, and updates the IP header conversion table. is updated (step S1004).

For example, in response to a notification of a new program viewing request for program 1 (IPv6 address ff02::1), the in-building transmitter 11 uses the IPv4 address allocation information to determine which program is being distributed among the IPv4 addresses for bandwidth guarantee. Addresses other than the IPv4 address included in the information, such as 239.0.0.1, are identified as usable IPv4 addresses. Then, the in-building transmitter 11 obtains the required transmission capacity of program 1, 100 Mbps, from the program transmission capacity information. Further, the in-building transmitter 11 obtains the remaining bandwidth of 160 Mbps for each of the bonding signals 1, 2, and 3 as the remaining bandwidth for each bonding signal from the IPv4 address assignment information.

The in-building transmitter 11 determines that the remaining bandwidth of 160 Mbps of bonding signals 1, 2, and 3 is equal to or greater than the required transmission capacity of program 1, 100 Mbps, and determines bonding signal 1 to be actually used. Here, when there are multiple bonding signal candidates to be actually used, the in-building transmitter 11 selects the bonding signal with the smallest number among the multiple bonding signals according to a predetermined rule, for example, as the bonding signal to be actually used. decided on.

Furthermore, the intra-building transmitting device 11 determines the IPv4 address 239.0.0.1 to be actually used among the usable IPv4 addresses 239.0.0.1 and the like of the identified bonding signal 1. Here, when there are multiple IPv4 address candidates to actually use, the in-building transmitter 11 selects the IPv4 address with the smallest number among the multiple IPv4 addresses according to a predetermined rule, for example, as the IPv4 address to actually use. decided on.

The in-building transmitter 11 converts the combination of the IPv6 address ff02::1 of program 1 and various IPv6 header information, and the determined IPv4 address 239.0.0.1 and various IPv4 header information into an IP header conversion table. , and update the IP header conversion table.

Moving from step S1004, the in-building transmitting device 11 transmits the updated data of the IP header conversion table to the in-building receiving device 21-1 via the CMTS 12 and CM 20-1 (step S1005). In this case, the intra-building transmitting device 11 transmits the update data of the IP header conversion table to all the intra-building receiving devices 21 via all the CMs 20.

Regarding the IPv4 address allocation information, the intra-building transmitter 11 subtracts the transmission capacity of program 1, 100 Mbps, from the remaining band of bonding signal 1, 160 Mbps, and updates the subtraction result of 60 Mbp as a new remaining band. In addition, regarding the IPv4 address assignment information, the in-building transmitter 11 adds program 1, IPv6 address ff02::1, IPv4 address 239.0.0.1, and recipient's home 3 to the program information being distributed in bonding signal 1. -1 information is added.

The in-building receiving device 21-1 receives the update data for the IP header conversion table from the in-building transmitting device 11, and updates the IP header conversion table (step S1006). The same applies to other in-building receiving devices 21-2 and the like. In other words, the update data of the IP conversion table is transmitted from the in-building transmitter 11 to the in-building receivers 21-1, 21-2, etc. via the CMTS 12 and CM20-1, 20-2, etc. The IP header conversion table held by 21-1, 21-2, etc. is updated. As a result, the IP header conversion tables held by the intra-building transmitting device 11, the intra-building receiving devices 21-1, 21-2, etc. have the same contents.

The in-building receiving device 21-1 uses the IP header conversion table to convert the Join signal of the program viewing request for the program 1 (IPv6 address ff02::1) received from the IP-STB 22-1 to the IPv6 address ff02 of the program 1. The IPv6 header of ::1 is converted to the IPv4 header of IPv4 address 239.0.0.1 for distribution of program 1 (step S1007). The in-building receiving device 21-1 transmits a join signal for a program viewing request for program 1 (IPv4 address 239.0.0.1) to the in-building transmitting device 11 via the CM 20-1 and the CMTS 12 (step S1008 ).

As a result, the CM 20-1 receives the join signal for the program viewing request for program 1 from the in-building receiving device 21-1, and transmits the IP address including the video signal of program 1 from the in-building transmitting device 11 via the CMTS 12. When a packet is received, the IP packet is transmitted to the in-building receiving device 21-1.

The in-building transmitting device 11 receives a join signal requesting to view the program of program 1 (IPv4 address 239.0.0.1) from the in-building receiving device 21-1. Then, the in-building transmitter 11 converts the IPv4 header of the IPv4 address 239.0.0.1 for distribution of the program 1 into the IPv6 header of the IPv6 address ff02::1 of the program 1 using the IP header conversion table. (Step S1009). The in-building transmitter 11 transmits a join signal for requesting program viewing of program 1 (IPv6 address ff02::1) to the CATV station via the ONU 10 (step S1010).

The in-building transmitter 11 receives an IP packet containing a video signal of program 1 (IPv6 address ff02::1) from the CATV station via the ONU 10 (step S1011). Then, the in-building transmitter 11 uses the IP packet conversion table to convert the IPv6 header of IPv6 address ff02::1 of program 1 to the IPv4 header of IPv4 address 239.0.0.1 for distribution of program 1. (Step S1012). The in-building transmitting device 11 transmits an IP packet containing the video signal of program 1 (IPv4 address 239.0.0.1) to the in-building receiving device 21-1 (step S1013).

The in-building receiving device 21-1 receives an IP packet containing the video signal of program 1 (IPv4 address 239.0.0.1) from the in-building transmitting device 11. In this case, the IP packet containing the video signal of program 1 is multicast-transmitted from the CMTS 12 to the CMs 20-1, 20-2, etc. with a guaranteed bandwidth of the bonding signal 1, and then sent to the in-building receiving device 21-1 via the CM 20-1. arrive at. The CMs 20-1, 20-2, etc. receive IP packets containing the video signal of program 1. However, only the CM 20-1, which has already received the Join signal requesting to view the program 1, transmits an IP packet containing the video signal of the program 1 to the in-building receiving device 21-1. Other CMs 20-2 and the like receive the IP packet containing the video signal of program 1, but do not transmit the IP packet to the corresponding in-building receiving device 21-2 and the like.

In this way, when there is a request to view program 1 at receiver's home 3-1, the video signal of program 1 with guaranteed bandwidth is multicasted using vacant bonding signal 1, and CM 20-1 is The video signal of program 1 is transferred to the in-building receiving device 21-1.

The in-building receiving device 21-1 converts the IPv4 header of IPv4 address 239.0.0.1 for distribution of program 1 to the IPv6 header of IPv6 address ff02::1 of program 1 using the IP header conversion table. (Step S1014). The in-building receiving device 21-1 transmits an IP packet containing the video signal of program 1 (IPv6 address ff02::1) to the IP-STB 22-1 (step S1015).

As a result, the video signal is output from the IP-STB 22-1 to the TV 23-1, and the user at the recipient's home 3-1 can view the program 1.

(If there is a request to watch program 2 at another recipient's house 3 while watching program 1)
Next, a distribution operation will be described when there is a request to view program 2 at the recipient's home 3-2 after the operation shown in FIG. 10 is completed. FIG. 11 is a diagram for explaining the operation when there is a request to view program 2 at another house (receiver's house 3-2) while watching program 1. The operation is shown when program 2 (IPv6 address ff02::2) of programs 1 to N is selected.

As shown in FIG. 11, it is assumed that the video signal of program 1 is transmitted to recipient's home 3-1 using bonding signal 1, and program 1 is being viewed at recipient's home 3-1.

In addition, the IP header conversion table held by the in-building transmitter 11 and the in-building receivers 21-1, 21-2, etc. includes the IPv6 header of IPv6 address ff02::1 and the corresponding IPv4 address 239. It is assumed that an IPv4 header of .0.0.1 is included.

Furthermore, the IPv4 address allocation information held by the intra-building transmitter 11 includes information of 60 Mbps as the remaining band of the bonding signal 1. Further, it is assumed that the program information being distributed includes information on program 1, IPv6 address ff02::1, IPv4 address 239.0.0.1, and recipient's home 3-1.

The in-building receiving device 21-2 of the recipient's house 3-2 receives a join signal for a program viewing request for program 2 (IPv6 address ff02::2) from the IP-STB 22-2 in accordance with the user's operation (step S1101).

The in-building receiving device 21-2 determines whether or not program 2 is currently being distributed, that is, whether or not information about the IPv6 address ff02::2 of program 2 exists in the IP header conversion table. As described above, the IP header conversion table only contains information about the IPv6 address ff02::1 of program 1, and does not contain information about the IPv6 address ff02::2. In other words, only program 1 is being distributed, and program 2 is not being distributed.

The in-building receiving device 21-2 determines that information about the IPv6 address ff02::2 of program 2 does not exist in the IP header conversion table (step S1102). Then, the in-building receiving device 21-2 transmits a notification of a new program viewing request for program 2 (IPv6 address ff02::2) to the in-building transmitting device 11 via the CM 20-2 and the CMTS 12 (step S1103). .

The in-building transmitter 11 receives a notification of a new program viewing request for program 2 (IPv6 address ff02::2). Then, the in-building transmitter 11 uses the IPv4 address allocation information and the program transmission capacity information to determine the bonding signal and IPv4 address to be actually used, generates update data for the IP header conversion table, and updates the IP header conversion table. is updated (step S1104).

For example, in response to a notification of a new program viewing request for program 2 (IPv6 address ff02::2), the in-building transmitter 11 uses the IPv4 address allocation information to determine which program is being distributed among the IPv4 addresses for bandwidth guarantee. Addresses 239.0.0.2, . . . , 239.0.0.11, etc. other than the IPv4 addresses included in the information are specified as usable IPv4 addresses. Then, the in-building transmitter 11 acquires the required transmission capacity of program 2, 100 Mbps, from the program transmission capacity information. Further, the in-building transmitter 11 obtains the remaining bandwidth of 60 Mbps for bonding signal 1 and the remaining bandwidth of 160 Mbps for each of bonding signals 2 and 3 as the remaining bandwidth for each bonding signal from the IPv4 address assignment information.

The in-building transmitter 11 determines that the remaining bandwidth of 160 Mbps of the bonding signals 2 and 3 is greater than or equal to the required transmission capacity of the program 2, 100 Mbps, and determines the bonding signal 2 to be actually used. Furthermore, the in-building transmitter 11 determines the IPv4 address 239.0.0.11 to be actually used among the usable IPv4 addresses 239.0.0.11 and the like of the identified bonding signal 2.

The in-building transmitter 11 converts the combination of the IPv6 address ff02::2 of program 2 and various IPv6 header information, and the determined IPv4 address 239.0.0.11 and various IPv4 header information into an IP header conversion table. , and update the IP header conversion table.

Moving from step S1104, the in-building transmitting device 11 transmits the updated data of the IP header conversion table to the in-building receiving device 21-2 via the CMTS 12 and CM 20-2 (step S1105). In this case, the intra-building transmitting device 11 transmits the update data of the IP header conversion table to all the intra-building receiving devices 21 via all the CMs 20.

Regarding the IPv4 address allocation information, the in-building transmitter 11 subtracts the transmission capacity of program 2, 100 Mbps, from the remaining band of bonding signal 2, 160 Mbps, and updates the subtraction result of 60 Mbp as a new remaining band. In addition, regarding the IPv4 address assignment information, the in-building transmitter 11 adds the program information being distributed in the bonding signal 2 to program 2, IPv6 address ff02::2, IPv4 address 239.0.0.11, and recipient's home 3. -2 information is added.

The in-building receiving device 21-2 receives the update data of the IP header conversion table from the in-building transmitting device 11, and updates the IP header conversion table (step S1106). The same applies to other in-building receiving devices 21-1, 21-3, etc. As a result, the IP header conversion tables held by the intra-building transmitting device 11, the intra-building receiving devices 21-1, 21-2, etc. have the same contents.

The in-building receiving device 21-2 uses the IP header conversion table to convert the Join signal of the program viewing request for the program 2 (IPv6 address ff02::2) received from the IP-STB 22-2 to the IPv6 address ff02 of the program 2. ::2 is converted into an IPv4 header of IPv4 address 239.0.0.11 for distribution of program 2 (step S1107). The in-building receiving device 21-2 transmits a join signal requesting program viewing of program 2 (IPv4 address 239.0.0.11) to the in-building transmitting device 11 via the CM 20-2 and the CMTS 12 (step S1108 ).

As a result, the CM 20-2 receives the join signal for the program viewing request for program 2 from the in-building receiving device 21-2, and transmits the IP address including the video signal of program 2 from the in-building transmitting device 11 via the CMTS 12. When a packet is received, the IP packet is transmitted to the in-building receiving device 21-2.

The in-building transmitting device 11 receives a join signal requesting to view the program of program 2 (IPv4 address 239.0.0.11) from the in-building receiving device 21-2. Then, the in-building transmitter 11 converts the IPv4 header of the IPv4 address 239.0.0.11 for distribution of the program 2 into the IPv6 header of the IPv6 address ff02::2 of the program 2 using the IP header conversion table. (Step S1109). The in-building transmitter 11 transmits a join signal requesting to view the program 2 (IPv6 address ff02::2) to the CATV station via the ONU 10 (step S1110).

The in-building transmitter 11 receives an IP packet containing a video signal of program 2 (IPv6 address ff02::2) from the CATV station via the ONU 10 (step S1111). Then, the in-building transmitter 11 uses the IP packet conversion table to convert the IPv6 header of the IPv6 address ff02::2 of the program 2 into the IPv4 header of the IPv4 address 239.0.0.11 for distribution of the program 2. (Step S1112). The in-building transmitter 11 transmits an IP packet containing the video signal of program 2 (IPv4 address 239.0.0.11) to the in-building receiver 21-2 via the CMTS 12 and CM 20-2 (step S1113). ).

The in-building receiving device 21-2 receives an IP packet containing the video signal of program 2 (IPv4 address 239.0.0.11) from the in-building transmitting device 11. In this case, the IP packet containing the video signal of program 2 is multicast-transmitted from the CMTS 12 to the CMs 20-1, 20-2, etc. with a band guaranteed by the bonding signal 2, and then transmitted via the CM 20-2 to the in-building receiving device 21-2. arrive at. The CMs 20-1, 20-2, etc. receive IP packets containing the video signal of program 2. However, only the CM 20-2, which has already received the Join signal requesting to view the program 2, transmits an IP packet containing the video signal of the program 2 to the in-building receiving device 21-2. Other CMs 20-1 and the like receive the IP packet containing the video signal of program 2, but do not transmit the IP packet to the in-building receiving device 21-1 and the like.

In this way, when there is a request to view program 2 at the recipient's home 3-2, the video signal of program 2 with guaranteed bandwidth is multicasted using the vacant bonding signal 2, and CM 20-2 is The video signal of program 2 is transferred to the in-building receiving device 21-2.

The in-building receiving device 21-2 converts the IPv4 header of IPv4 address 239.0.0.11 for distribution of program 2 to the IPv6 header of IPv6 address ff02::2 of program 2 using the IP header conversion table. (Step S1114). The in-building receiving device 21-2 transmits an IP packet containing the video signal of program 2 (IPv6 address ff02::2) to the IP-STB 22-2 (step S1115).

As a result, the video signal is output from the IP-STB 22-2 to the TV 23-2, and the user at the recipient's home 3-2 can view the program 2.

(If there is a request to view program 1 at another recipient's home 3 while viewing programs 1 and 2)
Next, a distribution operation will be described when there is a request to view program 1 at the recipient's home 3-3 after the operation shown in FIG. 11 is completed. FIG. 12 is a diagram explaining the operation when there is a request to view program 1 at another house (receiver's house 3-3) while programs 1 and 2 are being viewed. shows the operation when program 1 (IPv6 address ff02::1) of programs 1 to N is selected.

As shown in the upper part of FIG. 12, it is assumed that the video signal of program 1 is transmitted to recipient's home 3-1 using bonding signal 1, and program 1 is being viewed at recipient's home 3-1. Further, it is assumed that the video signal of program 2 is transmitted to receiver's house 3-2 by bonding signal 2, and program 2 is being viewed at receiver's house 3-2.

In addition, the IP header conversion table held by the in-building transmitting device 11 and in-building receiving devices 21-1, 21-2, etc. includes the IPv6 header of IPv6 address ff02::1 for program 1 and its corresponding The combination of the IPv4 header of the IPv4 address 239.0.0.1 for program 2, the IPv6 header of the IPv6 address ff02::2 for program 2, and the corresponding IPv4 header of the IPv4 address 239.0.0.11. shall be included.

Further, the IPv4 address allocation information held by the intra-building transmitter 11 includes information of 60 Mbps as the remaining bands of the bonding signals 1 and 2, respectively. Further, it is assumed that the program information being distributed for the bonding signal 1 includes information about the program 1, the IPv6 address ff02::1, the IPv4 address 239.0.0.1, and the recipient's home 3-1. It is assumed that the program information being distributed for the bonding signal 2 includes information about the program 2, the IPv6 address ff02::2, the IPv4 address 239.0.0.11, and the recipient's home 3-2.

The in-building receiving device 21-3 of the recipient's house 3-3 receives a join signal for a program viewing request for program 1 (IPv6 address ff02::1) from the IP-STB 22-3 in accordance with the user's operation (step S1201).

The in-building receiving device 21-3 determines whether or not program 1 is currently being distributed, that is, whether or not information about the IPv6 address ff02::1 of program 1 exists in the IP header conversion table. As described above, the IP header conversion table includes information about the IPv6 address ff02::1 of program 1. In other words, program 1 is currently being distributed.

The in-building receiving device 21-3 determines that information about the IPv6 address ff02::1 of program 1 exists in the IP header conversion table, and converts the IPv6 address ff02:: of program 1 to the Join signal of the program viewing request for program 1. 1 is converted into an IPv4 header of IPv4 address 239.0.0.1 for distribution of program 1 (step S1202). The in-building receiving device 21-3 receives a join signal for a program viewing request for program 1 (IPv4 address 239.0.0.1) instead of a notification for a new program viewing request for program 1 (IPv6 address ff02::1). , CM20-3 and CMTS12 to the in-building transmitter 11 (step S1203).

As a result, the CM 20-3 receives the join signal for the program viewing request for program 1 from the in-building receiving device 21-3, and receives the IP address including the video signal of program 1 from the in-building transmitting device 11 via the CMTS 12. When a packet is received, the IP packet is transmitted to the in-building receiving device 21-3.

The in-building transmitter 11 receives an IP packet containing a video signal of program 1 (IPv6 address ff02::1) from the CATV station via the ONU 10 (step S1204, which corresponds to step S1011 in FIG. 10). Then, the in-building transmitter 11 uses the IP packet conversion table to convert the IPv6 header of IPv6 address ff02::1 of program 1 to the IPv4 header of IPv4 address 239.0.0.1 for distribution of program 1. (Steps S1205, S1012). The in-building transmitting device 11 transmits an IP packet containing the video signal of program 1 (IPv4 address 239.0.0.1) to the in-building receiving devices 21-1 and 21-3 (steps S1206, S1013).

The in-building receiving device 21-3 receives an IP packet containing the video signal of program 1 (IPv4 address 239.0.0.1) from the in-building transmitting device 11. In this case, the IP packet containing the video signal of program 1 is multicast transmitted from CMTS 12 to CM 20-1, 20-2, etc. with guaranteed bandwidth using bonding signal 1, and is received within the building via CM 20-1, 20-3. It arrives at devices 21-1 and 21-3. The CMs 20-1, 20-2, etc. receive IP packets containing the video signal of program 1. However, only CMs 20-1 and 20-3, which have already received the join signal requesting to view program 1, send IP packets containing the video signal of program 1 to in-building receiving devices 21-1 and 21-3, respectively. . Other CMs 20-2 and the like receive the IP packet containing the video signal of program 1, but do not transmit the IP packet to the in-building receiving device 21-2 and the like.

In this way, when there is a request to view program 1 at recipient's home 3-3, CM 20-3 receives the video signal of program 1, which has already been guaranteed bandwidth using bonding signal 1 and is being multicast distributed. Then, the video signal is transferred to the in-building receiving device 21-3.

The in-building receiving device 21-3 converts the IPv4 header of IPv4 address 239.0.0.1 for distribution of program 1 to the IPv6 header of IPv6 address ff02::1 of program 1 using the IP header conversion table. (Step S1207). The in-building receiving device 21-3 transmits an IP packet containing the video signal of program 1 (IPv6 address ff02::1) to the IP-STB 22-3 (step S1208).

As a result, the video signal is output from the IP-STB 22-3 to the TV 23-3, and the user at the recipient's home 3-3 can view the program 1.

FIG. 13 is a diagram illustrating a situation where program 1 is viewed at recipient's homes 3-1 and 3-3, and program 2 is viewed at recipient's home 3-2. It shows the situation after the operation is completed.

As shown in the upper part of FIG. 13, the video signal of program 1 is transmitted to CM20-1, 20-2, 20-3, etc. with the band guaranteed by bonding signal 1, and the video signal of program 2 is transmitted to CM20-1, 20-2, 20-3, etc. Bandwidth is guaranteed in signal 2, and the signal is transmitted to CMs 20-1, 20-2, 20-3, etc.

Then, only the CMs 20-1 and 20-3, which have already received the join signal requesting to view the program 1, receive the video signal of the program 1 and transmit it to the in-building receiving devices 21-1 and 21-3, respectively. Therefore, program 1 is currently being viewed at recipient homes 3-1 and 3-3.

Further, only the CM 20-2, which has already received the Join signal requesting to view the program 2, receives the video signal of the program 2 and transmits it to the in-building receiving device 21-2. Therefore, program 2 is being viewed at the recipient's home 3-2.

In this case, the information shown in FIG. 3 is included in the IP header conversion table held by the intra-building transmitting device 11, the intra-building receiving devices 21-1, 21-2, etc. Specifically, the IP header conversion table includes a combination of the IPv6 header with IPv6 address ff02::1 for program 1 and the IPv4 header with the corresponding IPv4 address 239.0.0.1, and the combination of the IPv6 header with IPv6 address ff02::1 for program 1, and The IPv6 header of the IPv6 address ff02::2 and the corresponding IPv4 header of the IPv4 address 239.0.0.11 are included.

Furthermore, the IPv4 address allocation information held by the intra-building transmitter 11 includes the information shown in FIG. Specifically, the IPv4 address allocation information includes information of 60 Mbps as the remaining bandwidth of bonding signals 1 and 2, respectively. In addition, the program information during the distribution of bonding signal 1 includes information on program 1, IPv6 address ff02::1, IPv4 address 239.0.0.1, and recipient homes 3-1 and 3-3. The program information currently being distributed for the bonding signal 2 includes information about the program 2, the IPv6 address ff02::2, the IPv4 address 239.0.0.11, and the recipient's home 3-2.

As described above, according to the intra-building transmitting device 11 of the embodiment of the present invention, the IP header processing unit 33 uses the IPv4 address allocation information stored in the memory 34 to distribute among the IPv4 addresses for bandwidth guarantee. Addresses other than IPv4 addresses included in the program information are identified as usable IPv4 addresses.

In accordance with the notification of the new program viewing request transmitted from the in-building receiving device 21, the IP header processing unit 33 determines the IPv6 address of the program included in the notification of the new program viewing request from the program transmission capacity information stored in the memory 34. Obtain the corresponding required transmission capacity. Then, the IP header processing unit 33 obtains the remaining bandwidth for each bonding signal from the IPv4 address assignment information stored in the memory 34.

The IP header processing unit 33 determines the bonding signal and IPv4 address to be actually used based on the available IPv4 address, the transmission capacity of the new program, and the remaining bandwidth of each bonding signal so as not to exceed the band of the bonding signal. do.

The IP header processing unit 33 generates data including the IPv6 address and IPv4 address of the program included in the notification of the new program viewing request as update data of the IP header conversion table, and stores the update data in the memory 32. It is added to the IP header conversion table created and output to the input/output interface 36.

The IP header processing unit 33 updates the remaining bandwidth of the IPv4 address allocation information stored in the memory 34 and the program information being distributed.

As a result, the updated data of the IP header conversion table is transmitted to the in-building receiving device 21, and the IP header conversion tables held in the in-building transmitting device 11 and the in-building receiving device 21 are updated to data with the same content. .

The IP header conversion processing unit 31 converts the IPv4 header included in the join signal of the program viewing request transmitted from the in-building receiving device 21 into an IPv6 header using the IP header conversion table. A Join signal with an IPv6 header is sent to the CATV station.

The IP header conversion processing unit 31 converts an IPv6 header included in an IP packet of a video signal transmitted from a CATV station into an IPv4 header using an IP header conversion table. An IP packet of a video signal having an IPv4 header is transmitted to the in-building receiving device 21 via the CMTS 12 and CM 20 with the band guaranteed by the bonding signal determined by the IP header processing unit 33.

In this way, 4K8K multi-channel broadcasting IP signals can be transmitted with guaranteed bandwidth and AL-FEC without exceeding the MTU handled by CMTS12 and CM20 on the transmission line within the building of a non-optical apartment complex. can do. In this case, fragment processing or processing to change the MTU becomes unnecessary.

Specifically, since an IPv6 header is converted to an IPv4 header using an IP header conversion table, the maximum packet length of an IP packet is The MTU to be handled will not be exceeded. In other words, the maximum packet length does not exceed MTU, fragment processing is not required, and intra-building transmission of 4K8K multi-channel broadcasting can be realized at low cost.

More specifically, in CATV stations, 4K8K multi-channel broadcasting that complies with the Advanced Wideband Satellite Digital Broadcasting Operation Regulations of Non-Patent Document 7, which requires broadcasting using IPv6 with the maximum packet length set to MTU = 1500 bytes. In-building transmission can be realized.

In addition, at CATV stations, there is no need to change the IP packet length to less than the maximum packet length of MTU = 1500 bytes, and the settings of the broadcasting equipment already in operation can be used as is, so there is no need to change the IP packet length. Unnecessary costs are also eliminated. Furthermore, since fragment processing is not required, costs do not increase.

On the other hand, according to the in-building receiving device 21 according to the embodiment of the present invention, when there is a new program viewing request from the user, the join signal processing section 43 determines if the program corresponding to the join signal of the program viewing request is not being distributed. (If the IPv6 address of the program does not exist in the IP header conversion table), a notification of a new program viewing request is output.

A notification of a new program viewing request is transmitted to the intra-building transmitting device 11. Then, the intra-building transmitting device 11 generates update data for the IP header conversion table corresponding to the notification of the new program viewing request, and transmits it to the intra-building receiving device 21.

The IP header conversion table update unit 44 inputs the update data of the IP header conversion table transmitted from the intra-building transmitter 11 and adds the updated data to the IP header conversion table stored in the memory 45. Thereby, the intra-building transmitting device 11 and the intra-building receiving device 21 can hold IP header conversion tables with the same contents.

When update data is added to the IP header conversion table by the IP header conversion table update unit 44, the IP header conversion processing unit 42 uses the IP header conversion table to convert the IPv6 header included in the join signal of the program viewing request to IPv4. Convert to header. The Join signal with the IPv4 header is transmitted to the intra-building transmitter 11.

The IP header conversion processing unit 42 converts the IPv4 header included in the IP packet of the video signal transmitted from the intra-building transmitter 11 into an IPv6 header using the IP header conversion table. The IP packet of the video signal having the IPv6 header is output to the IP-STB 22.

In this way, 4K8K multi-channel broadcasting IP signals can be transmitted with guaranteed bandwidth and AL-FEC without exceeding the MTU handled by CMTS12 and CM20 on the transmission line within the building of a non-optical apartment complex. can do. In this case, fragment processing or processing to change the MTU becomes unnecessary.

In other words, the maximum packet length does not exceed MTU, fragment processing is not required, and intra-building transmission of 4K8K multi-channel broadcasting can be realized at low cost.

Although the present invention has been described above with reference to the embodiments, the present invention is not limited to the embodiments described above, and can be modified in various ways without departing from the technical concept thereof.

In the embodiment, the intra-building IP transmission in the intra-building transmission system 1 shown in FIG. 1 uses the CMTS 12 and CM 20 of the DOCSIS standard. The present invention is applicable not only to the communication method of the DOCSIS standard but also to the communication method of the local 5G standard. When using the local 5G standard communication method for IP transmission within the building, a local 5G transmitter is installed in place of CMTS12, a local 5G receiver is installed in place of CM20, and a local 5G receiver is installed in place of CMTS12, and instead of a transmission path using a coaxial cable. A wireless transmission path is used.

Further, the intra-building transmitting device 11 includes an AL-FEC encoding section 35 and performs AL-FEC encoding processing, and the intra-building receiving device 21 includes an AL-FEC decoding section 41 and performs AL-FEC decoding processing. I decided to do it. The present invention does not necessarily require AL-FEC encoding processing and AL-FEC decoding processing. In this case, the intra-building transmitting device 11 does not include the AL-FEC encoding section 35, and the intra-building receiving device 21 does not include the AL-FEC decoding section 41.

Note that a normal computer can be used as the hardware configuration of the intra-building transmitting device 11 and the intra-building receiving device 21 according to the embodiment of the present invention. The in-building transmitting device 11 and the in-building receiving device 21 are configured by a computer including a CPU, a volatile storage medium such as a RAM, a non-volatile storage medium such as a ROM, an interface, and the like.

The functions of the input/output interfaces 30 and 36, the IP header conversion processing section 31, the memories 32 and 34, the IP header processing section 33, and the AL-FEC encoding section 35 provided in the in-building transmitting device 11 are described as follows. Each of these is realized by having the CPU execute the program.

In addition, each function of input/output interfaces 40, 46, AL-FEC decoding section 41, IP header conversion processing section 42, join signal processing section 43, IP header conversion table updating section 44, and memory 45 provided in the in-building receiving device 21 is provided. These functions are also realized by having the CPU execute a program in which these functions are written.

These programs are stored in the storage medium, and are read and executed by the CPU. Additionally, these programs can be stored and distributed in storage media such as magnetic disks (floppy (registered trademark) disks, hard disks, etc.), optical disks (CD-ROMs, DVDs, etc.), semiconductor memories, etc., and can be distributed via networks. You can also send and receive messages.

1 In-building transmission system 2 MDF (Main Distribution Frame) room 3 Receiver's house 4 Signal branch 10 ONU (Optical Network Unit)
11 In-building transmitter 12 CMTS (Cable Modem Termination System)
20 CM (Cable Modem)
21 In-building receiving device 22 IP-STB (Set Top Box)
23 TV (Television)
30, 36, 40, 46 Input/output interface 31, 42 IP header conversion processing unit 32, 34, 45 Memory 33 IP header processing unit 35 AL-FEC (Application Layer-Forward Error Correction) encoding unit 41 AL-FEC decoding section 43 Join signal processing section 44 IP header conversion table updating section

Claims (7)

ONU (optical line termination unit), in-building transmitter and first in-building transmission device installed in the MDF (main distribution frame) room, and second in-building transmission installed in each of the multiple recipient homes. In-building transmission consists of a device, an in-building receiving device, an IP-STB (set-top box), and a TV (television), and transmits IP packets containing video signals distributed by IP multicast from a CATV station via an FTTH transmission line. The in-building transmitting device in the system,
a first memory storing an IP header conversion table consisting of a combination of an IPv6 header containing a predetermined IPv6 address and an IPv4 header containing an IPv4 address corresponding to the IPv6 header;
The IPv6 header included in the IP packet transmitted from the CATV station is converted into the IPv4 header using the IP header conversion table stored in the first memory, and the IP packet having the IPv4 header is converted into the IPv4 header. a first IP header conversion processing unit that generates;
The IP packet having the IPv4 header generated by the first IP header conversion processing unit is transmitted from the first intra-building transmission device to all the second intra-buildings with a guaranteed band using a predetermined bonding signal. An in-building transmitting device characterized in that the second in-building transmitting device transmits the video signal to the in-building receiving device to which a request for viewing a program of the video signal has been made. The in-building transmitter according to claim 1,
Furthermore, it is equipped with an IP header processing section,
A notification of a program viewing request for the program selected by a user in the recipient's house is transmitted from the in-building receiving device to the in-building transmission device through the second in-building transmission device and the first in-building transmission device. When it is sent to the transmitting device,
The IP header processing unit includes:
Based on the IPv4 address that can be used to distribute the video signal, the transmission capacity for the program corresponding to the notification, and the remaining bandwidth for each bonding signal whose bandwidth is guaranteed, so as not to exceed the bandwidth of the bonding signal, determining the bonding signal and the IPv4 address to be actually used;
Generating a combination of the IPv6 header including the IPv6 address of the program corresponding to the notification and the IPv4 header including the IPv4 address as update data;
The updated data is added to the IP header conversion table stored in the first memory, and the update data is added to the IP header conversion table stored in the first memory, and transmitted to all the buildings via the first intra-building transmission device and all the second intra-building transmission devices. An in-building transmitting device characterized by transmitting to an in-building receiving device. In the in-building transmitting device according to claim 2,
Furthermore, program transmission capacity information including transmission capacity for each program, transmission capacity for each bonding signal, IPv4 address for bandwidth guarantee, remaining bandwidth, IPv6 address related to the program being distributed, IPv4 address including IPv4 address and distribution destination comprising a second memory storing allocation information;
The IP header processing unit includes:
identifying the usable IPv4 address based on the bandwidth guarantee IPv4 address included in the IPv4 address allocation information stored in the second memory and the IPv4 address related to the program being distributed;
obtaining the transmission capacity for the program corresponding to the notification from the program transmission capacity information stored in the second memory;
obtaining the remaining band of the bonding signal from the IPv4 address allocation information;
Based on the available IPv4 address, the transmission capacity for the program, and the remaining band of the bonding signal, determine the bonding signal to be actually used so as not to exceed the band of the bonding signal, and An intra-building transmitting device characterized in that the IPv4 address to be actually used is determined from among the available IPv4 addresses for a bonding signal. An ONU (optical line terminal unit) installed in an MDF (main distribution board) room, an in-building transmitter and a first in-building transmitter according to claim 1, and a second in-building transmitter installed in each of a plurality of recipient homes. It consists of an in-building transmission device, an in-building receiving device, an IP-STB (set-top box), and a TV (television), and transmits IP packets including video signals distributed by IP multicast from CATV stations via FTTH transmission lines. The in-building receiving device in an in-building transmission system,
It consists of a combination of an IPv6 header containing a predetermined IPv6 address and an IPv4 header containing an IPv4 address corresponding to the IPv6 header, and stores the same IP header translation table as the one held by the intra-building transmitter. a third memory,
The intra-building transmission device converts the IPv6 header included in the IP packet transmitted from the CATV station into the IPv4 header, and the IP packet having the IPv4 header is transmitted to the first intra-building transmission device and the When the IPv4 header included in the IP packet is transmitted to the in-building receiving device via the second in-building transmission device, the IPv4 header included in the IP packet is transmitted using the IP header conversion table stored in the third memory. a second IP header conversion processing unit that converts the IPv6 header into the IPv6 header and generates the IP packet having the IPv6 header;
An in-building receiving device characterized by comprising: ONU (optical line terminal unit) installed in the MDF (main distribution board) room, the in-building transmitter and the first in-building transmitter according to claim 2 or 3, and installed in each of the plurality of recipient homes. A second in-building transmission device, an in-building receiving device, an IP-STB (set-top box), and a TV (television), and IP packets containing video signals distributed by IP multicast from a CATV station via an FTTH transmission path. The in-building receiving device in an in-building transmission system that transmits
a third memory that stores an IP header conversion table that is made up of a combination of a predetermined IPv6 header and an IPv4 header that corresponds to the IPv6 header, and is the same as the IP header conversion table held by the intra-building transmitter;
The intra-building transmission device converts the IPv6 header included in the IP packet transmitted from the CATV station into the IPv4 header, and the IP packet having the IPv4 header is transmitted to the first intra-building transmission device and When the IPv4 packet contained in the IP packet is transmitted to the intra-building receiving device via the second intra-building transmission device, using the IP header conversion table stored in the third memory, a second IP header conversion processing unit that converts a header into the IPv6 header and generates the IP packet having the IPv6 header;
When a user at the recipient's home requests to view a selected program, determining whether or not the IPv6 address of the program exists in the IP header conversion table stored in the third memory; If it is determined that the IPv6 address of the program does not exist in the IP header conversion table, a notification of a program viewing request for the program tuned by the user at the recipient's home is output, and the notification is transmitted to the second a signal processing unit that causes the signal to be transmitted to the in-building transmitting device via the in-building transmitting device and the first in-building transmitting device;
The intra-building transmission device generates a combination of the IPv6 header and the IPv4 header as update data in response to the notification, and the updated data is transmitted to the first intra-building transmission device and the second intra-building transmission device. an IP header conversion table update unit that adds the update data to the IP header conversion table stored in the third memory when the update data is transmitted to the in-building receiving device via the IP header conversion table;
An in-building receiving device characterized by comprising: A program for causing a computer to function as the in-building transmitting device according to any one of claims 1 to 3. A program for causing a computer to function as the in-building receiving device according to claim 4 or 5.

Images