WO2015145869A1 - パケット自動受信装置 - Google Patents

パケット自動受信装置 Download PDF

Info

Publication number
WO2015145869A1
WO2015145869A1 PCT/JP2014/081207 JP2014081207W WO2015145869A1 WO 2015145869 A1 WO2015145869 A1 WO 2015145869A1 JP 2014081207 W JP2014081207 W JP 2014081207W WO 2015145869 A1 WO2015145869 A1 WO 2015145869A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
source identifier
buffer
transmission source
transmission
Prior art date
Application number
PCT/JP2014/081207
Other languages
English (en)
French (fr)
Inventor
裕美 藤田
永山　英紀
Original Assignee
Ｎｔｔエレクトロニクス株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ｎｔｔエレクトロニクス株式会社 filed Critical Ｎｔｔエレクトロニクス株式会社
Priority to US15/118,062 priority Critical patent/US10333834B2/en
Publication of WO2015145869A1 publication Critical patent/WO2015145869A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/34—Source routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Definitions

  • the present invention relates to an automatic packet receiving apparatus that can automatically receive IP packets transmitted from a plurality of transmitting apparatuses without confusion without resetting network parameters on the receiving side.
  • IP packets are transmitted from a plurality of transmitting devices to one receiving device via IP (Internet Protocol) networks at different times.
  • IP Internet Protocol
  • the format of the IP packet used for communication is known (for example, see Non-Patent Documents 1 to 3).
  • the conventional receiving apparatus selects the IP packet to be stored in the buffer by looking at the network parameters of the received IP packet.
  • the venue A Prior to each relay from the venues A to C, the venue A is between 9:30 and 10:00, the venue B is between 12:00 and 12:30, and the venue C is 14:30 to 15: During 00, it was necessary to change the network parameter settings for the receiving device at the venue Z every time.
  • the present invention has been made to solve the above-described problems, and an object of the present invention is to automatically receive IP packets transmitted from a plurality of transmitting devices without confusion without resetting network parameters on the receiving side.
  • An automatic packet receiving apparatus capable of performing the above is obtained.
  • a packet automatic receiving apparatus includes a packet receiving unit that receives an IP packet having a network parameter and a transmission source identifier, a transmission source identifier table that records the transmission source identifier of the received IP packet, If the source identifier of the received IP packet matches the source identifier recorded in the source identifier table, the received IP packet is stored in the first buffer regardless of the network parameter.
  • a packet storage processing unit for extracting the IP packet stored in the first buffer from the first buffer for packet transfer, and when there is no IP packet of the specific transmission source identifier, And a packet withdrawal transfer unit to be updated.
  • IP packets transmitted from a plurality of transmission devices can be automatically received without confusion without resetting network parameters on the receiving side.
  • FIG. 1 is a diagram showing a video transmission system according to Embodiment 1 of the present invention.
  • venues A, B, and C transmission devices 1a, 1b, and 1c that transmit video in IP packets are installed, respectively.
  • venue Z an automatic packet reception device 2 that receives IP packets transmitted from each venue is installed.
  • the transmission device 1a of the venue A is from 10:00 to 12:00
  • the transmission device 1b of the venue B is from 12:30 to 14:30
  • the transmission device 1c of the venue C is from 15:00 to 17:00.
  • Video transmission is performed via the IP network 3 to the Z packet automatic receiver 2.
  • Transmission device 1a, 1b, 1c and each packet the IP address of the automatic reception device 2 IP A, IP B, IP C, a IP Z, the port number is PN A, PN B, PN C , PN Z respectively.
  • the automatic packet reception device 2 can automatically receive the IP packets transmitted from all the transmission devices 1a, 1b, and 1c without reconfiguration without resetting the network parameters on the reception side.
  • FIG. 2 is a diagram showing the configuration of an IP packet.
  • An IP header is provided in the Internet layer, a UDP header is provided in the transport layer, and an RTP header is provided in the application layer.
  • the application layer by setting 1 to the X bit in the RTP header, the RTP extension header can be inserted and used after the RTP header.
  • the extension header includes a user-defined area.
  • FIG. 3 is a diagram showing an automatic packet reception apparatus according to Embodiment 1 of the present invention.
  • the packet receiving unit 4 receives an IP packet having a network parameter and a transmission source identifier.
  • the transmission source identifier table 5 records the transmission source identifier of the received IP packet.
  • the transmission source identifier table 5 is a table of array DI, and can store a maximum of N pieces of information of N transmission source identifiers from DI (0) to DI (N ⁇ 1) in order from address 0.
  • N 1, and the source identifier information stored in the source identifier table is only DI (0).
  • the packet storage processing unit 6 receives the received IP packet regardless of the network parameters. Are stored in the first buffer 7.
  • the packet extraction / transfer unit 8 extracts the IP packet stored in the first buffer 7 from the first buffer 7 and transfers the packet.
  • the transmission source identifier is given in the IP packet on the transmission side, and is referred to as DI (Device Identifier) here.
  • the transmission source identifier is SSRC (Synchronization Source) included in the RTP packet in the IP packet.
  • the SSRC is often set with a random number, but it can be said that there is no overlap between all the transmission devices due to the device for starting the random number calculation.
  • a user-defined transmission source identification symbol recorded in the RTP extension header may be used as the transmission source identifier. In this case, it is necessary to determine in advance so that another value is set between the transmission apparatuses.
  • These transmission source identifiers are recorded in IP packets separately from the network parameters.
  • FIG. 4 is a diagram showing a processing flow of the buffer storage processing unit according to Embodiment 1 of the present invention.
  • an IP packet is transmitted from the transmitting apparatus 1a at the venue A toward the automatic packet receiving apparatus 2.
  • the packet storage processing unit 6 clears the first buffer 7 and the transmission source identifier table 5 to zero as an initial setting (step S1).
  • one IP packet is received from the packet receiver 4 (step S2).
  • the source identifier is read from the IP packet.
  • the read value and DI R step S3.
  • the transmission source identifier table 5 additionally stores combinations of all types of transmission source identifiers that have arrived at the automatic packet reception device 2 in the order of arrival. If the same sender identifier has already been stored, no additional writing is performed. That is, in the first embodiment, only the first transmission source identifier is recorded. Since it is first cleared in step S1, the first transmission source identifier DI (0) in the transmission source identifier table 5 is 0 when the first IP packet arrives (step S4). Therefore, the transmission source identifier read in step S3 is recorded in DI (0) (step S5). Then, this IP packet is stored in the first buffer 7 (step S6).
  • the IP packet received for the second time is the same as the source identifier of the IP packet received for the first time (step S7), the IP packet is stored in the first buffer 7 (step S6). In this way, IP packets having the same transmission source identifier are stored in the first buffer 7 one after another.
  • the IP packet will be sent when reception from venue A ends at 12:00. Waiting for reception (step S2). In this case, the transmission source identifier DI (0) currently used is cleared to zero. This process is performed by the packet withdrawal transfer unit 8 as described later.
  • step S7 the IP packet itself is discarded.
  • FIG. 5 is a diagram showing a processing flow of the packet withdrawal transfer unit according to the first embodiment of the present invention.
  • the transmission source identifier of the received IP packet matches the transmission source identifier recorded in the transmission source identifier table 5, the received IP packet is not changed regardless of the network parameter. 1 in the buffer 7. As a result, the network parameters of the received IP packet are ignored, and all arrived IP packets can be received.
  • a plurality of network parameters can be set without re-setting the network parameters on the reception side in compliance with the IP packet format. It is possible to automatically receive the IP packet transmitted from the transmission device of the first without any confusion. Therefore, even if an unexpected IP packet arrives at the venue Z side, there is no influence on the relay video from the venue A to the venue Z.
  • the IP packet having the previous transmission source identifier does not arrive, and has another transmission source identifier.
  • An IP packet arrives. In that case, it continues to receive only IP packets with new source identifiers. Thereby, even if the transmission source changes, reception of a new transmission source can be continued without resetting network parameters on the reception side.
  • FIG. FIG. 6 shows an automatic packet reception apparatus according to Embodiment 2 of the present invention.
  • a second buffer 9 is also provided.
  • the packet storage processing unit 6 stores an IP packet with a certain type of source identifier in the first buffer 7 and stores IP packets with other source identifiers in the second buffer 9.
  • the packet withdrawal transfer unit 8 transfers an IP packet having a specific transmission source identifier from the second buffer 9 to the first buffer 7.
  • FIG. 7 is a diagram showing a processing flow of the buffer storage processing unit according to the second embodiment of the present invention. Differences from the processing flow of the first embodiment will be described.
  • the packet storage processing unit 6 clears not only the first buffer 7 and the transmission source identifier table 5 but also the second buffer 9 (step S21).
  • the read source identifier is different from the source identifier DI (0) being processed (step S7). Therefore, the sender identifier is added to the sender identifier table 5 (step S22). At this time, one line is added to the end of the valid data in the transmission source identifier table 5. If it is an unused area after that, 0 is entered there. As a result, all the received transmission source identifiers are recorded in the transmission source identifier table 5.
  • the first embodiment it is assumed that there is a 30-minute packet reception pause between transmission from the A venue and transmission from the B venue. That is, after the reception from the venue A is completed, the reception from the venue B is started in a state of waiting to receive a packet (step S2). In this case, since DI (0) is used, DI (1) is added to the transmission source identifier table 5. In order to receive the IP packet from the venue B, it is necessary to set DI (1) to DI (0). The update of the transmission source identifier table 5 is performed by the packet withdrawal transfer unit 8 as described later.
  • Step S23 when transmission from the venue A is 10: 00-12: 30 and transmission from the venue B is 12: 29-14: 30, there is some overlap at the time of switching. Therefore, in the second embodiment, the second buffer 9 is added, and the IP packets from the venue B are accumulated and stored in the second buffer 9 without discarding the IP packets as in the first embodiment. (Step S23).
  • FIG. 8 is a diagram showing a processing flow of the packet withdrawal transfer unit according to the second embodiment of the present invention.
  • the IP packets from the venue A stored in the first buffer 7 are read (steps S11 and S24). If there is even one IP packet in the first buffer 7, the content of one IP packet is read (step S25).
  • Sender identifier DI R of the IP packet if the match the source identifier DI recorded in the leading address of the transmission source identifier table 5 (0) (step S26), the IP packets read from the first buffer 7 The packet is taken out and transferred (step S15). The extracted IP packet disappears from the first buffer 7.
  • the collation with DI (0) is repeated for all IP packets in the first buffer 7 (steps S11, S24, S25, S26, S15, S16).
  • the transmission source identifier table 5 is updated (step S17). For example, the contents of the array DI are shifted by one address, such as DI (1) is changed to DI (0) and DI (2) is changed to DI (1).
  • the valid data and thereafter are padded with zeros so that it can be seen that there is no valid data after this.
  • the IP packets from the venue B stored in the second buffer 9 are moved to the first buffer 7 (step S27). Since DI (0) is changed to the value of the IP packet from the venue B by updating the transmission source identifier table 5, steps S11, S24, S25, S26, S15, and S16 are performed on the first buffer 7. By doing so, IP packet processing from the venue B is stably continued. That is, even if a plurality of types of packets are mixed at the time of switching, switching can be performed without any problem.
  • an IP packet with a certain type of source identifier is stored in the first buffer 7, and IP packets with other source identifiers are stored in the second buffer 9. .
  • the IP packet with the current transmission source identifier is stored in the first buffer 7 and the IP packet with the new transmission source identifier is stored in the second buffer. 9 can be stored separately. Then, after the processing of the IP packet having the current transmission source identifier is completed, the IP packet having the new transmission source identifier can be moved to the first buffer 7 and the processing can be continued. Therefore, the transmission source can be changed smoothly.
  • two buffers are prepared.
  • three or more buffers may be used to separate each source identifier.
  • the same effect can be obtained by changing the packet storage and packet extraction target buffer without moving the IP packet to the first buffer 7 when the transmission source is switched. Is obtained.
  • the transmission apparatus has been changed from the A venue to the B venue, and from the B venue to the C venue.
  • the transmission source identifier is also changed when the network parameter of one transmission apparatus is changed. The same processing is possible.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

　パケット受信部（４）は、ネットワークパラメータ及び送信元識別子を持つＩＰパケットを受信する。送信元識別子テーブル（５）は、受信したＩＰパケットの送信元識別子を記録する。パケット格納処理部（６）は、受信したＩＰパケットの送信元識別子が送信元識別子テーブル（５）に記録された送信元識別子と一致すれば、ネットワークパラメータに関わらず、受信したＩＰパケットを第１のバッファ（７）に格納させる。パケット引抜転送部（８）は、第１のバッファ（７）に格納されたＩＰパケットを第１のバッファ（７）から引き抜いてパケット転送する。

Description

パケット自動受信装置
　本発明は、受信側でネットワークパラメータを再設定することなく複数の送信装置から送信されたＩＰパケットを混乱なく自動受信することができるパケット自動受信装置に関する。
　複数の送信装置からそれぞれ別の時間帯にＩＰ（インターネットプロトコル）ネットワークを介して１台の受信装置にＩＰパケットが送信される場合がある。通信に用いるＩＰパケットのフォーマットは公知である（例えば、非特許文献１～３参照）。
　ＩＰ通信を行う場合にはＩＰパケットにおいて基本的な接続情報を毎回きちんと設定する必要がある。特に、ＩＰパケットのヘッダ内の送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、送信先ポート番号の設定は必須である。ここでは、これらの送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、送信先ポート番号をネットワークパラメータと呼ぶことにする。従来の受信装置は、受信したＩＰパケットのネットワークパラメータを見てバッファに格納すべきＩＰパケットを選別していた。
　ここで、３カ所の会場Ａ，Ｂ，Ｃからの中継映像を会場ＺにＩＰネットワークを介して伝送するシステムを考える。具体的には、１０：００～１２：００には会場Ａから会場Ｚへ、１２：３０～１４：３０には会場Ｂから会場Ｚへ、１５：００～１７：００には会場Ｃから会場Ｚに対して映像伝送を行う。会場Ａ，Ｂ，Ｃにはそれぞれ映像のＩＰパケットを送信する送信装置が設置され、会場Ｚには各会場から送信されたＩＰパケットを受信する受信装置が設置されている。
　従って、会場Ａ～Ｃからの各中継に先だって、会場Ａでは９：３０～１０：００の間に、会場Ｂでは１２：００～１２：３０の間に、会場Ｃでは１４：３０～１５：００の間に、会場Ｚの受信装置に対して、毎回、ネットワークパラメータの設定変更作業を行う必要があった。
"Internet Protocol RFC791", http://datatracker.ietf.org/doc/rfc791/ "User Datagram Protocol", http://datatracker.ietf.org/doc/rfc768/ "RTP: A Transport Protocol for Real-Time Applications RFC3550", https://datatracker.ietf.org/doc/rfc3550/
　しかし、切り替えのためだけにネットワーク設定の作業要員を確保する必要があり、運用コスト上の問題があった。また、切り替え時間が非常に短い場合には誤りが発生し易いなどの安全運用上の問題があった。一方で、このような毎回の設定変更作業を無くすために自動受信をさせた場合、会場Ａから会場Ｚへの映像中継の最中に誤って会場Ｂから会場Ｚに映像伝送してしまうと、会場Ａから会場Ｚへの本来の中継映像に乱れが発生してしまうという問題が想定される。
　本発明は、上述のような課題を解決するためになされたもので、その目的は受信側でネットワークパラメータを再設定することなく複数の送信装置から送信されたＩＰパケットを混乱なく自動受信することができるパケット自動受信装置を得るものである。
　本発明に係るパケット自動受信装置は、ネットワークパラメータ及び送信元識別子を持つＩＰパケットを受信するパケット受信部と、受信した前記ＩＰパケットの前記送信元識別子を記録する送信元識別子テーブルと、第１のバッファと、受信した前記ＩＰパケットの送信元識別子が前記送信元識別子テーブルに記録された送信元識別子と一致すれば、前記ネットワークパラメータに関わらず、受信した前記ＩＰパケットを前記第１のバッファに格納させるパケット格納処理部と、前記第１のバッファに格納された前記ＩＰパケットを前記第１のバッファから引き抜いてパケット転送し、前記特定の送信元識別子のＩＰパケットが無くなったら前記送信元識別子テーブルを更新するパケット引抜転送部とを備えることを特徴とする。
　本発明により、受信側でネットワークパラメータを再設定することなく複数の送信装置から送信されたＩＰパケットを混乱なく自動受信することができる。
本発明の実施の形態１に係る映像伝送システムを示す図である。 ＩＰパケットの構成を示す図である。 本発明の実施の形態１に係るパケット自動受信装置を示す図である。 本発明の実施の形態１に係るバッファ格納処理部の処理フローを示す図である。 本発明の実施の形態１に係るパケット引抜転送部の処理フローを示す図である。 本発明の実施の形態２に係るパケット自動受信装置を示す図である。 本発明の実施の形態２に係るバッファ格納処理部の処理フローを示す図である。 本発明の実施の形態２に係るパケット引抜転送部の処理フローを示す図である。
　本発明の実施の形態に係るパケット自動受信装置について図面を参照して説明する。同じ又は対応する構成要素には同じ符号を付し、説明の繰り返しを省略する場合がある。
実施の形態１．
　図１は、本発明の実施の形態１に係る映像伝送システムを示す図である。会場Ａ，Ｂ，Ｃにはそれぞれ映像をＩＰパケット化して送信する送信装置１ａ，１ｂ，１ｃが設置され、会場Ｚには各会場から送信されたＩＰパケットを受信するパケット自動受信装置２が設置されている。会場Ａの送信装置１ａは１０：００～１２：００に、会場Ｂの送信装置１ｂは１２：３０～１４：３０に、会場Ｃの送信装置１ｃは１５：００～１７：００に、それぞれ会場Ｚのパケット自動受信装置２に対してＩＰネットワーク３を介して映像伝送を行う。送信装置１ａ，１ｂ，１ｃとパケット自動受信装置２のＩＰアドレスはそれぞれＩＰＡ，ＩＰＢ，ＩＰＣ，ＩＰＺであり、ポート番号はそれぞれＰＮＡ，ＰＮＢ，ＰＮＣ，ＰＮＺである。
　映像送信が時間帯によって会場Ａから会場Ｂへ、又は会場Ｂから会場Ｃへと変更になる。この場合でも、パケット自動受信装置２は受信側でネットワークパラメータを再設定することなく全ての送信装置１ａ，１ｂ，１ｃから送信されたＩＰパケットを混乱なく自動受信することができる。
　図２は、ＩＰパケットの構成を示す図である。インターネット層にＩＰヘッダ、トランスポート層にＵＤＰヘッダ、アプリケーション層にＲＴＰヘッダがそれぞれ設けられている。アプリケーション層において、ＲＴＰヘッダ内のＸビットに１を設定することで、ＲＴＰヘッダの後ろにＲＴＰ拡張ヘッダを挿入して使用することができる。この拡張ヘッダ内はユーザの自由定義領域を含む。
　図３は、本発明の実施の形態１に係るパケット自動受信装置を示す図である。パケット受信部４は、ネットワークパラメータ及び送信元識別子を持つＩＰパケットを受信する。送信元識別子テーブル５は、受信したＩＰパケットの送信元識別子を記録する。ここでは、送信元識別子テーブル５は配列ＤＩのテーブルであり、ＤＩ（０）～ＤＩ（Ｎ－１）までのＮ個の送信元識別子の情報を０番地から順番に最大Ｎ個格納できる。ただし、実施の形態１においてはＮ＝１とし、送信元識別子テーブルに格納する送信元識別子の情報はＤＩ(０)のみとする。
　パケット格納処理部６は、受信したＩＰパケットの送信元識別子が送信元識別子テーブル５の先頭番地に記録された送信元識別子ＤＩ（０）と一致すれば、ネットワークパラメータに関わらず、受信したＩＰパケットを第１のバッファ７に格納させる。パケット引抜転送部８は、第１のバッファ７に格納されたＩＰパケットを第１のバッファ７から引き抜いてパケット転送する。
　送信元識別子は送信側でＩＰパケット内に付与するものであり、ここではＤＩ（Device Identifier）と呼ぶことにする。例えば、送信元識別子はＩＰパケット内のＲＴＰパケットに含まれるＳＳＲＣ（Synchronization Source）である。ＳＳＲＣは乱数で設定されることが多いが、乱数計算の開始点の工夫により全送信装置間で値が重なることは皆無といってよい。または、送信元識別子として、ＲＴＰ拡張ヘッダに記録されたユーザ定義の送信元識別記号を用いてもよい。この場合は、送信装置間で別の値を設定するように予め決めておく必要がある。これらの送信元識別子をネットワークパラメータとは別にＩＰパケットに記録しておく。
　図４は、本発明の実施の形態１に係るバッファ格納処理部の処理フローを示す図である。まず、会場Ａの送信装置１aからパケット自動受信装置２に向かってＩＰパケットが送信されているとする。パケット自動受信装置２を起動した時、パケット格納処理部６は、初期設定として、第１のバッファ７、送信元識別子テーブル５をゼロクリアする（ステップＳ１）。
　次に、パケット受信部４から一つのＩＰパケットを受信する（ステップＳ２）。ＩＰパケットが到着しない時はここで待ち状態になる。ＩＰパケットを受信したら、このＩＰパケット内から送信元識別子を読み取る。読み取った値をＤＩＲとする（ステップＳ３）。送信元識別子テーブル５は、パケット自動受信装置２に到着した全種類の送信元識別子の組み合わせを到着順に追記して格納する。すでに同じ送信元識別子が格納されていた場合には追記しない。即ち実施の形態１では最初に到着した送信元識別子しか記録しない。ステップＳ１で最初にクリアされているので、初めてＩＰパケットが到着した時点では、送信元識別子テーブル５の先頭の送信元識別子ＤＩ（０）は０である（ステップＳ４）。そこで、ステップＳ３で読み取った送信元識別子をＤＩ（０）に記録する（ステップＳ５）。そして、このＩＰパケットを第１のバッファ７に格納する（ステップＳ６）。
　２回目に受け取ったＩＰパケットが、上記の１回目で受け取ったＩＰパケットの送信元識別子と同一であれば（ステップＳ７）、そのＩＰパケットを第１のバッファ７に格納する（ステップＳ６）。このようにして、同一送信元識別子のＩＰパケットを次々と、第１のバッファ７に格納する。
　会場Ａからの受信（１０：００～１２：００）が会場Ｂからの受信（１２：３０～１４：３０）に代わる場合、会場Ａからの受信が１２：００に終了した時点でＩＰパケットの受信待ちになる（ステップＳ２）。この場合、現在使われている送信元識別子ＤＩ（０）がゼロクリアされる。この処理は後述するようにパケット引抜転送部８が行う。
　ところが、万一、会場Ｚのパケット自動受信装置２が会場Ａの送信装置１ａからＩＰパケットを受信している最中に、会場Ｂの送信装置１ｂが誤ってＩＰパケットを送信した場合、送信元識別子が処理中の送信元識別子と異なるため（ステップＳ７）、そのＩＰパケット自身は廃棄する（ステップＳ８）。
　図５は、本発明の実施の形態１に係るパケット引抜転送部の処理フローを示す図である。第１のバッファ７からＩＰパケットを読み込む（ステップＳ１１）。ただし、第１のバッファ７にＩＰパケットが入っていなければ（ステップＳ１２）、ＤＩ（０）＝０のように送信元識別子テーブル５を更新して（ステップＳ１３）、読み込みを繰り返す（ステップＳ１１、Ｓ１２、Ｓ１３）。第１のバッファ７にＩＰパケットが１つでも入っていれば、読み込んだＩＰパケットを第１のバッファ７から取り出してパケット転送する（ステップＳ１４）。
　以上説明したように、本実施の形態では、受信したＩＰパケットの送信元識別子が送信元識別子テーブル５に記録された送信元識別子と一致すれば、ネットワークパラメータに関わらず、受信したＩＰパケットを第１のバッファ７に格納させる。これにより、受信したＩＰパケットのネットワークパラメータを無視し、到着した全てのＩＰパケットを受信することができる。
　また、既に受信しているＩＰパケットの送信元識別子と一致する送信元識別子を持つＩＰパケットのみを処理するため、ＩＰパケットのフォーマットを遵守した上で受信側でネットワークパラメータを再設定することなく複数の送信装置から送信されたＩＰパケットを混乱なく自動受信することができる。従って、会場Ｚ側で想定しないＩＰパケットが到着しても、会場Ａから会場Ｚへの中継映像には何ら影響が出ない。
　また、会場Ａからの中継から会場Ｂからの中継へと送信元が変更になった場合には、これまでの送信元識別子を持つＩＰパケットが到着しなくなり、また、別の送信元識別子を持つＩＰパケットが到着するようになる。その場合には、新しい送信元識別子を持ったＩＰパケットのみを受信し続ける。これにより、送信元が変わっても、受信側でネットワークパラメータを再設定することなく、新たな送信元の受信を続けることができる。
実施の形態２．
　図６は、本発明の実施の形態２に係るパケット自動受信装置を示す図である。第１のバッファ７だけでなく、第２のバッファ９も設けられている。パケット格納処理部６は、ある１種類の送信元識別子のＩＰパケットを第１のバッファ７に格納させ、それ以外の送信元識別子のＩＰパケットを第２のバッファ９に格納させる。パケット引抜転送部８は、第２のバッファ９から特定の送信元識別子のＩＰパケットを第１のバッファ７に転送する。
　図７は、本発明の実施の形態２に係るバッファ格納処理部の処理フローを示す図である。実施の形態１の処理フローとの違いについて説明する。パケット格納処理部６は、初期設定として、第１のバッファ７及び送信元識別子テーブル５だけでなく第２のバッファ９もゼロクリアする（ステップＳ２１）。
　会場Ａからの受信に引き続き会場Ｂから受信開始すると、読み取った送信元識別子が処理中の送信元識別子ＤＩ（０）と異なる（ステップＳ７）。従って、その送信元識別子を送信元識別子テーブル５に追記する（ステップＳ２２）。この際に送信元識別子テーブル５の中の有効データの最後に１行追加する。それ以降が未使用領域であればそこには０が入っている。これにより受信した全ての送信元識別子が送信元識別子テーブル５に記録される。
　実施の形態１では、Ａ会場からの送信とＢ会場からの送信の間に３０分間のパケット受信の休止がある場合を想定していた。即ち会場Ａからの受信終了後、パケットの受信待ちとなった状態で（ステップＳ２）、会場Ｂからの受信が開始される。この場合、ＤＩ（０）が使われているので送信元識別子テーブル５にＤＩ（１）が追記される。会場ＢからのＩＰパケットを受けるためには、ＤＩ（０）にＤＩ（１）の値を設定する必要がある。この送信元識別子テーブル５の更新は後述するようにパケット引抜転送部８が行う。
　一方で、例えばＡ会場からの送信が１０：００－１２：３０、Ｂ会場からの送信が１２：２９－１４：３０の場合には、切り替え時に多少の重なりがある。そこで、実施の形態２では第２のバッファ９を追加し、実施の形態１のようにＩＰパケットを廃棄せずに、Ｂ会場からのＩＰパケットを第２のバッファ９に蓄積して保存しておく（ステップＳ２３）。
　図８は、本発明の実施の形態２に係るパケット引抜転送部の処理フローを示す図である。実施の形態１と同様に、第１のバッファ７内に蓄積されたＡ会場からのＩＰパケットを読み込む（ステップＳ１１、Ｓ２４）。第１のバッファ７にＩＰパケットが１つでも入っていれば、１つのＩＰパケットの内容を読み取る（ステップＳ２５）。そのＩＰパケットの送信元識別子ＤＩＲが、送信元識別子テーブル５の先頭番地に記録された送信元識別子ＤＩ（０）と一致すれば（ステップＳ２６）、読み込んだＩＰパケットを第１のバッファ７から取り出してパケット転送する（ステップＳ１５）。取り出したＩＰパケットは第１のバッファ７から消える。
　第１のバッファ７内にある全てのＩＰパケットについてＤＩ（０）との照合を繰り返す（ステップＳ１１，Ｓ２４，Ｓ２５，Ｓ２６，Ｓ１５，Ｓ１６）。全て照合が終了し、第１のバッファ７内に、送信元識別子ＤＩ（０）を持つＩＰパケットが無くなり取り出しが完了したら、送信元識別子テーブル５を更新する（ステップＳ１７）。例えば、ＤＩ（１）をＤＩ（０）に、ＤＩ（２）をＤＩ（１）のように、配列ＤＩの内容を１番地ずつずらす。有効データ以降が０埋めし、これ以降に有効データが入っていないことが分かるようにしておく。
　その後、第２のバッファ９内に蓄積されたＢ会場からのＩＰパケットを第１のバッファ７に移動する（ステップＳ２７）。送信元識別子テーブル５の更新により、ＤＩ（０）がＢ会場からのＩＰパケットの値に変更されるため、第１のバッファ７に対してステップＳ１１，Ｓ２４，Ｓ２５，Ｓ２６，Ｓ１５，Ｓ１６を実施することで、Ｂ会場からのＩＰパケット処理が安定して続行される。即ち、切り替え時に複数種類のパケットが混在しても問題なく切り替えることができる。
　以上説明したように、本実施の形態では、ある１種類の送信元識別子のＩＰパケットを第１のバッファ７に格納させ、それ以外の送信元識別子のＩＰパケットを第２のバッファ９に格納させる。これにより、送信元の変わり目等で送信元識別子が異なるパケットが混在した場合にも、現在の送信元識別子のＩＰパケットを第１のバッファ７に、新しい送信元識別子のＩＰパケットを第２のバッファ９に分別して格納しておくことができる。そして、現在の送信元識別子を持つＩＰパケットの処理が終わってから新しい送信元識別子を持つＩＰパケットを第１のバッファ７に移動して処理を連続させることができる。従って、送信元の変更をスムーズに行うことができる。
　なお、実施の形態２では２つのバッファを用意したが、３つ以上のバッファを用いて送信元識別子ごとに分離することもできる。また、送信元識別子ごとにバッファを分離した場合には、送信元が切り替わった際に第１のバッファ７にＩＰパケットを移動しなくても、パケット格納およびパケット引抜対象バッファを変えれば同様の効果が得られる。また、上記説明では、送信装置がＡ会場からＢ会場へ、Ｂ会場からＣ会場へと変わってゆく場合を説明したが、１つの送信装置のネットワークパラメータが変わってゆく場合も送信元識別子が変われば同様な処理が可能である。
２　パケット自動受信装置、４　パケット受信部、５　送信元識別子テーブル、６　パケット格納処理部、７　第１のバッファ、８　パケット引抜転送部、９　第２のバッファ

Claims (4)

  1. 　ネットワークパラメータ及び送信元識別子を持つＩＰパケットを受信するパケット受信部と、
    　受信した前記ＩＰパケットの前記送信元識別子を記録する送信元識別子テーブルと、
    　第１のバッファと、
    　受信した前記ＩＰパケットの送信元識別子が前記送信元識別子テーブルに記録された送信元識別子と一致すれば、前記ネットワークパラメータに関わらず、受信した前記ＩＰパケットを前記第１のバッファに格納させるパケット格納処理部と、
    　前記第１のバッファに格納された前記ＩＰパケットを前記第１のバッファから引き抜いて転送し、前記特定の送信元識別子のＩＰパケットが無くなったら前記送信元識別子テーブルを更新するパケット引抜転送部とを備えることを特徴とするパケット自動受信装置。
  2. 　第２のバッファを更に備え、
    　前記パケット格納処理部は、ある１種類の送信元識別子のＩＰパケットを前記第１バッファに格納させ、それ以外の送信元識別子のＩＰパケットを前記第２のバッファに格納させることを特徴とする請求項１に記載のパケット自動受信装置。
  3. 　前記パケット引抜転送部は、前記第２のバッファから特定の送信元識別子のＩＰパケットを前記第１のバッファに転送し、前記第１のバッファに格納された前記ＩＰパケットのうち、前記送信元識別子テーブルに記録された送信元識別子と一致する送信元識別子を持つＩＰパケットを前記第１のバッファから引き抜いてパケット転送することを特徴とする請求項２に記載のパケット自動受信装置。
  4. 　前記送信元識別子は、前記ＩＰパケット内のＲＴＰヘッダに含まれるＳＳＲＣ（Synchronization Source）、及び、ＲＴＰ拡張ヘッダに記録された送信元識別記号の少なくとも一つであることを特徴とする請求項１～３の何れか１項に記載のパケット自動受信装置。
PCT/JP2014/081207 2014-03-25 2014-11-26 パケット自動受信装置 WO2015145869A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/118,062 US10333834B2 (en) 2014-03-25 2014-11-26 Automatic packet reception apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2014061729A JP5733445B1 (ja) 2014-03-25 2014-03-25 パケット自動受信装置
JP2014-061729 2014-03-25

Publications (1)

Publication Number Publication Date
WO2015145869A1 true WO2015145869A1 (ja) 2015-10-01

Family

ID=53486890

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/081207 WO2015145869A1 (ja) 2014-03-25 2014-11-26 パケット自動受信装置

Country Status (3)

Country Link
US (1) US10333834B2 (ja)
JP (1) JP5733445B1 (ja)
WO (1) WO2015145869A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7494494B2 (ja) * 2020-03-09 2024-06-04 オムロン株式会社 通信制御機器および通信制御機器の制御方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000201125A (ja) * 1999-01-08 2000-07-18 Nec Corp ディジタル放送受信装置
JP2005045742A (ja) * 2003-07-25 2005-02-17 Sony Corp 通話装置及び通話方法、並びに通話システム
JP2006522520A (ja) * 2003-03-31 2006-09-28 ソニー・ユナイテッド・キングダム・リミテッド オーディオ信号処理
JP2012195864A (ja) * 2011-03-17 2012-10-11 Fujitsu Ltd 伝送システム及び伝送装置、並びに伝送方法
JP2013042492A (ja) * 2011-08-11 2013-02-28 Polycom Inc 常駐表示式ビデオ会議においてビデオストリームを切替える方法およびシステム

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6430183B1 (en) * 1997-09-18 2002-08-06 International Business Machines Corporation Data transmission system based upon orthogonal data stream mapping
US20020064164A1 (en) * 2000-10-06 2002-05-30 Barany Peter A. Protocol header construction and/or removal for messages in wireless communications
KR100552509B1 (ko) * 2003-10-13 2006-02-14 삼성전자주식회사 이동 애드 혹 네트워크에서의 브로드캐스트 데이터 처리방법
US7117112B2 (en) * 2004-09-22 2006-10-03 Research In Motion Limited Method and system for the interactive testing of assembled wireless communication devices
US20080267081A1 (en) * 2007-04-27 2008-10-30 Guenter Roeck Link layer loop detection method and apparatus
US8760492B2 (en) 2009-01-30 2014-06-24 Polycom, Inc. Method and system for switching between video streams in a continuous presence conference

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000201125A (ja) * 1999-01-08 2000-07-18 Nec Corp ディジタル放送受信装置
JP2006522520A (ja) * 2003-03-31 2006-09-28 ソニー・ユナイテッド・キングダム・リミテッド オーディオ信号処理
JP2005045742A (ja) * 2003-07-25 2005-02-17 Sony Corp 通話装置及び通話方法、並びに通話システム
JP2012195864A (ja) * 2011-03-17 2012-10-11 Fujitsu Ltd 伝送システム及び伝送装置、並びに伝送方法
JP2013042492A (ja) * 2011-08-11 2013-02-28 Polycom Inc 常駐表示式ビデオ会議においてビデオストリームを切替える方法およびシステム

Also Published As

Publication number Publication date
US20170012864A1 (en) 2017-01-12
JP2015186091A (ja) 2015-10-22
US10333834B2 (en) 2019-06-25
JP5733445B1 (ja) 2015-06-10

Similar Documents

Publication Publication Date Title
US10015091B2 (en) Method of low-bandwidth data transport
US9736316B2 (en) Network address translation traversal system and method for real-time communications
CN105187440A (zh) 使用udp协议传输视频数据的方法及系统
US8179795B2 (en) Communication terminal apparatus, distribution apparatus, error notification method, and error notification program
US8068515B2 (en) Faster multimedia synchronization of broadcast streams using router caching of RTCP packets
US10129163B2 (en) Methods and apparatus for preventing head of line blocking for RTP over TCP
JP5733445B1 (ja) パケット自動受信装置
US9749262B2 (en) Packet processing method and forwarding element
TWI660609B (zh) 識別網路封包內部目的地的方法及裝置
JP2009015392A (ja) 通信装置および通信方法
US9282172B2 (en) System and method for relaying data based on a modified reliable transport protocol
JP5812612B2 (ja) 通信制御装置及びプログラム、並びに、通信システム
JP6146088B2 (ja) ゲートウェイ装置、通信装置、及び通信コネクション管理方法
WO2015184979A1 (zh) 处理报文、发送信息、接收信息的方法及装置
JP2009135772A (ja) ルータ装置
JP6128132B2 (ja) 通信装置、制御装置、通信システム、パケット処理方法、通信装置の制御方法及びプログラム
EP2802117B1 (en) A system and method for relaying data based on a modified reliable transport protocol
US10142126B2 (en) Scalable dynamic overlay tunnel management
JP5992348B2 (ja) 負荷分散システム、負荷分散方法
KR20130070330A (ko) 모바일 환경에서 에이치티티피 라이브 스트리밍 프토토콜을 알티에스피 프로토콜로 변환하는 시스템 및 그 방법
US20170242738A1 (en) Static message placement in queues based on an apriori defined placement plan
JP2021114795A (ja) コンテンツ配信システム、コンテンツ配信装置、及び方法
US20170104606A1 (en) Home gateway ds-lite multicast method and device
JP2010288167A (ja) ネットワーク中継装置
JP2008295082A (ja) ゲートウェイ装置、送信方法、受信方法および情報記録媒体

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14887110

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15118062

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14887110

Country of ref document: EP

Kind code of ref document: A1