WO2010082509A1 - Sctp通信方法 - Google Patents

Sctp通信方法 Download PDF

Info

Publication number
WO2010082509A1
WO2010082509A1 PCT/JP2010/000268 JP2010000268W WO2010082509A1 WO 2010082509 A1 WO2010082509 A1 WO 2010082509A1 JP 2010000268 W JP2010000268 W JP 2010000268W WO 2010082509 A1 WO2010082509 A1 WO 2010082509A1
Authority
WO
WIPO (PCT)
Prior art keywords
streams
node
nodes
stream
association
Prior art date
Application number
PCT/JP2010/000268
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 US13/144,824 priority Critical patent/US8908519B2/en
Priority to JP2010546606A priority patent/JP5246271B2/ja
Publication of WO2010082509A1 publication Critical patent/WO2010082509A1/ja

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/72Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/72Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/726Reserving resources in multiple paths to be used simultaneously
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/76Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/80Actions related to the user profile or the type of traffic
    • H04L47/801Real time traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14Multichannel or multilink protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]

Definitions

  • the present invention relates to an SCTP (Stream Control Transmission Protocol) communication method applied to a communication system composed of a plurality of nodes, and more particularly to allocation of the number of streams used in each association established in each node.
  • SCTP Stream Control Transmission Protocol
  • Patent Document 1 discloses a transport layer protocol that supports multihoming.
  • the multihomed host has a plurality of network interfaces and can have a plurality of addressable IP addresses.
  • SCTP also supports multi-streaming.
  • the number of streams used in each association is statically assigned, and the number of streams determined at the time of establishing the association has been used until communication is disconnected.
  • the stream number assignment procedure will be described.
  • FIG. 13 shows a procedure for assigning the number of streams between SCTP nodes (hereinafter referred to as “nodes”) X and Y in steps ST301 to ST303.
  • nodes SCTP nodes
  • the node X that issues a connection request sends INIT (Initiation) to the node Y.
  • INIT Initiation
  • Step ST302 the node Y that has received INIT returns INIT_ACK (Initiation Acknowledgment) to the node X.
  • INIT_ACK Initiation Acknowledgment
  • Step ST303 the node X compares the requested number of streams OS (Number of Outbound Streams) described in the received INIT_ACK with the allowable number of streams MIS (Number of Inbound Streams), and sets the minimum number as the number of streams. decide.
  • the requested stream number OS is the number of streams that are desired to be used in each association
  • the allowable stream number MIS is the maximum number of streams that can be allowed by each node.
  • the advantage of the communication method using a plurality of streams is that packet transmission can be continued in a stream other than the stream for which packet retransmission is being performed, compared to a communication method using a single stream. That is, the use of a plurality of streams can be expected to improve the data communication speed in the application layer.
  • the maximum number of streams used by each node is determined in consideration of the trade-off between the number of streams and the processing capacity allocated to each stream. That is, each node needs to efficiently allocate the limited number of streams to each association.
  • the number of streams determined at the time of establishing each association is statically allocated to each node and is maintained until communication is disconnected, so application requests, changes in communication status, etc.
  • the number of streams cannot be changed. For this reason, even if a stream that can be used during communication is generated, there is a problem in that the communication speed cannot be improved using the stream.
  • the communication speed between the node Q and the node R remains low. That is, even if a surplus stream occurs in another node, the conventional SCTP communication method cannot use the available stream, and the communication speed cannot be improved.
  • the number of streams determined at the time of initiation is statically assigned to each node and maintained until communication is disconnected, which occurs due to application requests, changes in communication status, etc.
  • the number of streams cannot be dynamically changed by effectively using an empty stream, and the communication speed cannot be improved.
  • the present invention has been made in view of the above circumstances, and dynamically updates the number of streams used for associations established between nodes, and effectively enables streams that greatly affect the communication speed in large-scale communication.
  • An object of the present invention is to provide an SCTP communication method that can be used to improve communication speed.
  • each node when each node receives INIT describing the number of requested streams, it returns INIT_ACK describing the number of allowable streams, thereby
  • INIT_ACK describing the number of allowable streams
  • the SCTP communication system constructs an association using at least one stream between a plurality of nodes in the communication system.
  • Each node detects the occurrence of an empty stream, a first transmission unit that transmits INIT describing the number of requested streams, a second transmission unit that transmits INIT_ACK describing the number of allowable streams when receiving INIT, and
  • an additional request message in which the number of additional request streams is described is received, an additional confirmation message is transmitted, so that the number of streams used in the association established with another node is changed.
  • the node according to the present invention is compliant with the SCTP communication method for constructing an association using at least one stream, and receives a INIT that includes a first transmitter that transmits an INIT describing the number of requested streams.
  • a second transmission unit that transmits INIT_ACK describing the number of allowable streams, and when an addition request message describing the number of additional request streams is detected when the occurrence of an empty stream is detected, an additional confirmation message is transmitted, Therefore, a control unit is provided that changes the number of streams used in the association established with another node.
  • the number of streams used in the association established between nodes can be dynamically changed without disconnecting communication.
  • the number of streams in large-scale communication can be effectively used to improve the communication speed.
  • FIG. 4 is a diagram showing a state where an empty stream generated in FIG. 3 is additionally allocated between nodes B and C. As shown in FIG. 2 to FIG. 4, when a free stream occurs, it is a sequence diagram showing a procedure for detecting it and assigning it to another node.
  • FIG. 8 is a diagram showing a state where the number of streams used between nodes D and E is reduced in FIG.
  • FIG. 9 is a diagram showing a state where the surplus stream generated in FIG. 8 is recognized as an empty stream and assigned between nodes E and F. As shown in FIGS. 7 to 9, when a surplus stream is detected, it is a sequence diagram showing a procedure for assigning it to another node.
  • FIG. As a first example of a conventional SCTP communication method, it is a diagram illustrating a state in which nodes K and M communicate with a node L having the number of usable streams “5”. In FIG.
  • FIG. 15 it is a figure which shows the condition where communication between the node K and the node L was complete
  • FIG. 17 it is a diagram illustrating a state in which nodes P and R communicate with a node Q whose number of usable streams is “5”.
  • FIG. 17 it is a figure which shows the condition where two streams became unnecessary by communication between the node P and the node Q.
  • FIG. 1 is a block diagram illustrating a configuration of a node 1 provided in a communication system to which an SCTP communication method according to a first embodiment of the present invention is applied.
  • the node 1 includes a first transmission unit 2, a second transmission unit 3, and a control unit 4.
  • the first transmission unit 2 is used when an SCTP link (that is, “association”) is established between nodes, and a communication start request to another node and a request stream number OS are set to INIT (Initiation). Send as.
  • SCTP link that is, “association”
  • the second transmission unit 3 is used when constructing an SCTP association between the nodes.
  • the INIT_ACK Initiation Acknowledgment
  • the node Reply to the node.
  • the control unit 4 communicates with other nodes using the minimum number of streams based on the requested number of streams OS and the allowable number of streams MIS. When the control unit 4 detects an empty stream, it notifies the number of empty streams to other nodes. In response to this, when the number of additional request streams is transmitted from another node, the control unit 4 calculates the minimum number of streams based on the number of empty streams and the number of additional request streams and uses it for communication with other nodes. Change the number of streams dynamically.
  • control unit 4 may control the first transmission unit 2 independently to transmit the number of empty streams to other nodes at a predetermined cycle.
  • the control unit 4 may control the second transmission unit 3 independently to transmit the number of additional request streams from another node.
  • the communication system includes a plurality of nodes 1 and communicates with each other to establish an SCTP association. At that time, the node 1 determines the number of streams used in the association and starts communication.
  • nodes A, B, and C having the same configuration as the node 1 are connected.
  • the application ends, the association between the nodes A and B becomes unnecessary, and the association is released. That is, the three streams used between the node A and the node B are vacated.
  • the stream assignment procedure shown in FIG. 5 is executed, and thus an empty stream generated due to the cancellation of the association is assigned to another association.
  • the number of streams between the node B and the node C is changed from “2” to “3”, thereby improving the communication speed of both.
  • Step ST101 The node A transmits an INIT requesting the number of streams to be used in the association to the node B.
  • Step ST102 The node B returns INIT_ACK indicating the upper limit value of the number of streams to the node A as a response to the INIT received in step ST101.
  • Step ST103 The node C transmits INIT requesting the number of streams to be used in the association to the node B.
  • Step ST104 The node B returns INIT_ACK indicating the upper limit value of the number of streams to the node C as a response to the INIT received in step ST103.
  • Step ST105 When the association between the nodes A and B becomes unnecessary due to the termination of the application, SHUTDOWN indicating that the association is released is transmitted from the node A to the node B.
  • Step ST106 The node B returns SHUTDOWN_ACK to the node A as a response to SHUTDOWN received in step ST105.
  • the three streams used in the association between the nodes A and B are vacant.
  • Step ST107 The node B recognizes that three empty streams have occurred due to the cancellation of the association between the nodes A and B. That is, the node B recognizes that three streams that have been used with the node A so far are free.
  • Step ST108 The node B notifies the node C of a vacancy occurrence message indicating that a vacant stream has occurred.
  • a vacancy occurrence message having the packet format shown in FIG. 6 is transmitted from node B to node C.
  • Step ST110 The node B that has received the addition request message in step ST109 transmits an addition confirmation message indicating the upper limit value of the current usable stream number to the node C.
  • This addition confirmation message uses the same packet format as INIT_ACK. This is the same as using the same packet format as INIT for the add request message. That is, the type value differs between the addition confirmation message and INIT_ACK.
  • Step ST111 The node B allocates an additional stream with the node C. Accordingly, as shown in FIG. 4, the number of streams can be increased from “2” to “3” without the association between the nodes B and C being interrupted.
  • the node B transmits a vacancy occurrence message to the node C at the timing when it detects that a vacant stream has occurred with the node A.
  • the vacancy occurrence message may be transmitted at a predetermined cycle.
  • each node may simultaneously transmit a vacancy occurrence message indicating the occurrence of an empty stream to another node at the time of data transmission.
  • the SCTP communication method Similar to the first embodiment, the configuration of the node 1 is also used in the second embodiment, but the function is different.
  • the control unit 4 of the node 1 calculates the number of surplus streams based on the current communication amount and the number of used streams, recognizes the number of surplus streams as the number of free streams, and notifies the other nodes.
  • the second embodiment is the same as the first embodiment.
  • FIG. 10 is a sequence diagram illustrating a procedure for recognizing a surplus stream generated when the number of streams used in the association is reduced as an empty stream and allocating it to another association in the SCTP communication method according to the second embodiment.
  • Step ST201 The node D transmits an INIT requesting the number of streams to be used in the association to the node E.
  • Step ST202 The node E returns INIT_ACK indicating the upper limit of the number of streams to the node D as a response to the INIT received in step ST201.
  • Step ST203 The node F transmits an INIT requesting the number of streams to be used in the association to the node E.
  • Step ST204 The node E returns INIT_ACK indicating the upper limit value of the number of usable streams to the node F as a response to the INIT received in step ST203.
  • the upper limit value of the number of streams of the node E is “5” and three streams are used with the node D, the upper limit value of the number of usable streams is “2”.
  • an association is established between the nodes E and F with two streams as shown in FIG.
  • Step ST206 The node D transmits a release request message to the node E in order to release the recognized surplus stream.
  • a release request message is created in the packet format shown in FIG. 11, and “2” is described in the number of surplus streams RS (Number of Reducing Streams).
  • Step ST207 Upon receiving the release request message in step ST206, step E returns a release confirmation message to the node D to confirm the surplus stream to be released.
  • the number of surplus streams to be allocated is described in the release confirmation message.
  • a release confirmation message is created in the packet format shown in FIG. 12, and the number of surplus streams assigned to the number of surplus streams RS (Number of Reducing Streams) is described.
  • Step ST208 Upon receiving the release confirmation message, the node D releases only the surplus stream, maintains the association with the remaining stream, and continues the communication with the node E. Node E recognizes the occurrence of an empty stream in step ST208.
  • Step ST209 The node E transmits to the node F a vacancy occurrence message indicating that a vacant stream has occurred.
  • the vacancy occurrence message may be transmitted in a predetermined cycle.
  • the current number of free streams is described in the free space generation message.
  • Step ST211 Upon receiving the addition request message in step ST210, the node E returns an addition confirmation message indicating the upper limit value of the number of usable streams to the node F. As a result, as shown in FIG. 9, the number of streams is increased from “2” to “3” without the association between the nodes E and F being interrupted.
  • the present invention is applied to an SCTP-compliant communication system that establishes an association between a plurality of nodes and performs communication.
  • the present invention is also applicable to a communication system between nodes that comply with other communication protocols. .

Landscapes

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

Abstract

 複数のノードにより構成されたSCTP通信システムにおいて、ノード間に少なくとも1本のストリームを使用してアソシエーションを構築して通信を行う際、空きストリームや余剰ストリームの発生が検出され、かつ、追加要求ストリーム数を記述した追加要求メッセージを受信すると、各ノードは他のノードに対して追加確認メッセージを送信し、以って、両者間のアソシエーションで使用されるストリーム数を変更する。即ち、ノード間で使用されるストリーム数を通信切断することなく動的に変更することにより、大規模通信におけるストリーム数を有効活用し、以って、通信速度を向上することができる。

Description

SCTP通信方法
 本発明は、複数のノードよりなる通信システムに適用されるSCTP(Stream Control Transmission Protocol)通信方法に関し、特に各ノードで確立される各アソシエーションで用いられるストリーム数の割り当てに関する。
 本願は、2009年1月19日、日本国に出願された特願2009-9201号に基づき優先権を主張し、その内容をここに援用する。
 近年、種々のSCTP通信方法が開発されており、特許文献1はマルチホーミングをサポートするトランスポート層プロトコールを開示している。ここで、マルチホームホストは複数のネットワークインターフェイスを持ち、アドレス指定可能な複数のIPアドレスを持つことができる。また、SCTPはマルチストリーミングをサポートしている。
 従来のSCTPでは、各アソシエーションで用いるストリーム数を静的に割り当てており、アソシエーション構築時に決定したストリーム数を通信が切断されるまで使用しつづけていた。図13を参照して、ストリーム数割当て手順を説明する。
 図13では、ステップST301~ST303によるSCTPノード(以下、「ノード」と呼ぶ)X及びY間におけるストリーム数の割当て手順を示している。ステップST301において、接続要求を行なうノードXがINIT(Initiation)をノードYに送る。
 ステップST302において、INITを受信したノードYはINIT_ACK(Initiation Acknowledgement)をノードXに返信する。
ステップST303において、ノードXは受信したINIT_ACKに記述されている要求ストリーム数OS(Number of Outbound Streams)と許容ストリーム数MIS(Number of Inbound Streams)を比較し、両者の中で最小数をストリーム数として決定する。要求ストリーム数OSは、各アソシエーションで使用したいストリーム数であり、許容ストリーム数MISは各ノードが許容できる最大ストリーム数である。
 上記の手順により、各アソシエーション確立時のストリーム数を用いて通信を開始し、以後、そのストリーム数を変更することなく通信が切断されるまで維持する。
 例えば、ノードXの要求ストリーム数OSが「5」であり、ノードYの許容ストリーム数MISが「3」の場合、図14に示すように3本のストリームを用いて通信を開始する。
 次に、ノード間で設定されるストリーム数と通信速度(即ち、アプリケーション層の通信速度)の関係について説明する。SCTPではストリーム単位でパケットの到達確認を行なっており、パケット消滅時にはそのパケットが再送される。このため、パケット再送時、そのストリームにおいて再送パケット以降のパケットを送信することができない。
 複数のストリームを用いた通信方法の利点は、単一のストリームを用いた通信方法と比較して、パケット再送を実行しているストリーム以外のストリームにてパケット送信を続行できる点である。即ち、複数のストリームを用いることにより、アプリケーション層でのデータ通信速度の向上が期待できる。
 しかし、複数のストリームを用いた通信方法においても、データ量がストリーム数に比べて極めて多い場合には、パケット再送に起因する伝送遅延が大きくなり、通信速度が低下してしまう可能性がある。そこで、ストリーム数と各ストリームに割り当てる処理能力のトレードオフを考慮して、各ノードが用いる最大ストリーム数を決定する。即ち、各ノードはその限られたストリーム数を効率よく各アソシエーションに割り当てる必要がある。
特表2004-535133号公報
 上記のように、従来のSCTP通信方法は各アソシエーション構築時に決定したストリーム数を各ノードに静的に割り当てて通信が切断されるまで維持しつづけているので、アプリケーションの要求や通信状況の変化等によりストリーム数を変更することができない。このため、通信途中で利用可能となったストリームが生じたとしても、そのストリームを利用して通信速度を向上することができないという問題点がある。
 次に、上記の問題点について詳細に説明する。
 第1の例について図15及び図16を参照して説明する。ここでは、3つのノードK、L、Mにより通信が行われており、ノードLの使用可能なストリーム数の上限値が5本(MIS=5)であり、ノードKがノードLに対して3本のストリームを要求(OS=3)するINITを送信し、ノードLはその要求を受諾してアソシエーションを構築するものとする。
 次に、ノードMからノードLに対して3本のストリームを要求(OS=3)するINITを送信したとする。このとき、ノードLが使用できるストリーム数はMIS=5-3=2なので、ノードLとノードMの間で確立されるアソシエーションに使用できるストリーム数は「2」に限定される。即ち、3本のストリームを要求したノードMは、2本のストリームしか利用できないため、必然的に各ストリームで流れるデータ量が多くなり、ノードLとノードLとの間の通信速度が遅くなる。
 その後、図16に示すようにノードKとノードLとの間でアプリケーションが終了すると、両者の間に確立したアソシエーションが不要となり、アソシエーションが解除される。このとき、ノードKとノードLの間で用いた3本のストリームは空きとなり他のノードで使用可能となる。この場合、利用可能となったストリームをノードLとノードMの間のアソシエーションに割り当てて両者間の通信速度を向上せしめることが考えられる。
 しかし、従来のSCTP通信方法では、アソシエーション構築時に決定したストリーム数を各ノードに静的に割り当てて通信が切断されるまで維持するため、通信途中においてストリーム割当てを変更することができない。これにより、ノードLとノードMの間のアソシエーションでは少ないストリーム数で多くのデータを流した状態が続くこととなり、通信速度は遅いままである。即ち、他のノードでの通信終了により空きストリームが生じたとしても、従来のSCTP通信方法ではその利用可能なストリームを用いることができず、通信速度を向上することができない。
 次に、第2の例について図17及び図18を参照して説明する。ここでは、3つのノードP、Q、Rにより通信が行われており、ノードQの使用可能なストリーム数の上限値を5本(MIS=5)とする。図17に示すように、ノードPとノードQとの間に3本のストリームを用いたアソシエーションを構築し、ノードQとノードRの間に2本のストリームを用いたアソシエーションを構築したものとする。このとき、ノードP、Q間並びにノードQ、R間において、各ストリームに流れるデータ量が多いものとする。
 その後、図18に示すように、ノードPとノードQとの間を流れるデータ量が減少し、1本のストリームでも十分に両者の通信を処理できるようになったとする。この場合、ノードPとノードQの間のアソシエーションで余剰になった2本のストリームをノードQとノードRの間のアソシエーションに割り当てて両者間の通信速度を向上せしめることが考えられる。
 しかし、従来のSCTP通信方法では通信途中でストリーム数を変更できないため、ノードQとノードRの間の通信速度は遅いままとなってしまう。即ち、他のノードで余剰ストリームが発生したとしても、従来のSCTP通信方法ではその利用可能なストリームを用いることができず、通信速度を向上することができない。
 上記のように、従来のSCTP通信方法ではイニシエーション時に決定したストリーム数を各ノードに静的に割り当てて通信が切断されるまで維持しているため、アプリケーションの要求や通信状況の変化等により発生した空きストリームを有効に利用して、動的にストリーム数を変更することができず、通信速度を向上することができない。
 本発明は上記の事情に鑑みてなされたものであり、ノード間に構築されるアソシエーションに用いられるストリーム数を動的に更新するものであり、大規模通信における通信速度に大きく影響するストリームを有効活用し、以って、通信速度を向上せしめたSCTP通信方法を提供することを目的とする。
 本発明に係るSCTP通信方法は、複数のノードより構成された通信システムにおいて、各ノードは、要求ストリーム数を記述したINITを受信すると、許容ストリーム数を記述したINIT_ACKを返信し、以って、他のノードとの間に少なくとも1本のストリームを使用したアソシエーションを確立し、空きストリームの発生が検出され、かつ、追加要求ストリーム数が記述された追加要求メッセージを受信すると、各ノードは追加確認メッセージを送信し、以って、他のノードとの間に構築したアソシエーションで使用されるストリーム数を変更する。
 本発明に係るSCTP通信システムは、通信システムにおいて複数のノード間で少なくとも1本のストリームを使用したアソシエーションを構築する。各ノードは、要求ストリーム数を記述したINITを送信する第1の送信部と、INITを受信すると、許容ストリーム数を記述したINIT_ACKを送信する第2の送信部と、空きストリームの発生が検出され、かつ、追加要求ストリーム数が記述された追加要求メッセージを受信すると、追加確認メッセージを送信し、以って、他のノードとの間に構築されたアソシエーションで使用されるストリーム数を変更する制御部を具備する。
 本発明に係るノードは、少なくとも1本のストリームを使用してアソシエーションを構築するSCTP通信方法に準拠しており、要求ストリーム数を記述したINITを送信する第1の送信部と、INITを受信すると、許容ストリーム数を記述したINIT_ACKを送信する第2の送信部と、空きストリームの発生が検出され、かつ、追加要求ストリーム数が記述された追加要求メッセージを受信すると、追加確認メッセージを送信し、以って、他のノードとの間に構築されたアソシエーションで使用されるストリーム数を変更する制御部を具備する。
 本発明によれば、ノード間に構築されるアソシエーションで使用するストリーム数を通信切断することなく動的に変更することができる。これにより、大規模通信におけるストリーム数を有効活用して、通信速度を向上することができる。
本発明の実施例1に係るSCTP通信方法が適用される通信システムに具備されるノードの構成を示すブロック図である。 3つのノードA、B、C間にてアソシエーションを構築し、通信を行う様子を示す図である。 図2において、ノードA、B間のアソシエーションが解除された状態を示す図である。 図3において発生した空きストリームをノードB、C間に追加割り当てした状態を示す図である。 図2乃至図4に示すように、空きストリームが発生した際、それを検出して、他のノードに割り当てる手順を示すシーケンス図である。 空きストリームの発生を示す空位発生メッセージのパケットフォーマットを示す図である。 本発明の実施例2に係るSCTP通信方法を説明するため、3つのノードD、E、F間にアソシエーションを構築した様子を示す図である。 図7において、ノードD、E間で使用されるストリーム数が減少した状態を示す図である。 図8において発生した余剰ストリームを空きストリームとして認定し、ノードE、F間に割り当てた状態を示す図である。 図7乃至図9に示すように、余剰ストリームが検出された際、それを他のノードに割り当てる手順を示すシーケンス図である。 余剰ストリームの解放を要求する解放要求メッセージのパケットフォーマットを示す図である。 新たに割り当てる余剰ストリーム数を示す解放確認メッセージのパケットフォーマットを示す図である。 従来のSCTP通信方法において、ノード間に構築されるアソシエーションで用いるストリーム数の割当てを説明するシーケンス図である。 ノードX、Yにおいて3本のストリームを用いてアソシエーションを構築する様子を示す図である。 従来のSCTP通信方法の第1の例として、ノードK、Mが使用可能ストリーム数「5」であるノードLと通信を行う様子を示す図である。 図15において、ノードKとノードLの間の通信が終了して、3本のストリームが利用可能となった状況を示す図である。 従来のSCTP通信方法の第2の例として、ノードP、Rが使用可能ストリーム数「5」であるノードQと通信を行う様子を示す図である。 図17において、ノードPとノードQの間の通信で2本のストリームが不必要となった状況を示す図である。
 本発明の実施例について図面を参照して説明する。
 図1は、本発明の実施例1に係るSCTP通信方法が適用される通信システムに具備されるノード1の構成を示すブロック図である。ここで、ノード1は第1の送信部2、第2の送信部3、及び制御部4より構成される。
 第1の送信部2は、ノード間でSCTPのリンク(即ち、「アソシエーション」)を構築する際に用いられるものであり、他のノードへの通信開始要求と要求ストリーム数OSをINIT(Initiation)として送信する。
 第2の送信部3は、ノード間でSCTPのアソシエーションを構築する際に用いられるものであり、INITを他のノードから受信したときに、許容ストリーム数MISを記述したINIT_ACK(Initiation Acknowledgement)を他のノードに返信する。
 制御部4は、要求ストリーム数OSと許容ストリーム数MISに基づく最小ストリーム数にて他のノードとの通信を行う。また、制御部4は空きストリームを検出すると、その空きストリーム数を他のノードに知らせる。これに応じて、他のノードから追加要求ストリーム数が送信されると、制御部4は空きストリーム数と追加要求ストリーム数に基づいて最小ストリーム数を算出して、他のノードとの通信に用いるストリーム数を動的に変更する。
 尚、制御部4は第1の送信部2を独立して制御することにより、他のノードへ所定の周期で空きストリーム数を送信するようにしてもよい。或いは、制御部4は第2の送信部3を独立して制御することにより、他のノードから追加要求ストリーム数を送信させるようにしてもよい。
 通信システムには複数のノード1が含まれ、相互に通信を行い、SCTPアソシエーションを構築する。その際、ノード1はアソシエーションで用いるストリーム数を決定して通信を開始する。
 次に、実施例1に係るSCTP通信方法の詳細について図2乃至図6を参照して説明する。
 図2に示すように、ノード1と同一構成の3つのノード(ノードA、B、C)が接続されているものとする。ここで、ノードBの使用可能なストリーム数の上限値、即ち許容ストリーム数MISが「5」(MIS=5)に設定されている。先ず、ノードAがノードBに対して3本のストリーム(OS=3)を要求するINITを送信し、ノードBはその要求を受諾してアソシエーションを構築する。次に、ノードBがノードCに対して3本のストリーム(OS=3)を要求するINITを送信する。しかし、ノードBにおける使用可能なストリーム数は「5」-「3」=「2」(MIS=2)なので、ノードBとノードCの間のアソシエーションにて使用されるストリーム数は「2」に制限される。
 その後、図3に示すように、アプリケーションが終了してノードA、B間のアソシエーションが不要になり、当該アソシエーションが解除される。即ち、ノードAとノードBの間で使用していた3本のストリームが空くこととなる。この場合、実施例1では図5に示すストリーム割当て手順を実行し、以って、アソシエーションが解除されたことに起因して発生する空きストリームを別のアソシエーションに割り当てる。その結果、図4に示すように、ノードBとノードCの間のストリーム数を「2」から「3」に変更され、以って、両者の通信速度を向上せしめる。
 図5は、実施例1に係るSCTP通信方法において、アソシエーション解除により発生した空きストリームを別のアソシエーションに割り当てる手順を示すシーケンス図である。即ち、3つのノードA、B、Cが接続されており、ノードBの許容ストリーム数MISが「5」(MIS=5)の場合において、ノードA、B間とノードB、C間のアソシエーションに割り当てられるストリーム数を変更する手順を示している。
 ステップST101:ノードAは、アソシエーションで使用したいストリーム数を要求するINITをノードBに送信する。ここで、ノードAからノードBへの要求ストリーム数OSを「3」(OS=3)とする。
 ステップST102:ノードBは、ステップST101で受信したINITの応答として、ストリーム数の上限値を示すINIT_ACKをノードAに返信する。ここで、ノードBの許容ストリーム数MISは「5」(MIS=5)に設定されている。ノードAは、MIS=5を通知するINIT_ACKを受諾する。これにより、図2に示すように、ノードA、B間で3本のストリームを用いたアソシエーションが構築される。
 ステップST103:ノードCは、アソシエーションで使用したいストリーム数を要求するINITをノードBに送信する。ここで、ノードCからノードBへの要求ストリーム数OSを「3」(OS=3)とする。
 ステップST104:ノードBは、ステップST103で受信したINITの応答として、ストリーム数の上限値を示すINIT_ACKをノードCに返信する。ここでは、ノードBの許容ストリーム数MISが「5」であり、既にノードAとの間で3本のストリームが使用されているため、使用可能なストリーム数の上限値「2」(MIS=2)をノードCに通知する。ノードCは、MIS=2を通知するINIT_ACKを受諾する。これにより、図2に示すように、ノードCは要求ストリーム数OS=3よりも少ない2本のストリームでノードBとの間にアソシエーションを構築する。
 ステップST105:アプリケーション終了に起因して、ノードA、B間のアソシエーションが不要になると、当該アソシエーションが解除されたことを示すSHUTDOWNがノードAからノードBに送信される。
 ステップST106:ノードBは、ステップST105で受信したSHUTDOWNの応答として、SHUTDOWN_ACKをノードAに返信する。この結果、図3に示すように、ノードA、B間のアソシエーションで用いていた3本のストリームが空くこととなる。
 ステップST107:ノードBは、ノードA、B間のアソシエーションが解除されたことに起因して3本の空きストリームが発生したことを認識する。即ち、ノードBは、これまでノードAとの間で使用していた3本のストリームが空いたことを認識する。
 ステップST108:ノードBは、空きストリームが発生したことを示す空位発生メッセージをノードCに通知する。この空位発生メッセージには空きストリーム数「3」(即ち、MIS=3)が記述されている。具体的には、図6に示すパケットフォーマットを有する空位発生メッセージがノードBからノードCに送信される。ここで、空きストリーム数を示すMIS=3が「Number of Outbound Streams」に記述される。
 ステップST109:ステップST108で上記メッセージを受信したノードCは、ノードBとのアソシエーションにおけるストリーム数を増やすべきか否か判断する。ノードCは、ステップST103で要求ストリーム数OS=3をノードBに送信しているのにも拘らず、ステップST104にてノードBから2本のストリームの使用しか許諾されていないので、ストリーム数を増やすべきであると判断する。ノードCは、追加要求ストリーム数OS=3を示す追加要求メッセージをINITと同一のパケットフォーマットでノードBに送信する。ステップST103におけるINITはノードB、C間にアソシエーションを構築することを意図しているのに比べて、この追加要求メッセージでは当該アソシエーション自体はそのまま維持するが、使用するストリーム数のみを変更することを意図しているので、INITとは異なるメッセージ種別にする必要がある。即ち、この追加要求メッセージのパケットフォーマットに記述されるType値(メッセージの種別を識別する値)は、INITのType値とは異なる。
 ステップST110:ステップST109で追加要求メッセージを受信したノードBは、現在の使用可能ストリーム数の上限値を示す追加確認メッセージをノードCに送信する。前記ステップST107において、3本の空きストリームが発生しているので、ノードBは許容ストリーム数MIS=3をノードCに通知する。この追加確認メッセージは、INIT_ACKと同一のパケットフォーマットを用いている。これは、追加要求メッセージにINITと同一のパケットフォーマットを用いたことと同様である。即ち、追加確認メッセージとINIT_ACKはType値が異なる。
 ステップST111:ノードBはノードCとの間で追加ストリームの割当てを行なう。これにより、図4に示すように、ノードB、C間のアソシエーションが途切れることなく、ストリーム数を「2」から「3」に増加することができる。
 尚、ノードBはノードAとの間で空きストリームが発生したことを検出したタイミングで空位発生メッセージをノードCに送信しているが、所定の周期で空位発生メッセージを送信するようにしてもよい。或いは、各ノードは、データ送信時に、他のノードへ空きストリームの発生を示す空位発生メッセージを同時に送信するようにしてもよい。
 次に、本発明の実施例2に係るSCTP通信方法について説明する。実施例1と同様に、実施例2でもノード1の構成を採用しているが、その機能が異なる。実施例2において、ノード1の制御部4は、現在の通信量と使用ストリーム数に基づいて余剰ストリーム数を算出し、その余剰ストリーム数を空きストリーム数として認定して他のノードに通知する。これ以外の動作について、実施例2は実施例1と同じである。
 次に、実施例2に係るSCTP通信方法の詳細について図7乃至図11を参照して説明する。
 図7に示すように、3つのノードD、E、Fが接続されており、ノードEの使用可能なストリーム数の上限値、即ち許容ストリーム数MISは「5」(MIS=5)に設定されている。先ず、ノードDが3本のストリームを要求(OS=3)するINITをノードEに送信して、ノードEはその要求ストリーム数OSを受諾してアソシエーションを構築したものとする。次に、ノードFが3本のストリームを要求(OS=3)するINITをノードEに送信した場合、ノードEにて使用可能なストリーム数は「2」(MIS=2)であるため、ノードE、F間で構築されるアソシエーションのストリーム数は「2」に制限される。
 その後、図8に示すように、ノードD、E間を流れるデータ量が減少して、1本のストリームでも十分処理可能な状態になったものとする。この場合、実施例2は図10に示すストリーム数割当て手順を実行することにより、ノードD、E間のアソシエーションが解除されなくても余剰ストリームを空きストリームとして使用して、ノードFに割り当てる。その結果、図9に示すように、ノードE、F間で使用されるストリーム数が「2」から「3」に変更され、以って、両者の間の通信速度を向上せしめる。
 図10は、実施例2に係るSCTP通信方法において、アソシエーションで使用されるストリーム数が減少した際に発生する余剰ストリームを空きストリームとして認定し、他のアソシエーションに割り当てる手順を示すシーケンス図である。
 ステップST201:ノードDは、アソシエーションで使用するストリーム数を要求するINITをノードEに送信する。ここで、ノードDからノードEに通知される要求ストリーム数OSは「3」(OS=3)に設定される。
 ステップST202:ノードEは、ステップST201で受信したINITの応答として、ストリーム数の上限を示すINIT_ACKをノードDに返信する。ここで、ノードEからノードDに通知される許容ストリーム数MISは「5」(MIS=5)に設定される。ノードDがINIT_ACKを受諾すると、図7に示すように3本のストリームにてノードD、E間にアソシエーションが構築される。
 ステップST203:ノードFは、アソシエーションで使用するストリーム数を要求するINITをノードEに送信する。ここで、ノードFからノードEに通知される要求ストリーム数OSは「3」(OS=3)に設定される。
 ステップST204:ノードEは、ステップST203で受信したINITの応答として、使用可能なストリーム数の上限値を示すINIT_ACKをノードFに返信する。ここでは、ノードEのストリーム数の上限値が「5」であり、ノードDとの間で3本のストリームが使用されているため、使用可能なストリーム数の上限値は「2」となる。ノードFが許容ストリーム数MIS=2を示すINIT_ACKを受諾すると、図7に示すように2本のストリームにてノードE、F間にアソシエーションが構築される。
 ステップST205:ノードD、E間を流れるデータ量が減少し、図8に示すように、1本のストリームでも十分に通信可能になると、両者の間で2本のストリームが使用されなくなる。即ち、当初、要求ストリーム数OS=3で通信要求を行なったノードDのアプリケーションは、ステップST205にて2本の余剰ストリームを認識することとなる。
 ステップST206:ノードDは、認識した余剰ストリームを解放するために解放要求メッセージをノードEに送信する。ここで、現在の余剰ストリーム数RS=2を解放要求メッセージに記述する。具体的には、図11に示すパケットフォーマットにて解放要求メッセージを作成し、その余剰ストリーム数RS(Number of Reducing Streams)に「2」を記述する。
 ステップST207:ステップST206にて解放要求メッセージを受信すると、ステップEは解放する余剰ストリームを確認すべく解放確認メッセージをノードDに返信する。ここで、割り当てられる余剰ストリーム数を解放確認メッセージに記述する。具体的には、図12に示すパケットフォーマットにて解放確認メッセージを作成し、その余剰ストリーム数RS(Number of Reducing Streams)に割り当てられる余剰ストリーム数を記述する。
 ステップST208:解放確認メッセージを受信すると、ノードDは余剰ストリームのみを解放し、残りのストリームにてアソシエーションを維持してノードEとの通信を続行する。ノードEは、ステップST208において空きストリームの発生を認識する。
 ステップST209:ノードEは、空きストリームが発生したことを示す空位発生メッセージをノードFに送信する。尚、空位発生メッセージを所定周期で送信するようにしてもよい。ここで、現在の空きストリーム数は空位発生メッセージに記述する。
 ステップST210:ステップST209にて空位発生メッセージを受信すると、ノードFはノードEとのアソシエーションにてストリームを増加するか否かを判断する。ノードFは、ステップST203で3本のストリームを要求しているにも拘らず、ステップST204でノードEから2本のストリームしか許諾されなかったので、ストリームを増加すべきであると判断する。このため、ノードFは3本目のストリームを追加要求すべく要求ストリーム数OS=3を記述した追加要求メッセージをノードEに送信する。
 ステップST211:ステップST210で追加要求メッセージを受信すると、ノードEは使用可能なストリーム数の上限値を示す追加確認メッセージをノードFに返信する。これにより、図9に示すように、ノードE、F間のアソシエーションが途切れることなく、そのストリーム数を「2」から「3」に増加する。
 上記のように、本発明に係るSCTP通信方法では、ノード間の通信途中においてストリーム数の変化を検出した際、空きストリームを別のアソシエーションに振り分けることができ、以って、通信切断することなく通信速度を向上することができる。
 尚、本発明は上記の実施例に限定されるものではなく、特許請求の範囲に定義された発明の範囲において種々の変形を行なうことが可能である。
 本発明は、複数のノード間でアソシエーションを構築して通信を行うSCTPに準拠した通信システムに適用されるものであるが、その他の通信プロトコールに準拠するノード間の通信システムにも適用可能である。
 1  ノード
 2  第1の送信部
 3  第2の送信部
 4  制御部

Claims (10)

  1.  複数のノードより構成された通信システムにおいて、
     各ノードは、要求ストリーム数を記述したINITを受信すると、許容ストリーム数を記述したINIT_ACKを返信し、以って、他のノードとの間に少なくとも1本のストリームを使用したアソシエーションを確立し、
     空きストリームの発生が検出され、かつ、追加要求ストリーム数が記述された追加要求メッセージ
    を受信すると、各ノードは追加確認メッセージを送信し、以って、他のノードとの間に構築したアソシエーションで使用されるストリーム数を変更するようにしたSCTP通信方法。
  2.  各ノードは、現在の通信量と使用ストリーム数に基づいて余剰ストリーム数を算出し、その余剰ストリーム数を空きストリーム数として他のノードに通知するようにした請求項1記載のSCTP通信方法。
  3.  各ノードは、空きストリームの発生が検出されたタイミングでその空きストリーム数を他のノードに通知するようにした請求項1記載のSCTP通信方法。
  4.  各ノードは、所定のタイミングで空きストリーム数を他のノードに通知するようにした請求項1記載のSCTP通信方法。
  5.  各ノードは、他のノードとの通信において随時空きストリーム数を通知するようにした請求項1記載のSCTP通信方法。
  6.  複数のノード間で少なくとも1本のストリームを使用したアソシエーションを構築するSCTP通信システムであって、
     各ノードは、要求ストリーム数を記述したINITを送信する第1の送信部と、
     INITを受信すると、許容ストリーム数を記述したINIT_ACKを送信する第2の送信部と、
     空きストリームの発生が検出され、かつ、追加要求ストリーム数が記述された追加要求メッセージを受信すると、追加確認メッセージを送信し、以って、他のノードとの間に構築されたアソシエーションで使用されるストリーム数を変更する制御部を具備するようにしたSCTP通信システム。
  7.  制御部は、現在の通信量と使用ストリーム数に基づいて余剰ストリーム数を算出し、その余剰ストリーム数を空きストリーム数として他のノードに通知するようにした請求項6記載のSCTP通信システム。
  8.  制御部は、第1の送信部を独立して制御して、空きストリーム数を他のノードに通知するようにした請求項6記載のSCTP通信システム。
  9.  制御部は、第2の送信部を独立して制御して、追加要求メッセージを送信するようにした請求項6記載のSCTP通信システム。
  10.  少なくとも1本のストリームを使用してアソシエーションを構築するSCTP通信方法に準拠したノードであって、
     要求ストリーム数を記述したINITを送信する第1の送信部と、
     INITを受信すると、許容ストリーム数を記述したINIT_ACKを送信する第2の送信部と、
     空きストリームの発生が検出され、かつ、追加要求ストリーム数が記述された追加要求メッセージを受信すると、追加確認メッセージを送信し、以って、他のノードとの間に構築されたアソシエーションで使用されるストリーム数を変更する制御部を具備するようにしたノード。
PCT/JP2010/000268 2009-01-19 2010-01-19 Sctp通信方法 WO2010082509A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US13/144,824 US8908519B2 (en) 2009-01-19 2010-01-19 SCTP communication method
JP2010546606A JP5246271B2 (ja) 2009-01-19 2010-01-19 Sctp通信方法、sctp通信システムおよびノード

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2009-009201 2009-01-19
JP2009009201 2009-01-19

Publications (1)

Publication Number Publication Date
WO2010082509A1 true WO2010082509A1 (ja) 2010-07-22

Family

ID=42339762

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/000268 WO2010082509A1 (ja) 2009-01-19 2010-01-19 Sctp通信方法

Country Status (3)

Country Link
US (1) US8908519B2 (ja)
JP (1) JP5246271B2 (ja)
WO (1) WO2010082509A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103001682B (zh) 2011-09-14 2015-03-11 华为技术有限公司 一种数据反馈方法以及相关装置
US20140114954A1 (en) * 2012-10-23 2014-04-24 International Business Machines Corporation Incorporating related searches by other users in a social network in a search request
EP3466015B1 (en) * 2016-06-02 2023-08-09 Telefonaktiebolaget LM Ericsson (PUBL) Method and network node for handling sctp packets
CN108243211A (zh) * 2016-12-24 2018-07-03 华为技术有限公司 一种数据传输方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001197118A (ja) * 2000-01-11 2001-07-19 Nec Corp データグラム中継装置及びその方法
JP2009111641A (ja) * 2007-10-29 2009-05-21 Fujitsu Ltd 基地局装置、通信方法及び移動通信システム

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3251077B2 (ja) * 1992-12-25 2002-01-28 沖電気工業株式会社 アソシエーション管理方法
US5862325A (en) * 1996-02-29 1999-01-19 Intermind Corporation Computer-based communication system and method using metadata defining a control structure
JP3983042B2 (ja) * 2000-12-07 2007-09-26 アルカテル・カナダ・インコーポレイテツド ソースルーティングシグナリングプロトコル通信ネットワークにおけるコールブロッキングトリガトポロジ更新のためのシステムおよび方法
US7054333B2 (en) * 2001-04-19 2006-05-30 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatus for distributed SCCP management procedures
DE10133473C1 (de) 2001-07-10 2003-02-20 Siemens Ag Verfahren zur optimierten Nutzung von SCTP (Stream Control Transmission Protocol) in MPLS (Multi Protocol Label Switching) Netzen
JP3943465B2 (ja) * 2002-08-20 2007-07-11 株式会社エヌ・ティ・ティ・ドコモ 通信装置、通信システム及び通信方法
JP4579742B2 (ja) * 2005-03-30 2010-11-10 キヤノン株式会社 無線端末装置、無線通信方法、及びコンピュータプログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001197118A (ja) * 2000-01-11 2001-07-19 Nec Corp データグラム中継装置及びその方法
JP2009111641A (ja) * 2007-10-29 2009-05-21 Fujitsu Ltd 基地局装置、通信方法及び移動通信システム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
R.STEWART ET AL.: "Stream Control Transmission Protocol (SCTP) Stream Reset", IETF, INTERNET-DRAFT DRAFT-STEWART-TSVWG-SCTPSTRRST-00.TXT, 20 June 2008 (2008-06-20) *

Also Published As

Publication number Publication date
JPWO2010082509A1 (ja) 2012-07-05
US8908519B2 (en) 2014-12-09
JP5246271B2 (ja) 2013-07-24
US20120020375A1 (en) 2012-01-26

Similar Documents

Publication Publication Date Title
KR102156687B1 (ko) 다중 경로 연결을 확립하기 위한 방법 및 멀티 홈 장비
JP2009219076A (ja) Ip電話システムにおけるゲートウェイルータおよび緊急呼の優先制御方法
JP2010050770A (ja) 無線通信装置、通信システム、および通信制御方法、並びにプログラム
JP5246271B2 (ja) Sctp通信方法、sctp通信システムおよびノード
JP4644709B2 (ja) データ記録システム、データ取得装置、データ記録装置、データ取得装置制御プログラム、およびデータ記録装置制御プログラム
JP2009260594A (ja) データ通信方法
JP3705297B1 (ja) ネットワーク伝送装置およびネットワーク伝送方法
JP4317208B2 (ja) 動的ネットワークにおけるセッションをセットアップする方法および装置
JP2007219680A (ja) サーバ
JP4480726B2 (ja) 無線端末および無線通信方法
JPWO2007023966A1 (ja) 通信装置、通信方法および通信プロトコル処理方法、通信端末装置およびその通信方法、ならびに通信システムおよびその通信方法
WO2021192294A1 (ja) 光伝送装置、光通信システム、及び光通信方法
JP4452172B2 (ja) ゲートウェイ装置及びVoIPネットワークシステム
JP2005244366A (ja) ゲートウェイ装置及び移動端末機とlan間接続方法
JP2006121246A (ja) 移動体パケット通信システム、ノード装置及びそれらに用いるpdpコンテキスト継続方法
KR100949280B1 (ko) 네트워크 인터페이스에서의 핸드오버 시의 인터페이스 버퍼제어 방법
US20060142022A1 (en) Method of operating a base station of wireless communications network, base station of a wireless communications network and radio network controller
KR20060096623A (ko) 통신시스템에서 데이터그램 프로토콜을 이용하여 실시간 데이터의 신뢰성을 보장하기 위한 방법
CN103166922A (zh) 点对点叠加网络中的呼叫请求处理方法、系统和装置
JP6061559B2 (ja) 画像処理装置、情報処理方法及びプログラム
JP5427853B2 (ja) データ同期方法
JP2004248257A (ja) 通信システム及び端末
JP3978685B2 (ja) 着信制御サーバ、着信再送システム、及び、着信再送方法
JP5125643B2 (ja) 中継装置、データ転送システム、データ転送方法及びデータ転送プログラム
CN101505189A (zh) 业务信息发送、接收方法和装置、顺序号同步系统

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: 10731178

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13144824

Country of ref document: US

Ref document number: 2010546606

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10731178

Country of ref document: EP

Kind code of ref document: A1