JPWO2015194134A1 - 通信状態推定装置、通信状態推定方法及び通信状態推定プログラムを記憶する記録媒体 - Google Patents

通信状態推定装置、通信状態推定方法及び通信状態推定プログラムを記憶する記録媒体 Download PDF

Info

Publication number
JPWO2015194134A1
JPWO2015194134A1 JP2016529023A JP2016529023A JPWO2015194134A1 JP WO2015194134 A1 JPWO2015194134 A1 JP WO2015194134A1 JP 2016529023 A JP2016529023 A JP 2016529023A JP 2016529023 A JP2016529023 A JP 2016529023A JP WO2015194134 A1 JPWO2015194134 A1 JP WO2015194134A1
Authority
JP
Japan
Prior art keywords
communication
error
parameter
unit
state estimation
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
JP2016529023A
Other languages
English (en)
Inventor
啓文 植田
啓文 植田
峻一 木下
峻一 木下
則夫 山垣
則夫 山垣
一峰 小倉
一峰 小倉
藤田 範人
範人 藤田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
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 NEC Corp filed Critical NEC Corp
Publication of JPWO2015194134A1 publication Critical patent/JPWO2015194134A1/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079Root cause analysis, i.e. error or fault diagnosis
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W24/00Supervisory, monitoring or testing arrangements
    • H04W24/06Testing, supervising or monitoring using simulated traffic
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751Error or fault detection not based on redundancy
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • 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/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W24/00Supervisory, monitoring or testing arrangements
    • H04W24/08Testing, supervising or monitoring using real traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/1874Buffer management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/1887Scheduling and prioritising arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W24/00Supervisory, monitoring or testing arrangements
    • H04W24/04Arrangements for maintaining operational condition

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)

Abstract

ネットワークの状態を特定する精度を向上させることができる通信状態判定装置などを提供する。本発明の一態様に係る通信状態推定装置は、与えられた通信パラメータに応じて、通信先装置との通信において通信エラーの発生を判定する通信装置に、前記通信パラメータを与える設定手段と、通信指示を受信するのに応じて前記通信を行う前記通信装置に前記通信指示を送信し、当該指示に応じた前記通信において判定された通信エラーの発生を検出する検出手段と、前記通信パラメータ及び前記通信エラーの発生の有無に基づき、前記通信装置が前記通信をできるか否かを推定する推定手段と、を備える。

Description

本発明は、通信環境を推定する技術に関する。
近年、例えば、車車間通信の通信手段、ネットワークインフラの無い僻地における通信、及び、災害時における通信手段として、モバイルアドホックネットワーク(Mobile Ad−Hoc Networks、MANET)が注目されている。MANETには、多数の通信端末(ノード)が無線接続されることが望まれている。
MANETでは、通信端末の移動及び無線接続を想定されている。そのため、通信端末の移動や無線干渉によって、パケット(通信データ)のロス、通信遅延の増加、そしてさらに通信の断絶等の障害が発生することがあり得る。そのような場合、既存の通信プロトコルが上手く動作しない。
例えば、TCP(Transmission Control Protocol)は、有線環境で利用されている一般的な通信プロトコルである。TCPは、コネクション型プロトコルと呼ばれる。TCPの特徴は、例えば、通信セッションの確立、通信速度の制御、及び、パケットの再送制御を行うことである。TCPをMANET環境で利用した場合、高い確率で発生するパケットロス及び通信の断絶のために、通信が上手く機能しないことがわかっている。
通信が機能しないそのような状態を回避する技術の例が、特許文献1に開示されている。特許文献1に記載されている無線通信装置は、TCPのウィンドウサイズを監視する。その無線通信装置は、輻輳状態が発生したと判断した場合、別の通信プロトコルであるUDP(User Datagram Protocol)を使用する。特許文献1には、TCPによる通信とUDPによる通信を並行して行うことにより、通信を継続する方法も記載されている。
特許文献2には、複数の同時無線接続間の干渉を減らすように、無線接続のパラメータを制御する通信装置が記載されている。
特許文献3には、予想スループットに基づいて送信パラメータを選択する通信システムが記載されている。その通信システムは、予想エラーレート及びデータ送信レートに基づいて、予想スループットを求める。
特許第4754416号公報 特表2008−521309号公報 特表2012−509647号公報
車車間通信のようなすれ違い通信、又は、通信リンクが頻繁に断絶するような環境では、パケットが届かない状況がしばらく続くことがある。このような場合、TCPによる通信の性能は、パケットの不達によって劣化する。加えて、TCPによる通信では、パケットの再送制御に問題が生じる。
例えば、TCPに基づく通信の開始時や再接続時に、SYN(Synchronize)パケットの交換が行われる。SYNパケットの交換の際に、通信の断絶、又は、パケットロスが発生すると、SYNパケットの再送制御が開始される。その際、再送待ち時間が設けられる。再送待ち時間は、一般に、バックオフ時間とも呼ばれる。バックオフ時間が設けられることによって、すぐにはSYNパケットの再送が行われない。そのため、少なくともバックオフ時間が終了するまで通信が開始されない。
図10は、車車間通信の例を模式的に表す図である。図10に示す例では、ノードAは、道路を走行中の車両に搭載された通信端末である。ノードBは、ノードAが搭載されている車両が走行している車線の対向車線を走行する車両に搭載されている通信端末である。図10に示す例では、時間は、時刻T1、時刻T2、そして時刻T3の順に経過する。時刻T1において、ノードA及びノードBは、セッションを確立する処理を開始する。しかし、セッションを確立するためのSYNパケットのロスが発生すると、バックオフ期間が設定される。図10に示す例では、時刻T1と時刻T2の間でSYNパケットのロスが発生する。そして、時刻T2から、通信できない期間であるSYNバックオフ期間が開始される。バックオフ期間が終了した後、セッションを確立する処理が再び行われる。図10に示す例では、時刻T3において、TCP接続が完了する。しかし、バックオフ期間中も2台の車両は逆方向への走行を継続することができるので、図10に示す例のように、接続が完了した時には、2台の車両の間の距離は大きくなっていることもある。
TCPによる通信が開始された後、通信リンクの断絶が発生した場合、データパケットの再送が開始される。その際、同様にバックオフ時間が設けられる。バックオフ時間が終了するまで、パケットの再送は行われない。バックオフ時間が設けられることによって、通信リンクが回復した後も、バックオフ時間が終了するまでしばらく通信できない。
図11は、2台の通信端末の間で行われる通信の例を模式的に表す図である。図11において、2台の通信端末が行う動作は、時間の経過に応じて、上から下に向かって描かれる。図11に示す例では、ノードBからのリクエストに応じて、ノードAがノードBにデータを送信する。ノードBからのリクエストは、例えばコンテンツを要求するコンテンツリクエストである。その場合、ノードAがノードBに送信するデータは、要求されたコンテンツである。データの送信中にノードAとノードBとの間に通信の断絶が生じた場合、ノードAは、データパケットを再送する。再送できなかった場合、ノードAは、設けられたバックオフ期間が終了した後、データパケットを再送する。バックオフ期間は、再送の回数の増加に応じて、例えば指数関数的に増加する。図11に示す例では、通信の断絶の間に行われた、3回のデータパケットの再送は全て失敗する。そして、3回目の再送の後に通信の断絶が解消する。通信の途絶が解消した場合、通信できない時間であるバックオフ時間が設定されてなければ、通信は可能である。しかし、3回目の再送の失敗によって設けられたバックオフ期間が終了するまで、ノードAはデータパケットの再送を行えない。図11における「再送待ち時間」が、設けられたバックオフ期間のために、ノードAがデータパケットの再送を行えない時間である。
上述の場合に通信が可能になるまでの時間を短縮するためには、SYNパケット交換時にパケットロスが発生した場合、通信リンクが安定した後、早期に、TCPの再接続を行えばよい。通信が開始された後に通信リンクが断絶した場合、通信リンクが回復した後、迅速に再送を行えばよい。
バックオフ時間は、正常動作時における待機時間である。通信を中継する通信装置におけるバックオフ期間の発生は、その通信装置を介して他の装置と通信を行う、例えばアプリケーションプログラムを実行するプロセッサ等の情報処理装置に、例えばエラーとして、通知されない。そのため、その通信装置を介して通信を行う情報処理装置は、バックオフ期間が設定されたために通信できない時間を検知することができない。従って、バックオフ期間が設定されていても、その情報処理装置は、正常に通信が行われていると認識する。
以上のように、一般に、通信装置バックオフ期間を伴う通信プロトコルによって通信を行う場合、その通信装置を使用する他の装置は、その通信装置が通信できる状態であるか否かを、精度よく判定することはできない。
その場合、バックオフ期間において、その情報処理装置が、その通信装置を介して、他の装置にデータを送信する可能性がある。その場合、例えば通信装置のバッファがあふれることによって、送信されたデータが失われることがある。
特許文献1に記載されている無線通信装置は、TCPによる通信にエラーが生じた場合、UDPによる通信を、TCPによる通信と併用する。しかし、バックオフ期間は待機期間であるので、バックオフ期間においてデータが送信されないことは異常ではない。従って、特許文献1に記載されている無線通信装置を介して通信する装置等は、バックオフ期間のために通信できないことを検知できない。
特許文献2に記載されている通信装置は、複数の無線接続が干渉するか否かを判定する。しかし、特許文献2の通信装置を介して通信する装置等は、バックオフ期間のために通信できないことを検知できない。
特許文献3に記載されている通信システムは、予想スループットに基づいて送信パラメータを選択する。しかし、特許文献3の通信システムを介して通信する装置等は、バックオフ期間のために通信できないことを検知できない。
本発明の目的の1つは、ネットワークの状態を特定する精度を向上させることができる通信状態判定装置などを提供することにある。
本発明の一態様に係る通信状態推定装置は、与えられた通信パラメータに応じて、通信先装置との通信において通信エラーの発生を判定する通信装置に、前記通信パラメータを与える設定手段と、通信指示を受信するのに応じて前記通信を行う前記通信装置に前記通信指示を送信し、当該指示に応じた前記通信において判定された通信エラーの発生を検出する検出手段と、前記通信パラメータ及び前記通信エラーの発生の有無に基づき、前記通信装置が前記通信をできるか否かを推定する推定手段と、を備える。
本発明の一態様に係る通信状態推定方法は、与えられた通信パラメータに応じて、通信先装置との通信において通信エラーの発生を判定する通信装置に、前記通信パラメータを与え、通信指示を受信するのに応じて前記通信を行う前記通信装置に前記通信指示を送信し、当該指示に応じた前記通信において判定された通信エラーの発生を検出し、前記通信パラメータ及び前記通信エラーの発生の有無に基づき、前記通信装置が前記通信をできるか否かを推定する。
本発明の一態様に係る記録媒体は、コンピュータを、与えられた通信パラメータに応じて、通信先装置との通信において通信エラーの発生を判定する通信装置に、前記通信パラメータを与える設定手段と、通信指示を受信するのに応じて前記通信を行う前記通信装置に前記通信指示を送信し、当該指示に応じた前記通信において判定された通信エラーの発生を検出する検出手段と、前記通信パラメータ及び前記通信エラーの発生の有無に基づき、前記通信装置が前記通信をできるか否かを推定する推定手段と、して動作させる通信状態推定プログラムを記憶する。本発明は、上述の記録媒体に格納される通信状態推定プログラムによっても実現される。
本発明には、ネットワークの状態を特定する精度を向上させることができるという効果がある。
図1は、本発明の第1及び第2の実施形態の通信端末1の構成の例を表すブロック図である。 図2は、異なる複数の通信パラメータについて算出された、通信エラーの発生確率の例を模式的に表す図である。 図3は、本発明の第1の実施形態の2台の通信端末1の配置の例を表す図である。 図4は、本発明の第1の実施形態の通信状態推定装置10の、通信を確立する動作を表すフローチャートである。 図5は、本発明の第1及び第2の実施形態の通信状態推定装置10の、通信状態推定処理の動作の例を表すフローチャートである。 図6は、本発明の第2の実施形態のおける2台の通信端末1の間で行われる通信を模式的に表す図である。 図7は、本発明の第2の実施形態の通信状態推定装置10の動作の例を表すフローチャートである。 図8は、本発明の第3の実施形態の通信状態推定装置10の構成の例を表すブロック図である。 図9は、本発明の各実施形態に係る通信端末1及び通信状態推定装置10を実現することができる、コンピュータ1000のハードウェア構成の一例を表す図である。 図10は、車車間通信の例を模式的に表す図である。 図11は、2台の通信端末の間で行われる通信の例を模式的に表す図である。
次に、本発明の実施の形態について図面を参照して詳細に説明する。
<第1の実施形態>
[構成の説明]
図1は、本実施形態の通信端末1の構成の例を表すブロック図である。通信端末1は、通信先装置2と通信可能に接続されている。通信端末1と通信先装置2とは、例えば、無線によって通信可能であればよい。通信先装置2は、例えば、通信端末1と同じ構成を備える通信端末である。
図1を参照すると、本実施形態の通信端末1は、推定部111と、設定部121と、検出部122と、通信プロトコル部130と、通信部140とを含む。図1に示す例では、通信端末1は、通信状態推定装置10と、通信装置11とを含む。通信状態推定装置10が、推定部111と、設定部121と、検出部122とを含む。通信装置11が、通信プロトコル部130と、通信部140とを含む。推定部111は、例えば、通信状態推定装置10のプロセッサと、通信状態推定装置10のプロセッサが実行するアプリケーションプログラムである、アプリケーション110とによって実現されている。なお、通信端末1のプロセッサが、通信状態推定装置10のプロセッサであってもよい。設定部121と、検出部122とは、制御部120として実装されている。通信部140は、例えば、通信先装置2などの他の通信端末と通信を行う。通信プロトコル部130は、所定の通信プロトコルに従った通信の制御を行う。制御部120は、通信装置11とアプリケーション110とのインタフェースである。
通信部140は、通信プロトコル部130から受け取ったデータを、通信先装置2などの他の通信端末に対して送信する。通信部140は、さらに、他の通信端末から受信したデータを、通信プロトコル部130に送信する。
通信プロトコル部130は、通信部140を通じてデータを送受信する。通信プロトコル部130は、他の通信端末との通信セッションを確立する。通信プロトコル部130は、送信速度を制御する。通信プロトコル部130は、送信されたデータの再送制御を行う。また、通信プロトコル部130は、一定回数以上の再送制御を行った場合、一定期間の間に通信セッションを確立できない場合、又は、一定期間の間にデータを受信できない場合、通信エラーが発生したと判定する。通信エラーが発生したと判定した場合は、通信プロトコル部130は、検出部122に前記エラー内容を送信する。また、通信プロトコル部130は、上述の一定回数及び一定期間を特定する通信パラメータを記憶する。通信パラメータは、例えば、設定部121によって設定される。通信プロトコル部130は、例えば、設定部121から通信パラメータを受信し、そして、受信した通信パラメータを記憶すればよい。設定部121が、通信プロトコル部130が含む、通信パラメータが格納されている記憶領域に、通信パラメータを書き込んでもよい。そして、通信プロトコル部130は、記憶している通信パラメータに従って通信を行う。
通信プロトコル部130が従う通信プロトコルは、例えば、TCPである。以下の説明では、通信プロトコル部130が従う通信プロトコルはTCPである。TCPを使用する場合は、通信プロトコル部130は、一定期間の間に通信セッションの確立ができたかどうかを、SYNパケットの再送回数に基づき判定する。通信プロトコル部130は、例えば、再送回数の最大値を超えた場合、セッション確立に失敗したと判定する。また、前述の一定期間は、例えば、変数であるTCP_USER_TIMEOUTに設定された値である。通信プロトコル部130は、TCP_USER_TIMEOUTに設定された時間内にパケットを受信できない場合、通信エラーが発生したと判定する。これらの値は、例えば、ソケットオプションにおいてTCPの通信パラメータを変更することによって設定される。
通信プロトコル部130は、例えば、TCPのシステムコールである、bind()、connect()、又はread()などが実行された際に、エラーが発生した場合、エラー情報を送信すればよい。
また、通信プロトコル部130は、さらに、通信プロトコルの制御メッセージ(例えば、TCPのSYNパケット)の送受信が行えない場合、通信エラーが発生したと判定してもよい。通信プロトコル部130は、特定の制御メッセージを通信相手から受信した場合、通信エラーが発生したと判定してもよい。以下の説明において、通信プロトコル部130が、通信エラーが発生したと判定することを、「通信プロトコル部130において通信エラーが発生する」と表記する。
設定部121は、通信プロトコル部130の通信パラメータを設定する。設定部121は、推定部111から通信パラメータ情報を受信する。設定部121は、受信した通信パラメータを、通信プロトコル部130に送信する。設定部121は、受信した通信パラメータを、通信プロトコル部130が含む、通信パラメータが記憶される記憶領域に書き込む。そして、設定部121は、通信プロトコル部130に通信を開始させる。例えば、TCPが用いられている場合、設定部121は、ソケットオプションを用いて、推定部111から通知されたパラメータを設定する。そして、設定部121は、通信プロトコル部130に、通信相手とのセッションを確立する処理を開始させる。例えば、設定部121は、通信プロトコル部130に、通信相手とのセッションを確立する処理を開始する指示を送信すればよい。その指示を受信した場合、通信プロトコル部130は、通信相手とのセッションを確立する処理を開始すればよい。
検出部122は、通信相手との通信における通信エラーの有無を監視する。検出部122は、通信相手との通信における通信エラーの発生を検出すればよい。検出部122は、通信プロトコル部130が、通信エラーが発生したと判定したか否かを検出すればよい。検出部122は、例えば、通信エラーが発生した場合に通信プロトコル部130が送信する、発生した通信エラーを表す通信エラー情報を受信した場合に、通信エラーの発生を検出すればよい。検出部122は、例えば、受信した通信エラー情報を送信することによって、推定部111に通信エラーの発生を通知する。例えば、TCPが使用される場合、設定部121は、例えば、SYNパケットの再送回数を通信パラメータとして設定する。その場合、通信プロトコル部130において、セッションの確立の失敗が、発生した通信エラーとして判定される。通信エラーが発生したと判定した場合、通信プロトコル部130は、セッションの確立に失敗したことを表すエラー情報を検出部122に送信する。検出部122は、セッションの確立に失敗したことを推定部111に通知する。すなわち、検出部122は、セッションの確立に失敗したことを表す通信エラーを、推定部111に送信する。
通信プロトコル部130は、セッションの確立に成功した場合、セッションの確立に成功したことを表すメッセージを、検出部122に送信してもよい。セッションの確立に成功したことを表すメッセージを受信した場合、検出部122は、セッションの確立に成功したことを表すメッセージを、推定部111に送信してもよい。
さらに、一定期間以上パケットを受信できないパケットを受信できない場合における通信エラーの発生を判定するのに使用される閾値として、前述のように、例えば、TCP_USER_TIMEOUTに期間が設定される。その場合、通信プロトコル部130は、セッションの確立後に、TCP_USER_TIMEOUTに設定されている期間以上の期間、パケットを受信しない場合、通信エラーが発生したと判定する。その場合、通信プロトコル部130は、一定期間の間にパケットを受信できなかったことを表す通信エラー情報を、検出部122に送信する。検出部122は、一定期間の間にパケットを受信できなかったことを推定部111に通知する。
例えば、通信プロトコルとしてTCPが使用されている場合、TCPのシステムコールであるbind()、connect()、read()などが実行された際、通信プロトコル部130は、通信エラーが発生していれば、通信エラー情報を送信すればよい。その場合、検出部122は、TCPのシステムコールを実行してもよい。検出部122は、TCPのシステムコールのいずれかを実行した際、TCPの通信エラーが発生していないか監視すればよい。通信エラーの発生が検出された場合、検出部122は、推定部111に通知すればよい。
他の通信エラーが検出された場合も同様に、検出部122は、推定部111に通知する。
前述のように、推定部111は、例えば、通信端末1又は通信状態推定装置10のプロセッサによって実行されるアプリケーションである、アプリケーション110によって実現されてもよい。
推定部111は、設定部121を用いて、調査対象の通信エラーに応じた通信パラメータを、通信プロトコル部130の通信パラメータとして設定する。推定部111は、検出部122から通知される通信エラーの発生の有無と、設定した通信パラメータの内容とに基づいて、通信確立状況を推定する。
例えば、TCP通信のセッションの確立の難しさが判定の対象である場合、推定部111は、設定部121に対して、例えば、通信パラメータの一つであるSYNパケットの再送回数を1に設定する要求を送信する。推定部111は、さらに、設定部121に対して、SYNパケットの再送回数が1に設定された状態で通信を行わせる要求を送る。推定部111は、要求に応じて行われた通信において発生した通信エラーを検出部122から受信する。通信パラメータが設定された状態で通信を行わせる要求を送信し、その通信において通信エラーが発生した場合にその通信エラーを受信することを、以下の説明において「調査」と表記する。推定部111は、受信した通信エラーに基づき、セッションの確立が容易であるか困難であるかを判定する。推定部111は、例えば、SYNパケットの再送回数が調査のために設定された状態において通信を実行する要求を既定の回数繰り返せばよい。SYNパケットの再送回数が1回に設定された状態において、通信プロトコル部130がセッションの確立に連続して失敗した場合、セッションの確立に失敗したことを表す通信エラーが、検出部122から連続して送信される。そのため、推定部111が検出部122からセッションの確立に失敗したことを表す通信エラーを連続して受信した場合、推定部111は、セッション確立は困難と判定する。SYNパケットの再送回数が1回に設定された状態であっても、通信プロトコル部130がセッションの確立に連続して失敗しなかった場合、セッションの確立に失敗したことを表す通信エラーは、検出部122から連続して送信されない。例えば、検出部122から通信エラーを連続して受信しなかった場合、推定部111は、セッションの確立が容易であると判定してもよい。その場合、さらに、推定部111は、通信先装置2との通信が可能であると推定すればよい。推定部111は、以上で説明した、セッションの確立が困難であるか容易であるかを繰り返し判定すればよい。
セッションの確立が困難であると判定されている間、通信端末1は、実際にデータ転送を行うための通信の確立を試みなければよい。そして、例えば、セッションの確立の難しさに関する判定の結果が、困難から容易に変化した場合、例えば、アプリケーション110が、実際にデータ転送を行うTCP通信を開始させればよい。そのことにより、通信状態推定装置10は、通信を確立する過程におけるバックオフ時間を短くすることができ、その結果、早期にTCP通信を開始することができる。
また、推定部111は、特定の通信パラメータだけを使用して、繰り返し上述の調査を行ってもよい。推定部111は、通信パラメータをさまざまに変化させながら、繰り返し調査を行ってもよい。推定部111は、さらに、調査が行われた通信パラメータ毎に、通信エラーを受信した確率を算出してもよい。例えば、推定部111は、一つの通信パラメータに対して複数回の調査を行えばよい。推定部111は、その複数回の調査の結果に基づき、通信エラーの発生確率を算出すればよい。推定部111は、同様に、他の通信パラメータの各々について、通信エラーの発生確率を算出すればよい。
推定部111は、SYNパケットの再送回数に1より大きい値を設定する指示を設定部121に送信してもよい。検出部122は、セッションの確立に成功した場合、セッションが確立されるまでのSYNパケットの再送回数を、推定部111に送信すればよい。セッションの確立に失敗した場合、検出部122は、セッションの確立に失敗したことを表す通信エラーを、推定部111に送信すればよい。推定部111は、受信した再送回数に基づき、SYNパケットの再送回数毎の通信エラーを算出してもよい。
図2は、異なる複数の通信パラメータについて算出された、通信エラーの発生確率の例を模式的に表す図である。図2において、「通信エラー確率」は、SYNパケットを「SYN再送回数」に示す回数まで再送できる場合に、セッションを確立できない確率を表す。図2に示す例は、例えば、SYNパケットを3回再送してもセッションを確立できない確率が20%であることを表す。また、「バックオフ期間」は、SYNパケットの再送回数が「SYN再送回数」に示す回数である場合の、バックオフ期間を表す。例えば、SYNパケットの1回目の再送におけるバックオフ期間は、3秒である。SYNパケットの2回目の再送におけるバックオフ期間は、6秒である。SYNパケットの3回目の再送におけるバックオフ期間は、12秒である。SYNパケットを3回再送した場合における、バックオフ期間の合計は、3、6、及び12の和は21であるので、21秒である。
推定部111は、セッションの確立が可能か否かを、通信エラー確率に基づいて決定してもよい。推定部111は、通信エラー確率が閾値以下である最小のSYNパケット再送回数を特定すればよい。そして、推定部111は、SYNパケットの再送回数が、特定したSYNパケット再送回数である場合のバックオフ時間の合計を、待ち時間として算出すればよい。推定部111は、例えば、算出された待ち時間が所定の閾値を越えない場合、通信が可能であると推定すればよい。推定部111は、例えば、算出された待ち時間が所定の閾値を越える場合、通信が可能でないと推定すればよい。例えば、セッションの確立が可能か否かを判定する閾値が20%である場合、通信エラー確率が20%以下である最小のSYN再送回数は3である。その場合、推定部111は、SYNパケットを3回再送すればセッションを確立できると推定すればよい。推定部111は、さらに、SYNパケットを3回再送した場合のバックオフ時間の合計を、待ち時間として算出すればよい。この例では、算出される待ち時間は21秒である。この場合、推定部111は、21秒の待ち時間が発生すると判定する。例えば、待ち時間に対する閾値が25秒である場合、推定部111は、算出された時間が21秒であれば、通信は可能であると判定する。
推定部111は、複数の通信パラメータを用いて調査を行う際、例えば識別子を使用して、通信パラメータと検出部122から送信される通信エラーとを関連付ければよい。例えば、推定部111は、あらかじめ、識別子を通信パラメータに関連付けておけばよい。推定部111は、調査において送信される、通信の要求に識別子を関連付けてもよい。そして、推定部111は、識別子が関連付けられた、通信の要求を、設定部121に送信すればよい。検出部122は、識別子が関連付けられた通信エラーを、推定部111に送信すればよい。識別子は、通信パラメータそのものであってもよい。識別子は、通信パラメータの識別子であってもよい。
複数の通信パラメータを用いた調査において、通信パラメータを変更しながら順次通信を行う場合、すべての通信が完了するまでに長い時間を要する。そのため、設定部121は、異なるパラメータが設定されたTCP通信を、同時に並列に行ってもよい。推定部111は、1つの通信パラメータの設定値の通信が終わるたびに、推定処理を行ってもよい。
アプリケーション110は、例えば図2に示す通信エラーの発生確率を使用して推定された結果を基に、アプリケーションレベルからTCPの再接続の制御を行えばよい。アプリケーション110による再接続の繰り返しは、SYNパケットの再送の繰り返しとは異なる。アプリケーション110による再接続が繰り返し失敗しても、設けられるバックオフ期間は、失敗の回数に応じて指数関数的には増加しない。言い換えると、この場合の設けられるバックオフ期間の増加は、指数関数的ではない。例えば、推定の結果、TCP接続が確立されるまでに21秒の時間を要する場合、アプリケーション110は、例えば1秒ごとにTCPの再接続を実行してもよい。通信プロトコル部130によってSYNパケットが送信されてから21秒以内に、セッションが確立されたことを表す応答が通信プロトコル部130から送信されない場合、アプリケーション110は、セッションの確立に失敗したとみなしてもよい。その場合、アプリケーション110がTCPの再接続を行ってもよい。これにより、早期にTCPの接続を確立することができる。
[動作の説明]
次に、本実施形態の通信状態推定装置10の動作について、図面を参照して詳細に説明する。
本実施形態では、多数の通信端末1によって、アドホックネットワークが構築されてもよい。以下では、説明を容易にするために、ネットワークを構成する通信端末1のうち2台の通信端末1の間の通信について説明する。また、以下で説明する例では、通信プロトコルとしてTCPが用いられる。
図3は、2台の通信端末1の配置の例を表す図である。図3において、ノードA及びノードBとして示される図形が2台の通信端末1の位置を表す。2台の通信端末1は、例えば、走行する車両等の移動体に搭載されている。図3に示す例では、時間は、時刻T1、時刻T2、そして時刻T3の順に経過する。時刻T1におけるノードA及びノードBの位置が、互いに通信可能な最も離れた位置を表す。また、各通信端末1は、自身の存在を通知するビーコン(Beacon)を定期的に送信することによって、通信可能な範囲に存在する他の通信端末1に、IP(Internet Protocol)アドレスを通知する。そのため、各通信端末1は、他方の存在(IPアドレス)を認識している。
図4は、本実施形態の通信状態推定装置10の、通信を確立する動作を表すフローチャートである。上述の2台の通信端末1のうちの一方(例えば、ノードAとして表される通信端末1)が、保有しているデータを、他方の通信端末1(例えば、ノードBとして表される通信端末1)に対して送信する場合、データを送信する前に、ノードBとの通信を確立する。以下の説明では、ノードAとして表される通信端末1を、ノードA又は単に通信端末1と表記する。さらに、ノードBとして表される通信端末1を、ノードB又は通信先装置2と表記する。図4は、ノードAがノードBとの接続を確立する場合における、ノードAである通信端末1に含まれる通信状態推定装置10の動作を表す。以下の説明において、通信端末1が通信を行う相手は、通信先装置2である。
ノードAすなわち通信端末1は、まず、通信状況を把握する。すなわち通信端末1は、推定部111を使用して、TCPを用いてデータを転送できるかどうか(すなわち、バックオフ制御が発生しないかどうか)を判定する。そのための処理が、図4に示す、ステップS101における通信状態推定処理である。
図4を参照すると、本実施形態の通信状態推定装置10は、まず、通信状態推定処理を行う(ステップS101)。通信状態推定処理については、後で詳細に説明する。通信状態推定処理における判定の結果、通信が可能である場合(ステップS102においてYes)、すなわち、データの転送が可能である場合、例えば推定部111が、通信装置11の通信プロトコル部130に対して、データを転送するための通信を確立する、再接続指示を送信する(ステップS103)。通信が可能でない場合(ステップS102においてNo)、通信状態推定装置10は、通信状態推定処理(ステップS101)を繰り返せばよい。なお、アプリケーション110が、ステップS102及びステップS103の一方又は双方の動作を行ってもよい。通信状態推定装置10のプロセッサが実行する他のアプリケーションプログラムが、ステップS102及びステップS103の一方又は双方の動作を行ってもよい。通信端末1のプロセッサが実行するアプリケーションプログラムが、ステップS102及びステップS103の一方又は双方の動作を行ってもよい。
次に、本実施形態の通信状態推定装置10の、通信状態推定処理の動作について、図面を参照して詳細に説明する。
図5は、本実施形態の通信状態推定装置10の、通信状態推定処理の動作の例を表すフローチャートである。
図5を参照すると、まず、推定部111は、通信パラメータを決定する(ステップS111)。ステップS111では、推定部111は、セッションの確立におけるバックオフ時間が大きくならずにセッションが確立できるかどうかを推定するTCP通信の試験のために、例えば、SYNパケットの再送回数を1に決定する。推定部111は、決定した通信パラメータを設定部121に送信する(ステップS112)。推定部111は、その通信パラメータを設定する指示を、設定部121に送信すればよい。推定部111は、例えば、SYNパケットの再送回数を1に設定する指示を設定部121に送信する。推定部111は、決定した通信パラメータが設定された状態で、通信を行わせる指示である通信指示を、設定部121に送信する(ステップS113)。通信指示を受信した設定部121は、後述のように、通信プロトコル部130に、通信状況推定のためのTCP通信を開始させる。推定部111は、このように例えば通信指示を設定部121に送信することによって、通信プロトコル部130に、通信状況推定のためのTCP通信を開始させる。
ステップS113において、設定部121は、推定部111から送信された通信パラメータ(例えば、SYN再送回数:1回)を、通信プロトコル部130に与える。そして、設定部121は、通信プロトコル部130に通信を開始させる。本実施の形態では、設定部121は、ソケットオプションにおいて、TCPのSYNパケット再送回数を「1」に設定することによって、通信プロトコル部130に通信パラメータを与える。そして、ステップS113において、設定部121は、通信プロトコル部130にTCP通信を開始させる。
ステップS113において、通信プロトコル部130は、設定部121によって設定された通信パラメータに従って通信を開始する。本実施形態では、上述のように、TCPのSYNパケットの再送回数は「1」に設定されている。通信プロトコル部130は、TCPのSYNパケットの再送回数が「1」である条件下で、TCP通信を開始する。通信プロトコル部130は、通信エラーが発生したか否か、そして、TCP通信が完了したか否かを監視する。通信エラーの発生を検出した場合、通信プロトコル部130は、発生した通信エラーを表す通信エラー情報を検出部122に送信する。正常に通信が完了した場合、通信プロトコル部130は、例えば、通信が完了したことを表す応答を、検出部122に送信する。本実施形態では、その通信は、例えば、セッションを確立するSYNパケットの送信である。
通信エラーが発生した場合、検出部122は、通信プロトコル部130から発生した通信エラーを表す通信エラー情報を受信する(すなわち、通信エラーを受信する)。通信プロトコル部130から発生した通信エラーを表す通信エラー情報を受信した場合(ステップS114においてYes)、検出部122は、推定部111に通信エラーの発生を通知する(ステップS116)。検出部122は、発生した通信エラーを推定部111に送信すればよい。すなわち、検出部122は、発生した通信エラーを表す通信エラー情報を、推定部111に送信すればよい。ステップS116の動作の後、検出部122は、通信終了処理を実行する(ステップS117)。ステップS117において、検出部122は、例えば、通信を終了する指示を通信プロトコル部130に送信すればよい。通信を終了する指示を受信した通信プロトコル部130は、TCP通信のソケットをクローズすることによって、TCP通信を終了する。
通信エラーが発生しない場合、検出部122は、通信プロトコル部130から発生した通信エラーを表す通信エラー情報を受信しない(すなわち、通信エラーを受信しない)。通信プロトコル部130から発生した通信エラーを表す通信エラー情報を受信しない場合(ステップS114においてNo)、検出部122は、ステップS113において送信した送信指示に基づく通信が完了したか判定する。判定の結果、通信が正常に完了している場合(ステップS115においてYes)、検出部122は、上述のステップS117の動作を行う。通信プロトコル部130から、通信エラーを受信しておらず(ステップS114においてNo)、通信が正常に完了したことを表す応答を受信していない場合(ステップS115においてNo)、通信状態推定装置10の動作は、ステップS114に戻る。そして、通信プロトコル部130から、通信エラー又は通信が正常に完了したことを表す応答を受信するまで、ステップS114及びステップS115の動作を繰り返す。
上述の調査が複数回行われる場合、通信状態推定装置10は、ステップS111からステップS117までの動作を繰り返す。
そして、推定部111は、通信先装置2との通信が可能であるか否かを推定する(ステップS118)。推定部111は、例えば、セッションの確立が3回連続で成功した場合、推定部111は、通信先装置2との通信が可能であると推定すればよい。通信が可能である状態は、例えば、通信先装置2との通信において通信エラーが発生せず、TCPを用いてデータを転送できる状態(すなわち、例えばバックオフ制御が発生しない状態)である。推定部111が、通信先装置2との通信が可能であると判定した場合、前述のように、通信端末1は、例えばアプリケーション110が接続指示を送信することによって、実際にデータの送信が行われるTCP通信を開始する。
図3に示す例では、例えば時刻T2において再接続開始されている。そして、時刻T3において、TCP接続が完了している。図3に示す例では、図10に示す例と比較して、TCP接続が完了するまでの時間が短い。従って、図3のノードAとノードBは、図10に示す例と比較して、通信できる時間が長い。なお、図3に示す時刻T1、T2、及びT3は、図10に示す時刻T1、T2、及びT3と関連しない。
以上の説明では、通信状態推定装置10は、通信の状態の推定以外に使用されない、専用のTCP通信によって、通信の状態を推定する。通信状態推定装置10は、データの送信を行うTCP通信を使用して、通信の状態を推定してもよい。具体的には、通信状態推定装置10は、通信パラメータを試験で使用する通信パラメータに設定してからデータ通信を開始すればよい。そして、通信エラーが検出されなくなったと判定された時点で、通信端末1は、通信パラメータを、データ転送時に設定される通信パラメータに戻せばよい。そして、通信端末1は、データ通信を行えばよい。
以上で説明した本実施形態には、ネットワークの状態を特定する精度を向上させることができるという効果がある。その理由は、通信パラメータと、その通信パラメータにおける通信エラーの有無とに基づき、推定部111が、通信装置11が通信できるか否かを判定するからである。通信パラメータは、設定部121によって、通信装置11の通信プロトコル部130に与えられる。通信エラーは、その通信パラメータが与えられた通信装置11が行う通信において、検出部122によって検出される。
<第2の実施形態>
[構成の説明]
次に、本発明の第2の実施形態について、図面を参照して詳細に説明する。本実施形態は、第1の実施形態を基本とする実施形態である。
図1は、本実施形態の通信端末1の構成の例を表すブロック図である。本実施形態の通信端末1の構成は、第1の実施形態の通信端末1の構成と同じである。以下の説明においては、本実施形態に係る特徴的な部分を中心に説明する。そして、上述した第1の実施形態と同様な構成についての重複する説明は省略する。
本実施形態の通信状態推定装置10は、TCPセッションが確立された後のデータ通信において、パケットが一定期間流れていないことに基づいて、通信状況を推定する。本実施形態の通信状態推定装置10は、さらに、第1の実施形態の通信状態推定装置10と同様の動作を行ってもよい。すなわち、本実施形態の通信状態推定装置10は、さらに、TCP通信のSYNパケットの再送回数と、TCP通信のセッションの確立において検出された通信エラーとに基づいて、データ通信の開始の可否を判断してもよい。
推定部111は、第1の実施形態の推定部111と同様に、通信プロトコル部130に与える通信パラメータを決定する。推定部111は、さらに、決定した通信パラメータと、その通信パラメータが設定された通信において発生する通信エラーの有無とに基づいて、通信の状態を推定する。
例えば、確立されているTCP通信セッションの通信の状態(例えば、パケット再送のバックオフの発生の有無)が調査の対象である場合、推定部111は、例えば、通信の断絶を許容する時間を決定する。そして、推定部111は、決定した、通信の断絶を許容する時間を、通信装置11に与える通信パラメータとして、設定部121に送信する。推定部111は、さらに、通信を行わせる要求である通信指示を、設定部121に送信する。推定部111は、送信した通信パラメータが設定された状態で行われた通信において発生した通信エラーを、検出部122から受信する。推定部111は、受信した通信エラーに基づいて、例えば、パケットの送信の状態等の、通信の状態を把握する。通信の断絶を許容する時間を表すパラメータは、例えば、TCP_USER_TIMEOUTであってもよい。以下の説明では、通信の断絶を許容する時間は、10秒である。
例えば、通信の断絶を許容する時間が10秒に設定されている場合、送信した通信指示に応じた通信において10秒以上の通信の断絶が生じた場合、検出部122から通信エラーが送信される。例えば一定期間内に、検出部122から通信エラーを受信した場合、推定部111は、10秒以上の通信の断絶が発生すると判定する。反対に、一定期間内に検出部122から通信エラーを受信しなかった場合、推定部111は、10秒以上の通信の断絶は無いと判定する。推定部111は、繰り返し通信指示を送信してもよい。そして、例えば3回以上連続して通信エラーを受信しなかった場合、10秒以上の通信の断絶が発生しないと判定してもよい
推定部111は、通信パラメータを異なる通信パラメータに変更しながら、繰り返し調査を行ってもよい。推定部111は、特定の通信パラメータを使用して、繰り返し調査を行ってもよい。推定部111は、ある通信パラメータを使用した通信において通信エラーの発生が検出されない場合、さらにエラーが発生しやすい通信パラメータを使用して調査を行ってもよい。例えば、10秒以上の通信の断絶が発生しないと判定した場合、は、推定部111は、通信の断絶を許容する時間を5秒に変更してもよい。推定部111は、例えば、TCP_USER_TIMEOUTを5秒に変更させればよい。そして、推定部111は、再度、通信指示を送信すればよい。推定部111は、異なる複数の通信パラメータを使用して調査を行うことで、発生する通信の断絶時間の長さをさらに正確に把握することができる。
また、推定部111は、通信パラメータとして、パケットの再送回数の最大値を使用することによっても、通信が断絶する時間を把握することができる。例えば、パケットの再送回数の最大値が通信パラメータとして設定されている通信において、パケットの再送回数が、パケットの再送回数の最大値として設定されている回数を越えた場合、通信エラー情報の発生が検出される。推定部111は、パケットの最大値として設定されている回数に応じたバックオフ時間の合計を、通信が途絶する時間として推定すればよい。推定部111は、例えば、パケットの再送回数の最大値をさまざまに変更しながら調査を行うことによって、通信が断絶する時間をさらに精度よく推定してもよい。なお、一般に、バックオフ時間の合計は、パケットの再送回数に比例しない。1回のパケットの再送において設定されるバックオフ時間は、例えば図2に示す例のように、再送回数の増加に応じて指数的に増加する。推定部111は、パケットの再送回数毎の、パケットの再送において設定されるバックオフ時間を保持していればよい。そして、推定部111は、通信パラメータとして設定されているパケットの再送回数の最大値に応じた、バックオフ時間の和を算出すればよい。推定部111は、算出されたバックオフ時間の和が、通信が途絶する時間であると判定すればよい。図2に示す例では、例えば、パケットの再送回数の最大値として設定されている回数が1回である場合、通信が途絶する時間として判定される時間は3秒である。パケットの再送回数の最大値として設定されている回数が2回である場合、推定部111は、通信が途絶する時間は、1回目の再送におけるバックオフ期間である3秒と、2回目の再送におけるバックオフ期間である6秒との和である9秒であると判定すればよい。
推定部111は、複数の通信パラメータをそれぞれ用いて調査を行う場合、第1の実施形態の推定部111と同様に識別子を使用することによって、通信パラメータと検出部122からの通信エラーとを関連付ければよい。
検出部122は、第1の実施形態の検出部122と同様に、通信エラーが発生した場合、発生した通信エラーを推定部111に通知する。検出部122は、発生した通信エラーを表す情報を、推定部111に送信してもよい。上述のように、検出部122は、例えば、TCP_USER_TIMEOUTを変更することによって、通信パラメータを設定すればよい。例えば、セッションが確立された後に、通信プロトコル部130が行う通信において通信エラーを検出した場合、検出部122は、通信パラメータとして設定されている期間パケットを受信できなかったことを、推定部111に通知すればよい。
他の通信パラメータが使用されている場合も同様に、検出部122は、通信エラーを表す情報を推定部111に通知すればよい。
[動作の説明]
次に、本実施形態の通信状態推定装置10の動作について、図面を参照して詳細に説明する。
本実施形態では、多数の通信端末1によるアドホックネットワークが構築されていてもよい。以下の説明では、説明を容易にするため、ネットワークを構成する通信端末1のうち、2台の通信端末1の間の通信について説明する。また、以下で説明する例では、通信プロトコルとして、TCPが用いられる。
図6は、本実施形態における2台の通信端末1の間で行われる通信を模式的に表す図である。図6に示すノードA及びノードBが、上述の2台の通信端末1である。ノードAとノードBとの間の距離は、ノードAとノードBとが互いに通信することができる距離である。また、各通信端末1は、自身の存在を通知するビーコンを定期的に送信することによって、IPアドレスを通知する。従って、各通信端末1は、他の通信端末1の存在を認識している。言い換えると、各通信端末1は、他の通信端末1のIPアドレスを認識している。
図7は、本実施形態の通信状態推定装置10の動作の例を表すフローチャートである。図7に示す動作では、ノードAとノードBとの間の通信は既に確立されている。そして、例えばノードAが、保有しているデータを、ノードBに対して送信する。図6において、ノードA及びノードBが行う動作は、時間の経過に応じて、上から下に向かって描かれる。図6に示す例では、ノードAは、例えば、ノードBからのコンテンツリクエストに応じて、コンテンツを送信する。そして、ノードAが、ノードBに対してデータを送信しながら、図7に示す動作を行う。具体的には、ノードAに含まれる通信状態推定装置10が、図7に示す動作を行う。以下の説明において、図6においてノードAとして表される通信端末1を、ノードA又は単に通信端末1と表記する。また、図6においてノードBとして表される通信端末1を、ノードB又は通信先装置2と表記する。
図7を参照すると、通信端末1の通信状態推定装置10は、まず、通信状態推定処理を行う(ステップS101)。すなわち、通信端末1の通信状態推定装置10は、推定部111によって、TCPを用いてデータ通信できるか否か(すなわち、再送バックオフ制御が行われるか否か)を判定する。ステップS101の通信状態推定処理については、後で詳細に説明する。
通信状態推定処理によって、通信が可能であると判定された場合(ステップS102においてYes)、通信状態推定装置10は、ステップS101の通信状態推定処理を繰り返す。後述されるように、通信状態推定処理において、通信先装置2に対するデータの送信が行われる。すなわち、通信先装置2に対するデータの送信は継続される。
通信状態推定処理によって、通信が可能でないと判定された場合(ステップS102においてNo)、例えば、推定部111が、現在の接続を終了する(ステップS201)。推定部111は、通信装置11の通信プロトコル部130に対して、例えば、TCPのセッションをクローズする指示である、通信終了指示を送信すればよい。通信終了指示を受信した通信プロトコル部130は、確立されている通信を終了する。推定部111は、さらに、通信装置11の通信プロトコル部130に対して、再接続を行う指示である、再接続指示を送信する(ステップS103)。再接続指示を受信した通信プロトコル部130は、新たにTCP通信を開始する。そして、通信端末1が行うデータの送信は、新しく開始されたTCP通信によって行われる。なお、アプリケーション110が、ステップS102、ステップS201、及びステップS103の一部又は全部の動作を行ってもよい。通信状態推定装置10のプロセッサが実行する他のアプリケーションプログラムが、ステップS102、ステップS201、及びステップS103の一部又は全部の動作を行ってもよい。通信端末1のプロセッサが実行するアプリケーションプログラムが、ステップS102、ステップS201、及びステップS103の一部又は全部の動作を行ってもよい。
次に、本実施形態の通信端末1の、通信状態推定処理を行う動作について、図面を参照して詳細に説明する。
図5は、本実施形態の通信端末1の、通信状態推定処理を行う動作の例を表すフローチャートである。図5に示す本実施形態の通信状態推定処理では、例えばパケット再送におけるバックオフ時間が大きくなることによって、TCP通信が止まっているか否かが推定される。
まず、推定部111が、通信パラメータを決定する(ステップS111)。ステップS111において決定される通信パラメータは、TCP通信が所定時間以上断絶していないか推定するために使用される通信パラメータである。推定部111は、例えば、通信タイムアウト時間の値、すなわち、通信の断絶を許容する時間の値を決定すればよい。推定部111は、通信の断絶を許容する時間を、例えば10秒に決定する。推定部111は、次に、決定した通信パラメータを設定部121に送信する(ステップS112)。推定部111は、例えば、通信タイムアウトを通信の断絶を許容する時間として決定された10秒に設定する指示を、設定部121に送信すればよい。推定部111は、さらに、決定した通信パラメータが設定された状態でTCP通信を行わせる指示である、通信指示を、設定部121に送信する(ステップS113)。
ステップS112において、設定部121は、推定部111から受信した通信パラメータを、通信プロトコル部130に与える。上述の例では、設定部121は、例えば、ソケットオプションにおいて、TCP_USER_TIMEOUTを10秒に設定することによって、通信パラメータを設定すればよい。ステップS113において、設定部121は、通信プロトコル部130に、通信を開始する指示を送信する。通信プロトコル部130は、通信を開始する。なお、通信プロトコル部130が通信先装置2に送信するデータは、検査のみに使用されるデータであってもよい。本実施形態では、ステップS113動作によって、通信プロトコル部130が通信先装置2に送信するデータは、上述の、通信端末1が通信先装置2に対して送信するデータであってもよい。
ステップS114からステップS118までの動作は、第1の実施形態におけるステップS114からステップS118までの動作と同様である。なお、本実施形態では、通信パラメータは、例えば、通信の断絶を許容する時間であってもよい。通信エラーは、例えば、通信の断絶を許容する時間以上の時間、データの送信が行われないことであってもよい。
以上で説明したように、図5に示す動作は、通信端末1から通信先装置2へのデータの送信と並行して行われる。そして、図5に示す動作によって、通信状態推定装置10は、通信先装置2に対する、TCPによるデータの転送の断絶(例えば、パケットの再送によって生じる長い再送バックオフ時間)が発生していないかを監視する。
推定部111が、通信の断絶が発生していると推定した場合、通信端末1と通信先装置2との間の通信に、例えば、パケットの再送等によって生じる、図6に示す通信の断絶が生じている可能性がある。その場合、推定部111又はアプリケーション110等は、確立されているTCP通信を取りやめればよい。そして、推定部111又はアプリケーション110等は、新たにTCP通信を開始する、再接続処理を行う。これにより、図6に示すように、TCP通信を早期に再開することができる。そして、待ち時間が削減される。図6に示す例では、「TCP通信」は、TCPに従った通信プロトコル部130によって制御される通信を表す。「アプリによる制御」は、例えば、通信端末1等のプロセッサによって実行されるアプリケーションプログラムによって行われる処理を表す。「アプリ再接続処理」は、例えば、通信端末1等のプロセッサによって実行されるアプリケーションプログラムによって行われる、再接続の処理を表す。アプリ再接続処理の繰り返しは、パケットの再送の繰り返しではない。従って、アプリ再接続処理では、再接続の失敗が繰り返されても、設けられるバックオフ期間は、指数関数的には増加しない。言い換えると、この場合に設けられるバックオフ期間の増加は、指数関数的ではない。
以上の説明では、通信の状態の推定のための専用のTCP通信が使用される。実際のデータを送信するTCP通信を用いて、通信状態の推定が行われてもよい。具体的には、推定部111は、検査に使用される通信パラメータを、データを送信する際の通信パラメータとして決定すればよい。そして、設定部121は、決定された通信パラメータが設定された状態で、データの送信を開始させればよい。通信エラーの発生が検出された時点で、アプリケーション110等がTCP通信を再開すればよい。そして、データの送信を行うアプリケーション等が、通信エラーによって送信が中断したデータの送信を再開すればよい。
以上で説明した本実施形態には、第1の実施形態と同じ効果がある。その理由は、第1の実施形態の効果が生じる理由と同じである。
<第3の実施形態>
次に、本発明の第3の実施形態の通信状態推定装置10について、図面を参照して詳細に説明する。本実施形態は、上述した各実施形態に共通する概念を表す実施形態である。
図8は、本実施形態の通信状態推定装置10の構成の例を表すブロック図である。
図8を参照すると、本実施形態の通信状態推定装置10は、設定部121と、検出部122と、推定部111と、を備える。設定部121は、与えられた通信パラメータに応じて、通信先装置2との通信において通信エラーの発生を判定する通信装置11に、前記通信パラメータを与える。検出部122は、通信指示を受信するのに応じて前記通信を行う前記通信装置11に前記通信指示を送信し、当該指示に応じた前記通信において判定された通信エラーの発生を検出する。推定部111は、前記通信パラメータ及び前記通信エラーの発生の有無に基づき、前記通信装置11が前記通信をできるか否かを推定する。
以上で説明した本実施形態には、第1の実施形態と同じ効果がある。その理由は、第1の実施形態の効果が生じる理由と同じである。
<他の実施形態>
通信端末1、及び通信状態推定装置10は、それぞれ、コンピュータ及びコンピュータを制御するプログラム、専用のハードウェア、又は、コンピュータ及びコンピュータを制御するプログラムと専用のハードウェアの組合せにより実現することができる。
図9は、通信端末1、及び通信状態推定装置10を実現することができる、コンピュータ1000のハードウェア構成の一例を表す図である。図9を参照すると、コンピュータ1000は、プロセッサ1001と、メモリ1002と、記憶装置1003と、I/O(Input/Output)インタフェース1004とを含む。また、コンピュータ1000は、記録媒体1005にアクセスすることができる。メモリ1002と記憶装置1003は、例えば、RAM(Random Access Memory)、ハードディスクなどの記憶装置である。記録媒体1005は、例えば、RAM、ハードディスクなどの記憶装置、ROM(Read Only Memory)、可搬記録媒体である。記憶装置1003が記録媒体1005であってもよい。プロセッサ1001は、メモリ1002と、記憶装置1003に対して、データやプログラムの読み出しと書き込みを行うことができる。プロセッサ1001は、I/Oインタフェース1004を介して、例えば、通信先装置2、又は通信装置11にアクセスすることができる。プロセッサ1001は、記録媒体1005にアクセスすることができる。記録媒体1005には、コンピュータ1000を、通信端末1、又は通信状態推定装置10として動作させるプログラムが格納されている。
プロセッサ1001は、記録媒体1005に格納されている、コンピュータ1000を、通信端末1、又は通信状態推定装置10として動作させるプログラムを、メモリ1002にロードする。そして、プロセッサ1001が、メモリ1002にロードされたプログラムを実行することにより、コンピュータ1000は、通信端末1、又は通信状態推定装置10として動作する。
推定部111、設定部121、検出部122、通信プロトコル部130、及び通信部140は、例えば、それらの部の機能を実現することができる専用のプログラムと、そのプログラムを実行するプロセッサ1001により実現することができる。その場合、その専用のプログラムは、例えば、その専用のプログラムを記憶する記録媒体1005からメモリ1002に読み込まれる。あるいは、推定部111、設定部121、検出部122、通信プロトコル部130、及び通信部140の一部又は全部を、各部の機能を実現する専用の回路によって実現することもできる。
また、上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
(付記1)
与えられた通信パラメータに応じて、通信先装置との通信において通信エラーの発生を判定する通信装置に、前記通信パラメータを与える設定手段と、
通信指示を受信するのに応じて前記通信を行う前記通信装置に前記通信指示を送信し、当該指示に応じた前記通信において判定された通信エラーの発生を検出する検出手段と、
前記通信パラメータ及び前記通信エラーの発生の有無に基づき、前記通信装置が前記通信をできるか否かを推定する推定手段と、
を備える通信状態推定装置。
(付記2)
前記推定手段は、前記通信パラメータ及び前記通信エラーの発生の有無に基づき、前記通信をできるようになるまでの時間を推定し、当該時間に基づき前記通信装置が前記通信をできるか否かを推定する
付記1に記載の通信状態推定装置。
(付記3)
前記設定手段は、異なる複数の通信パラメータを前記通信装置に送信し、
前記検出手段は、前記複数の通信パラメータの各々について、当該通信パラメータに応じて判定された前記通信エラーの発生を検出する
付記1又は2に記載の通信状態推定装置。
(付記4)
前記設定手段は、前記通信装置が前記通信をできないと推定された場合、再接続指示を受信するのに応じて前記通信先装置に再接続する前記通信装置に、前記再接続指示を送信する
付記1乃至3のいずれかに記載の通信状態推定装置。
(付記5)
前記通信は、前記通信先端末とコネクションを確立する通信を含む
付記1乃至4のいずれかに記載の通信状態推定装置。
(付記6)
前記通信は、データを送信する又は受信する通信を含む
付記1乃至5のいずれかに記載の通信状態推定装置。
(付記7)
前記通信パラメータは、データの再送回数である
付記1乃至6のいずれかに記載の通信状態推定装置。
(付記8)
前記通信パラメータは、通信が断絶している時間である
付記6に記載の通信状態推定装置。
(付記9)
付記1乃至8のいずれかに記載の通信状態推定装置と、前記通信装置と、を含む通信端末。
(付記10)
与えられた通信パラメータに応じて、通信先装置との通信において通信エラーの発生を判定する通信装置に、前記通信パラメータを与え、
通信指示を受信するのに応じて前記通信を行う前記通信装置に前記通信指示を送信し、当該指示に応じた前記通信において判定された通信エラーの発生を検出し、
前記通信パラメータ及び前記通信エラーの発生の有無に基づき、前記通信装置が前記通信をできるか否かを推定する
通信状態推定方法。
(付記11)
前記通信パラメータ及び前記通信エラーの発生の有無に基づき、前記通信をできるようになるまでの時間を推定し、当該時間に基づき前記通信装置が前記通信をできるか否かを推定する
付記10に記載の通信状態推定方法。
(付記12)
異なる複数の通信パラメータを前記通信装置に送信し、
前記複数の通信パラメータの各々について、当該通信パラメータに応じて判定された前記通信エラーの発生を検出する
付記10又は11に記載の通信状態推定方法。
(付記13)
前記通信装置が前記通信をできないと推定された場合、再接続指示を受信するのに応じて前記通信先装置に再接続する前記通信装置に、前記再接続指示を送信する
付記10乃至12のいずれかに記載の通信状態推定方法。
(付記14)
前記通信は、前記通信先端末とコネクションを確立する通信を含む
付記10乃至13のいずれかに記載の通信状態推定方法。
(付記15)
前記通信は、データを送信する又は受信する通信を含む
付記10乃至14のいずれかに記載の通信状態推定方法。
(付記16)
前記通信パラメータは、データの再送回数である
付記10乃至15のいずれかに記載の通信状態推定方法。
(付記17)
前記通信パラメータは、通信が断絶している時間である
付記15に記載の通信状態推定方法。
(付記18)
コンピュータを、
与えられた通信パラメータに応じて、通信先装置との通信において通信エラーの発生を判定する通信装置に、前記通信パラメータを与える設定手段と、
通信指示を受信するのに応じて前記通信を行う前記通信装置に前記通信指示を送信し、当該指示に応じた前記通信において判定された通信エラーの発生を検出する検出手段と、
前記通信パラメータ及び前記通信エラーの発生の有無に基づき、前記通信装置が前記通信をできるか否かを推定する推定手段と、
して動作させる通信状態推定プログラム。
(付記19)
コンピュータを、
前記通信パラメータ及び前記通信エラーの発生の有無に基づき、前記通信をできるようになるまでの時間を推定し、当該時間に基づき前記通信装置が前記通信をできるか否かを推定する前記推定手段と、
して動作させる付記18に記載の通信状態推定プログラム。
(付記20)
コンピュータを、
異なる複数の通信パラメータを前記通信装置に送信する前記設定手段と、
前記複数の通信パラメータの各々について、当該通信パラメータに応じて判定された前記通信エラーの発生を検出する前記検出手段と、
して動作させる付記18又は19に記載の通信状態推定プログラム。
(付記21)
コンピュータを、
前記通信装置が前記通信をできないと推定された場合、再接続指示を受信するのに応じて前記通信先装置に再接続する前記通信装置に、前記再接続指示を送信する前記設定手段と、
して動作させる付記18乃至20のいずれかに記載の通信状態推定プログラム。
(付記22)
前記通信は、前記通信先端末とコネクションを確立する通信を含む
付記18乃至21のいずれかに記載の通信状態推定プログラム。
(付記23)
前記通信は、データを送信する又は受信する通信を含む
付記18乃至22のいずれかに記載の通信状態推定プログラム。
(付記24)
前記通信パラメータは、データの再送回数である
付記18乃至23のいずれかに記載の通信状態推定プログラム。
(付記25)
前記通信パラメータは、通信が断絶している時間である
付記23に記載の通信状態推定プログラム。
以上、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されるものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
この出願は、2014年6月18日に出願された日本出願特願2014−124982を基礎とする優先権を主張し、その開示の全てをここに取り込む。
1 通信端末
2 通信先装置
10 通信状態推定装置
11 通信装置
110 アプリケーション
111 推定部
120 制御部
121 設定部
122 検出部
130 通信プロトコル部
140 通信部
1000 コンピュータ
1001 プロセッサ
1002 メモリ
1003 記憶装置
1004 I/Oインタフェース
1005 記録媒体

Claims (10)

  1. 与えられた通信パラメータに応じて、通信先装置との通信において通信エラーの発生を判定する通信装置に、前記通信パラメータを与える設定手段と、
    通信指示を受信するのに応じて前記通信を行う前記通信装置に前記通信指示を送信し、当該指示に応じた前記通信において判定された通信エラーの発生を検出する検出手段と、
    前記通信パラメータ及び前記通信エラーの発生の有無に基づき、前記通信装置が前記通信をできるか否かを推定する推定手段と、
    を備える通信状態推定装置。
  2. 前記推定手段は、前記通信パラメータ及び前記通信エラーの発生の有無に基づき、前記通信をできるようになるまでの時間を推定し、当該時間に基づき前記通信装置が前記通信をできるか否かを推定する
    請求項1に記載の通信状態推定装置。
  3. 前記設定手段は、異なる複数の通信パラメータを前記通信装置に送信し、
    前記検出手段は、前記複数の通信パラメータの各々について、当該通信パラメータに応じて判定された前記通信エラーの発生を検出する
    請求項1又は2に記載の通信状態推定装置。
  4. 前記設定手段は、前記通信装置が前記通信をできないと推定された場合、再接続指示を受信するのに応じて前記通信先装置に再接続する前記通信装置に、前記再接続指示を送信する
    請求項1乃至3のいずれかに記載の通信状態推定装置。
  5. 前記通信は、前記通信先端末とコネクションを確立する通信を含む
    請求項1乃至4のいずれかに記載の通信状態推定装置。
  6. 前記通信は、データを送信する又は受信する通信を含む
    請求項1乃至5のいずれかに記載の通信状態推定装置。
  7. 請求項1乃至6のいずれかに記載の通信状態推定装置と、前記通信装置と、を含む通信端末。
  8. 与えられた通信パラメータに応じて、通信先装置との通信において通信エラーの発生を判定する通信装置に、前記通信パラメータを与え、
    通信指示を受信するのに応じて前記通信を行う前記通信装置に前記通信指示を送信し、当該指示に応じた前記通信において判定された通信エラーの発生を検出し、
    前記通信パラメータ及び前記通信エラーの発生の有無に基づき、前記通信装置が前記通信をできるか否かを推定する、
    通信状態推定方法。
  9. コンピュータを、
    与えられた通信パラメータに応じて、通信先装置との通信において通信エラーの発生を判定する通信装置に、前記通信パラメータを与える設定手段と、
    通信指示を受信するのに応じて前記通信を行う前記通信装置に前記通信指示を送信し、当該指示に応じた前記通信において判定された通信エラーの発生を検出する検出手段と、
    前記通信パラメータ及び前記通信エラーの発生の有無に基づき、前記通信装置が前記通信をできるか否かの推定を行う推定手段と、
    して動作させる通信状態推定プログラムを記憶する記録媒体。
  10. 前記推定が、前記通信パラメータ及び前記通信エラーの発生の有無に基づき前記通信をできるようになるまでの時間として予測した時間に基づいて行われる
    通信状態推定プログラムを記憶する請求項9に記載の記録媒体。
JP2016529023A 2014-06-18 2015-06-11 通信状態推定装置、通信状態推定方法及び通信状態推定プログラムを記憶する記録媒体 Pending JPWO2015194134A1 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2014124982 2014-06-18
JP2014124982 2014-06-18
PCT/JP2015/002925 WO2015194134A1 (ja) 2014-06-18 2015-06-11 通信状態推定装置、通信状態推定方法及び通信状態推定プログラムを記憶する記録媒体

Publications (1)

Publication Number Publication Date
JPWO2015194134A1 true JPWO2015194134A1 (ja) 2017-05-25

Family

ID=54935143

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016529023A Pending JPWO2015194134A1 (ja) 2014-06-18 2015-06-11 通信状態推定装置、通信状態推定方法及び通信状態推定プログラムを記憶する記録媒体

Country Status (3)

Country Link
US (1) US10310931B2 (ja)
JP (1) JPWO2015194134A1 (ja)
WO (1) WO2015194134A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018098122A1 (en) * 2016-11-23 2018-05-31 Williams Michael B Notification system and method for alerting of valued contents in a vehicle
JP6889835B2 (ja) * 2017-07-14 2021-06-18 コニカミノルタ株式会社 ファクシミリ通信装置およびプログラム

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2745417B2 (ja) * 1989-02-16 1998-04-28 株式会社リコー ファクシミリ装置
JP3866506B2 (ja) * 2000-12-04 2007-01-10 株式会社エヌ・ティ・ティ・ドコモ 電子メールの配信制御方法及びメールサーバ
FI20045450A0 (fi) 2004-11-22 2004-11-22 Nokia Corp Menetelmä ja laite radioyhteyden kontrolloimiseen
GB2425012A (en) * 2005-04-08 2006-10-11 Quadriga Technology Ltd Ranking data files for scheduling transmission
JP4754416B2 (ja) 2006-06-26 2011-08-24 株式会社トヨタIt開発センター 無線通信装置、無線通信方法およびプログラム
US8145967B2 (en) * 2007-10-12 2012-03-27 Oracle America, Inc. System and method for verifying the receive path of an input/output component
EP2243329B1 (en) * 2008-01-11 2013-07-24 Nokia Corp. Scheduling ahead for improving data transmission in case of measurement gaps
US8340586B2 (en) 2008-11-19 2012-12-25 T-Mobile Usa, Inc. System and method for link adaptation for variable link conditions
JP5260251B2 (ja) 2008-12-08 2013-08-14 株式会社トヨタIt開発センター コグニティブ無線システムにおける利用周波数帯調整方法および無線通信装置
JP2011077822A (ja) * 2009-09-30 2011-04-14 Fujitsu Ltd 無線通信装置、無線通信システム、及び無線通信システムにおける無線通信方法
JP5672206B2 (ja) * 2011-09-20 2015-02-18 トヨタ自動車株式会社 利用周波数チャネル選択方法および無線通信装置
US9536081B2 (en) * 2012-06-12 2017-01-03 Intermec Ip Corp. System and process for managing network communications
US9515941B2 (en) * 2012-11-09 2016-12-06 Aruba Networks, Inc. Dynamic determination of transmission parameters based on packet priority and network conditions
US9807780B2 (en) * 2012-11-19 2017-10-31 Nec Corporation Data sharing system
CN107306414A (zh) * 2016-04-21 2017-10-31 富士通株式会社 故障诊断方法、装置和系统

Also Published As

Publication number Publication date
WO2015194134A1 (ja) 2015-12-23
US10310931B2 (en) 2019-06-04
US20170116063A1 (en) 2017-04-27

Similar Documents

Publication Publication Date Title
US9768917B2 (en) Communication control method, network system, and communication device
JP6279938B2 (ja) 接続管理装置、通信システム、接続管理方法およびプログラム
US10193661B2 (en) Communication device, non-transitory computer readable medium and wireless communication system
US9167614B2 (en) Tunneled direct link setup systems and methods with consistent link information maintenance
WO2012101763A1 (ja) 通信装置、通信システム、通信方法、および通信プログラム
US20170099668A1 (en) Method, device and system for controlling air interface resource
TW201946489A (zh) 多閘道通訊方法及其無線閘道系統
JP5720793B2 (ja) データ転送方法およびそれを用いるノード装置
US20160269957A1 (en) Method for selecting network and electronic device therefor
US20170171092A1 (en) Network analysis and monitoring tool
CN114363147B (zh) 用于媒体访问控制安全性的改善的错误处理
CN108124504B (zh) Tfo传输方法、代理服务器和系统
WO2015194134A1 (ja) 通信状態推定装置、通信状態推定方法及び通信状態推定プログラムを記憶する記録媒体
US11617120B2 (en) Communication system, node, communication method, and computer program product
TWI727519B (zh) 終端裝置、通信系統及通信方法
JP5702255B2 (ja) アドホックネットワーク通信端末およびアドホックネットワーク通信端末の制御方法
Stais et al. Error and congestion control for wireless sensor networks
JP2012065071A (ja) 中継装置、中継システム、及び中継プログラム
JP2009065617A (ja) Lan通信システム
KR101031300B1 (ko) 동적으로 토폴로지가 변하는 통신망을 위한 가상 전송 방법 및 장치
WO2021192293A1 (ja) 基地局、無線通信システム、及び無線通信方法
JP5324038B2 (ja) 通信制御装置、無線通信装置、通信制御方法及び無線通信方法
JP2015136010A (ja) 無線通信装置、無線通信システム、無線通信方法及び無線通信プログラム
EP3327988A1 (en) System and method for improving multicast latency and reliability of multicast transmissions in a wireless building automation network
JP2016167789A (ja) 通信装置、通信システム、通信方法及び制御プログラム

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161213