JP6128580B2 - 通信装置、通信制御方法およびプログラム - Google Patents

通信装置、通信制御方法およびプログラム Download PDF

Info

Publication number
JP6128580B2
JP6128580B2 JP2012216431A JP2012216431A JP6128580B2 JP 6128580 B2 JP6128580 B2 JP 6128580B2 JP 2012216431 A JP2012216431 A JP 2012216431A JP 2012216431 A JP2012216431 A JP 2012216431A JP 6128580 B2 JP6128580 B2 JP 6128580B2
Authority
JP
Japan
Prior art keywords
communication
protocol
layer
event
processing
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.)
Active
Application number
JP2012216431A
Other languages
English (en)
Other versions
JP2014072647A (ja
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 Communication Systems Ltd
Original Assignee
NEC Communication Systems Ltd
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 Communication Systems Ltd filed Critical NEC Communication Systems Ltd
Priority to JP2012216431A priority Critical patent/JP6128580B2/ja
Publication of JP2014072647A publication Critical patent/JP2014072647A/ja
Application granted granted Critical
Publication of JP6128580B2 publication Critical patent/JP6128580B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Communication Control (AREA)

Description

本発明は、複数の通信層における動作を制御する通信装置、通信制御方法、およびコンピュータに実行させるためのプログラムに関する。
通信装置は、階層状に配置された複数の通信層を備えているプロトコル・スイートを使用して通信を行う。プロトコル・スイートの1つとして、インターネット・プロトコル・スイートが知られている(非特許文献1参照)。インターネット・プロトコル・スイートは、リンク層、インターネット層、トランスポート層、およびアプリケーション層の4階層に分類されている。
アプリケーション層は、インターネット・プロトコル・スイートの最上位層であり、データ通信を利用した様々なサービスの提供、データとユーザがわかりやすい形との相互変換、データを送受信するための仮想的なコネクションの管理などを行う。
トランスポート層は、アプリケーションのためにエンド・ツー・エンドの通信サービスを提供する。トランスポート層に分類されるプロトコルとして、例えば、TCP(Transmission Control Protocol)がある。
インターネット層については、データを送信元から宛先ホストに運ぶためにインターネットプロトコル(IP)を使用する。IPはコネクションレス、または、データグラム相互ネットワークサービスであり、エンド・ツー・エンドでの配送保証は提供しない。IPは、アドレス付けやサービスタイプの指定や、フレームの分割や組立などを行う。
リンク層については、通信機が直接接続されたネットワーク上で通信するために、ネットワークにインタフェース接続するために使用される通信プロトコルを実装しなければならない。このプロトコルのことを、リンク層プロトコルと呼ぶ。
各通信層は隣り合う層とだけ通信を行うことができる。プロトコル・スイートは、インターネット・プロトコル・スイート以外にも、OSI(Open Systems Interconnection)参照モデル(非特許文献2参照)も知られているが、階層に分かれている点で実質的に同じである。
このようなプロトコル・スイートは、非特許文献3に開示されているように、安定した有線による通信を前提に考えられてきた。
しかし、今日、無線通信、光通信、省エネ通信など、通信環境が多様化され、上述の階層型アクセスだけでは、うまく動作しない場合が出てきた。例えば、非特許文献4には、無線アドホックネットワークでのクロスレイヤアクセスの必要性が述べられている。また、非特許文献5で規定されているように、不安定な無線ネットワークでモビリティを確保する場合は、TCPのパラメータをデータリンク層のパラメータに応じて制御する必要がある。すなわち各通信層間において自由なクロスレイヤアクセスが必要である。クロスレイヤアクセスとは、ある通信層が隣り合う通信層を跨いで他の通信層とアクセスすることである。
各通信層に自由にアクセスする方法として複数のタイプが知られている。非特許文献6では、その方法が「新アブストラクション型」、「共通データベース型」および「直接コミュニケーション型」の3つに分類されている。
「新アブストラクション型」は、各通信層が階層化されておらず、完全に独立して動作する通信形式である。しかし、既存の通信層を用いた通信機器との互換性が失われてしまう問題がある。インターネットを利用する通信システムは、インターネット層、トランスポート層といった通信階層を利用するように設計されているが、この既に幅広く普及している通信階層構造を全て無視して一から全て作り直し、使用するのは非現実的である。
「共通データベース型」は、例えば、特許文献1に開示されているような「クロスレイヤオプティマイザ」とよばれる一つの新たな階層を設ける方法である。これは、新たな階層を設けて、階層化された通信システムの全ての階層をコントロールする方法である。
しかし、一つの階層が全ての情報を把握し、最終的に判断する方法であるため、一つの目的に対する場合はうまく動作するが、今後、スマートフォンのように様々な目的のために複数のアプリケーションを入れ替えて複数動作させる場合には、一つの階層が総合的に判断、最適化するのは困難である。また、各通信層から様々な情報を得るためには、各通信層に対して、通信するためのインタフェースを必要な数だけ設けなければならず、インタフェース数が増大するおそれがある。そのため、管理が複雑になり、拡張性に乏しいという問題がある。
「直接コミュニケーション型」は、階層化された通信システムの個々の層間でクロスレイヤアクセスを実現する方法である。このように複数のアプリケーションを入れ替えるような場合は、個々のアプリケーションや通信層が独立して動作するのがよりよいと考えられる。
「直接コミュニケーション型」の方法が非特許文献7においてさらに詳細に分類されており、非特許文献7では、最適なアクセス手法として「CLASS」が提案されている。
特表2007−515833号公報
RFC1122, "Requirements for Internet Hosts - Communication Layers" ISO 7498, "Information processing systems -- Open Systems Interconnection -- Basic Reference Model" "無線通信におけるクロスレイヤネットワーキング技術", 信学技報, vol. 108, no. 447, AN2008-76, pp. 71-76, 2009年3月 "無線アドホックネットワークにおけるクロスレイヤシグナリングベース負荷制御方式", 信学技報, vol. 106, no. 356, CQ2006-76, pp. 95-100, 2006年11月 RFC 3481, "TCP over 2.5G and 3G Wireless Networks" Srivastava, V.; Motani, M. "Cross-layer design: a survey and the road ahead", IEEE Communications Magazine. Volume 43, Issue 12, Dec. 2005, Page(s): 112- 119 Qi Wang; Abu-Rgheff, M.A. "Cross-layer signalling for next- generation wireless systems", IEEE Wireless Communications and Networking conference, WCNC 2003.Volume 2, 16-20 March 2003, Page(s): 1084- 1089
しかし、非特許文献7に開示された手法では、通信層間のメッセージを規定しているだけにすぎず、通信層を超えてアクセスする仕組みについては具体的に示されていない。また、非特許文献6には、「直接コミュニケーション型」の方法でメッセージフォーマットを規定することが提案されているが、実際にどのように実施するか具体的が示されていない。
本発明は上述したような技術が有する問題点を解決するためになされたものであり、複数の通信層に対するクロスレイヤアクセスを容易に可能にした通信装置、通信制御方法、およびコンピュータに実行させるためのプログラムを提供することを目的とする。
上記目的を達成するための本発明の通信装置は、
階層化された複数の通信層におけるプロトコルの処理動作をイベント受信、イベント処理およびイベント送信という要素からなるイベントモデルで管理するための、前記プロトコルに含まれる機能が記述されたテーブルが格納された記憶部と、
前記階層化された複数の通信層を介して外部の通信装置とデータを送受信する際、各通信層間でやりとりする情報をイベントと規定し、各通信層のプロトコルの処理動作を、前記イベントモデルで管理し、前記テーブルを用いて、各通信層間の接続情報および各通信層の処理動作の写像を通信単位でチェーンとして管理し、前記イベント受信時に前記テーブルを参照して前記チェーンにしたがって、各通信層内のプロトコルに含まれる機能のうち、どの機能を使用するかを決定して実行する制御部を有する構成である。
また、本発明の通信制御方法は、通信装置による通信制御方法であって、
階層化された複数の通信層におけるプロトコルの処理動作をイベント受信、イベント処理およびイベント送信という要素からなるイベントモデルで管理するための、前記プロトコルに含まれる機能が記述されたテーブルが格納された記憶部を有する通信装置による通信制御方法であって、
前記階層化された複数の通信層を介して外部の通信装置とデータを送受信する際に、各通信層間でやりとりする情報をイベントと規定し、
各通信層のプロトコルの処理動作を、前記イベントモデルで管理し、
前記テーブルを用いて、各通信層間の接続情報および各通信層の処理動作の写像を通信単位でチェーンとして管理し、前記イベント受信時に前記テーブルを参照して前記チェーンにしたがって、各通信層内のプロトコルに含まれる機能のうち、どの機能を使用するかを決定して実行するものである。
さらに、本発明のプログラムは、コンピュータに、
階層化された複数の通信層におけるプロトコルの処理動作をイベント受信、イベント処理およびイベント送信という要素からなるイベントモデルで管理するための、前記プロトコルに含まれる機能が記述されたテーブルが格納された記憶部を有するコンピュータに、
前記階層化された複数の通信層を介して外部の通信装置とデータを送受信する際に、各通信層間でやりとりする情報をイベントと規定する手順と、
各通信層のプロトコルの処理動作を、前記イベントモデルで管理する手順と、
前記テーブルを用いて、各通信層間の接続情報および各通信層の処理動作の写像を通信単位でチェーンとして管理し、前記イベント受信時に前記テーブルを参照して前記チェーンにしたがって、各通信層内のプロトコルに含まれる機能のうち、どの機能を使用するかを決定して実行する手順を前記コンピュータに実行させるものである。
本発明によれば、複数の通信層における動作に関して予め規定したイベントモデルにしたがって処理を行うことで、クロスレイヤアクセスを容易に実行できる。
第1の実施形態の通信装置の一構成例を示すブロック図である。 図1に示した制御部で実行されるプロトコル・スイートの一例を示す図である。 CPUが図2に示したプロトコルを実行することで実現される仮想的な構成を示す機能ブロック図である。 2つの通信装置が通信する場合の情報処理方法を示す模式図である。 クロスレイヤアクセスを説明するための図である。 第1の実施形態において、通信層の上り方向の処理手順を決定するための上り処理テーブルの一例を示す図である。 第1の実施形態において、通信層の下り方向の処理手順を決定するための下り処理テーブルの一例を示す図である。 第1の実施形態において、各通信層において制御部がプロトコルを決定するため手順を示すフローチャートである。 第1の実施形態の通信装置の動作を説明するための図である。 第2の実施形態におけるプロトコル・スイートを説明するための図である。 第2の実施形態において、制御部によるプロトコル内の機能の実行の手順を示すフローチャートである。 第2の実施形態において、通信層の上り方向の処理手順を決定するための上り処理テーブルの一例を示す図である。 第2の実施形態において、エラーチェックのクロスレイヤ処理を説明するための図である。 本発明の一実施形態の通信装置の構成例を示すブロック図である。
(第1の実施形態)
本実施形態の通信装置の構成を説明する。図1は本実施形態の通信装置の一構成例を示すブロック図である。
図1に示すように、通信装置100は、記憶部190と、制御部180とを有する。制御部180は、プログラムにしたがって処理を実行するCPU(Central Processing Unit)182と、プログラムを記憶するメモリ184とを有する。メモリ184には、後述のクロスレイヤアクセスを実行するためのプログラムが格納されている。
図2は図1に示した制御部で実行されるプロトコル・スイートの一例を示す図である。本実施形態では、プロトコル・スイートがインターネット・プロトコル・スイートの場合とする。
図2に示すプロトコル・スイートがメモリ184に予め格納されている。プロトコル・スイートはメモリ184の代わりに記憶部190に予め格納されていてもよく、この場合、CPU182の実行対象となるプロトコルが記憶部190からメモリ184に読み出される。図2では、プロトコル・スイートに含まれる複数のプロトコルを、階層化された複数の通信層に分類して表示している。
プロトコル・スイートは、リンク層L001、インターネット層L002、トランスポート層L003、およびアプリケーション層L004を有する。
リンク層L001には、無線LAN(Local Area Network)プロトコルP110、WiMAX(Worldwide Interoperability for Microwave Access)プロトコルP120、およびLTE(Long Term Evolution)プロトコルP130が属する。インターネット層L002には、IP P210が属する。トランスポート層L003には、TCP P310およびUDP P320が属する。アプリケーション層L004には、動画アプリケーションソフトウェアプログラム(以下では、「動画アプリケーション」と称する)P410と、Webアプリケーション・ソフトウェアプログラム(以下では、「Webアプリケーション」と称する)P420とが属している。Webアプリケーションの一例としてWebブラウザがある。
図2に示すように、通信層は階層的に構成されており、隣り合う通信層とのみアクセスできるようになっている。例えば、アプリケーション層L004は、トランスポート層L003にアクセスすることができるが、インターネット層L002に直接アクセスすることはできない。インターネット層L002は、トランスポート層L003とリンク層L001にアクセスすることができるが、アプリケーション層L004と直接アクセスすることができない。
図2に示す4つの通信層において、最下層から最上層への処理の流れの方向を上り方向とし、最上層から最下層への処理の流れの方向を下り方向とする。
なお、TCPの概要はRFC793に開示され、UDPの概要はRFC768に開示されているため、本実施形態では、これらのプロトコルについての詳細な説明を省略する。IPの概要については、RFC791に開示されているため、その詳細な説明を省略する。また、無線LANプロトコルの概要はIEEE802.11に開示され、WiMAXプロトコルの概要はIEEE802.16eに開示され、LTEプロトコルの概要は3GPP Release.8に開示されているため、これらのプロトコルの詳細な説明を省略する。
図2に示すプロトコル・スイートは一例であり、階層化された複数の通信層からなるプロトコル・スイートを備えていれば、図2に示したものと異なるアプリケーションソフトウェアプログラムおよびプロトコルを備えていてもよい。
図3はCPUが図2に示したプロトコルを実行することで具現化される論理的な構成を示す機能ブロック図である。
制御部180は、アプリケーション層L004に分類される動画処理部410およびWebアプリケーション処理部420と、トランスポート層L003に分類されるTCP処理部310およびUDP処理部320と、インターネット層L002に分類されるIP処理部210と、リンク層L001に分類される無線LAN通信部110、WiMAX通信部120およびLTE通信部130とを有する。
動画処理部410はCPU182が動画アプリケーションP410を実行することで仮想的に構成され、Webアプリケーション処理部420はCPU182がWebアプリケーションP420を実行することで仮想的に構成される。
TCP処理部310はCPU182がTCP P310を実行することで仮想的に構成され、UDP処理部320はCPU182がUDP P320を実行することで仮想的に構成される。IP処理部210はCPU182がIP P210を実行することで仮想的に構成される。
無線LAN通信部110は、CPU182による無線LANプロトコルP110の実行と無線LAN専用の通信デバイスで構成される。WiMAX通信部120は、CPU182によるWiMAXプロトコルP120の実行とWiMAX専用の通信デバイスで構成される。LTE通信部130は、CPU182によるLTEプロトコルP130の実行とLTE専用の通信デバイスで構成される。
制御部180は、図2に示したプロトコル・スイートを用いて図3に示した各部を制御することで、別の通信装置と通信することが可能である。以下では、説明を簡単にするために、図3の機能ブロック図に示した各構成の代わりに、図2に示したプロトコルまたはプログラムを動作の主体にして説明する。
ここで、通信装置100が他の通信装置と通信する場合を簡単に説明する。図4は2つの通信装置が通信する場合の情報処理方法を示す模式図である。
通信装置102は通信装置100と同様な構成である。
なお、図4では、リンク層L001内の無線LANプロトコルP110が通信装置100と通信装置102との間で直接通信する様子を示しているが、アクセスポイント(不図示)およびLAN(不図示)を経由する通信に経路を使用してもよく、特に通信形態は問わない。また、図4では、アプリケーション層L004内のアプリケーションについても、通信装置100と通信装置102との間で直接通信する様子を示しているが、サーバアプリケーション(不図示)を経由してもよい。他のプロトコルについても、上記の説明と同様に、直接に通信する場合に限定されない。
図4に示すように、同一の通信層における同一のプロトコル同士で情報交換が行われる。実線および破線の双方向矢印は、各通信層におけるプロトコル間のやりとりを表現したものである。アプリケーション層L004を例に説明すると、WebアプリケーションP420で扱われるデータは通信装置100のWebアプリケーション処理部420で処理され、WebアプリケーションP421で扱われるデータは通信装置102のWebアプリケーション処理部420で処理される。実線の双方向矢印に示すように、WebアプリケーションP420、P421で扱われるデータは通信装置100と通信装置102のそれぞれのWebアプリケーション処理部420で処理される。また、破線の双方向矢印に示すように、動画アプリケーションP410で扱われるデータは通信装置100と通信装置102のそれぞれの動画処理部410で処理される。
実際には、例えば、WebアプリケーションP421で扱われるデータを通信装置100が通信装置102に送信する場合、そのデータは、通信装置100のアプリケーション層L004からトランスポート層L003およびインターネット層L002を順に経由してリンク層L001から通信装置102に送信される。通信装置102では、通信装置100から受信したデータは、リンク層L001からインターネット層L002およびトランスポート層L003を順に経由してアプリケーション層L004に至り、Webアプリケーション処理部420で処理される。その結果、通信層毎のデータ処理は図4の模式図に示すように表される。
ここまで、通常の動作に関する制御部180の構成を説明したが、本実施形態の通信装置100に追加された、クロスレイヤアクセスの機能に関する構成を説明する。
はじめに、クロスレイヤアクセスを、図5を参照して説明する。図5は図2に示したプロトコル・スイートをベースにしてクロスレイヤアクセスを説明するための図である。
図5には、動画アプリケーションP410が、リンク層L001内の無線LANプロトコルP110、WiMAXプロトコルP120およびLTEプロトコルP130と、インターネット層L002内のIP P210と、トランスポート層L003内のTCP P310のそれぞれから情報を取得可能であることを上向きの破線矢印で示している。
厳密に言うと、動画アプリケーションP410がTCP P310にアクセスするのは、隣り合う通信層との情報のやりとりなのでクロスレイヤアクセスに相当しないが、各プロトコルの情報について、隣り合う通信層との情報のやりとりであっても予めプロトコルで規定された通常のやりとり以外の場合も含めて、以下では、クロスレイヤアクセスと称する。
各プロトコルの情報とは、例えば、リンク層L001での無線環境における品質情報(再送数、信号電力強度など)、インターネット層L002でのルーティング情報および最大パケットサイズの情報、トランスポート層L003でのTCPウィンドウサイズおよび再送数などの情報である。
また、図5には、動画アプリケーションP410が、これらの情報を使ってトランスポート層L003内のTCP P310に最適なTCPウィンドウサイズを設定したり、リンク層L001で使用する回線を選ぶためにインターネット層L002内のIP P210にパラメータを設定したりすることが可能なことを下向きの破線矢印で示している。
動画アプリケーションP410と同様に、図5では、WebアプリケーションP420が、リンク層L001内の無線LANプロトコルP110、WiMAXプロトコルP120およびLTEプロトコルP130と、インターネット層L002内のIP P210と、トランスポート層L003内のTCP P310のそれぞれから情報を取得可能であることを上向きの矢印で示している。また、WebアプリケーションP420が、使用するリンク層での回線を選ぶためにインターネット層L002内のIP P210にパラメータを設定可能なことを下向きの矢印で示している。
続いて、図5を参照して説明したクロスレイヤアクセスを実行可能にするための記憶部190および制御部180の構成を説明する。
記憶部190には、制御部180が実行するプロトコルの処理手順を決めるための処理テーブルが格納されている。図6Aは通信層の上り方向の処理手順を決定するための上り処理テーブルの一例を示し、図6Bは通信層の下り方向の処理手順を決定するための下り処理テーブルの一例を示す。
各処理テーブルには複数種の処理手順が予め登録されており、各処理手順は管理番号で管理される。図6Aおよび図6Bに示すように、各処理テーブルは、管理番号に対応して、各通信層で使用されるプロトコルが記述されている。図6Aおよび図6Bに示す例では、管理番号が0からn(nは1以上の整数)までの(n+1)種の処理手順が登録されている。
各処理テーブルに示す通信層#001〜004のそれぞれはリンク層L001、インターネット層L002、トランスポート層L003およびアプリケーション層L004のそれぞれに相当する。
図6Aの上り処理テーブルを参照すると、例えば、管理番号が0の場合の処理手順では、通信層#L001で無線LANプロトコルP110を使用し、通信層#L002でIP P210を使用することがわかる。そして、通信層#L003で使用されるプロトコルは「selectable」となっている。この「selectable」は、予め規定された選択処理、すなわちIP P210で管理されるプロトコル番号で特定されるプロトコルを選択することを示す。通信層#L004で使用されるプロトコルも「selectable」となっている。これは、予め規定された選択処理、すなわちトランスポート層L003のプロトコルで管理されるポート番号でどのアプリケーションを選択するかを示している。
また、図6Aの上り処理テーブルにおいて、管理番号が2の場合の処理手順では、通信層#L001でWiMAXプロトコルP120を使用し、通信層#L004で動画アプリケーションP410を使用することがわかる。そして、通信層#L002で使用されるプロトコルは「NULL」となっている。この「NULL」は、その通信層では何も処理をせずに、メッセージを含むデータをそのまま次の通信層に渡すことを意味する。通信層#L003で使用されるプロトコルも「NULL」となっており、通信層#002の場合と同様である。
このようにして、各通信層間の接続情報と各通信層の処理動作の写像を通信単位でチェーンとして管理している。そして、管理番号に基づいて複数の通信層における一連の処理が鎖状に決定されるので、この一連の処理をチェーンと称する。また、管理番号がチェーンを特定するための番号であることから、以下では、管理番号をチェーン番号と称する場合もある。
なお、本実施形態では、図6Aおよび図6Bに示したように、処理テーブルを上りと下りで別々に準備し、0からnまでの番号で(n+1)種の処理手順を管理する場合で説明したが、上りと下りのそれぞれの場合に応じて使用するプロトコルを特定できれば1つのテーブルであってもよい。また、処理手順を特定するための識別子は管理番号に限らず、通信相手のアドレスなど、制御部180が処理手順を特定できれば他の識別子でもよい。
また、本実施形態では、処理手順を特定するための管理番号は、情報発信またはプロトコル制御したい発信元のプロトコルが付与し、必要な情報や制御情報を含むメッセージに含めるものとするが、通信装置100の通信相手から受信するデータに添付されていてもよく、管理番号の入手方法はこれらの場合に限らない。
制御部180は、外部の装置からデータを受信すると、リンク層L001内のプロトコルを実行することで管理番号を設定する。そして、制御部180は、リンク層L001よりも上位の各通信層において、図6Aに示した処理テーブルを参照して管理番号に対応するチェーンを特定し、特定したチェーンにしたがって処理を実行する。ここでは、データを受信した際に常に管理番号を設定する例を示したが、既存の処理には手を付けず、クロスレイヤ処理をしたい場合にのみ管理番号を付与してもよい。またデータの受信にかかわらず、必要や要求に応じて情報を送信したり制御したりしたい場合に管理番号を付与してもよい。
また、制御部180は、外部の装置にデータを送信する際、データの種類や形式に応じてアプリケーション層L004内のアプリケーションを実行することで管理番号を決定する。そして、制御部180は、アプリケーション層L004よりも下位の各通信層において、図6Bに示した処理テーブルを参照して管理番号に対応するチェーンを特定し、特定したチェーンにしたがって処理を実行した後、データに管理番号を添付して外部の装置に送信する。ここでは、外部の装置にデータを送信する際に常に管理番号を設定する例を示したが、必要や要求に応じて情報を送信したり制御したりしたい場合に管理番号を付与してもよい。
図7は各通信層において制御部がプロトコルを決定するための手順を示すフローチャートである。制御部180は、図2に示した4つの通信層のうち、外部の装置からデータを受信し、アプリケーションがデータを受信した場合には、リンク層L001からアプリケーション層L004まで、アプリケーションが外部の装置にデータを送信する場合には、アプリケーション層L004からリンク層L001まで、通信層毎に図7に示すフローの処理を行う。
ここでは、各通信層のプロトコルの種類がm(mは1以上の整数)個あるものとし、図7では、種類k(kは1以上m以下の任意の整数)のプロトコルを「#k」と表記している。例えば、図5を参照すると、インターネット層L002ではm=1であり、トランスポート層L003ではm=2である。
各通信層において、制御部180は、処理テーブルを参照し、情報処理対象の通信層の情報と管理番号とに基づいて、どのプロトコルの処理をデータに対して行うか判定する(ステップCF01)。続いて、制御部180は、ステップCF01で決定したプロトコルの処理をデータに実行する(ステップCF02−1〜CF02−m)。ただし、ステップCF01で特定した内容が「NULL」である場合、制御部180は、データに対して何も処理しない(ステップCF02−(m+1))。
次に、本実施形態の通信装置100の動作を説明する。
通信装置100が外部の装置からデータを受信したものとし、制御部180は、図6Aに示した処理テーブルを参照する。
図8は本実施形態の通信装置の動作を説明するための図である。図8では、図2に示したプロトコル・スイートの各通信層におけるプロトコル処理に加えて、隣り合う通信層の間で情報を振り分ける処理を模式的に示している。具体的には、通信層間の振り分け処理を行う通信層間インタフェースを図に示している。
図8に示すインタフェースL012、L023、L034は、通信層間の処理を、わかり易く説明するために追加したものである。インタフェースL012、L023、L034は、制御部180が図7に示したステップCF01の処理を実行することで仮想的に構成される。
また、図8に示すように、RSS(Receive Signal Strength:受信信号強度)伝達機能P111が無線LANプロトコルP110内に設けられ、管理番号が2の場合に有効になることが予め設定されているものとする。RSS伝達機能P111は、無線LANプロトコルP110内で管理されている受信信号電力強度の値を、動画アプリケーションP410に伝える機能とする。この機能により、例えば、動画アプリケーションP410は、受信信号電力強度の値を動画品質の判定に使用することが可能となる。
はじめに、図6Aおよび図8を参照して、通信装置100が実行するクロスレイヤ処理(レイヤスキップ)の場合を説明する。ここでは、管理番号が2の場合で説明する。
RSS伝送機能P111は、無線LANのフレームを外部から受信すると、フレームから受信信号電力強度の情報を読み出す。そして、RSS伝達機能P111は、管理番号「2」を設定し、上位層であるインターネット層L002宛にインタフェースL012を介して、管理番号を含むメッセージとともに受信信号電力強度のデータを送信する。
インタフェースL012は、RSS伝達機能P111を含む無線LANプロトコルP110からメッセージとともに受信信号電力強度のデータを受信すると、上り処理テーブルを参照し、メッセージに含まれる管理番号に基づいてチェーンを特定し、特定したチェーンにしたがって処理を分岐させる。
図6Aに示した上り処理テーブルでは、管理番号が2の場合の通信層#002の欄が「NULL」なので、インターネット層L002では何も処理しない。インタフェースL012は、図7に示したステップCF02−(m+1)にしたがって、メッセージを含む受信信号電力強度のデータをIP P210に渡さずに、トランスポート層L003宛にインタフェースL023を介して送信する。
インタフェースL023は、インタフェースL012からメッセージを含む受信信号電力強度のデータを受信すると、上り処理テーブルを参照し、メッセージに含まれる管理番号に基づいてチェーンを特定し、特定したチェーンにしたがって処理を分岐させる。
図6Aに示した上り処理テーブルでは、管理番号が2の場合の通信層#003の欄が、通信層#002の欄と同様に、「NULL」なので、トランスポート層L003でも、何も処理しない。インタフェースL023は、図7に示したステップCF02−(m+1)にしたがって、メッセージを含む受信信号電力強度のデータをアプリケーション層L004宛にインタフェースL034を介して送信する。
インタフェースL034は、インタフェースL023からメッセージを含む受信信号電力強度のデータを受信すると、上り処理テーブルを参照し、メッセージに含まれる管理番号に基づいてチェーンを特定し、特定したチェーンにしたがって処理を分岐させる。
図6Aに示した上り処理テーブルでは、管理番号が2の場合の通信層#004の欄が「P410」なので、インタフェースL034は、受信信号電力強度のデータを動画アプリケーションP410に送信する。動画アプリケーションP410は、インタフェースL034から受信信号電力強度のデータを受け取ると、その値を動画品質の判定に使用する。
管理番号が2の場合、上述したように、リンク層L001の無線LANプロトコルP110がアプリケーション層L004の動画アプリケーションP410に情報を送信することができる。このような処理手順で、インタフェースを共通にしたまま通信層を跨いで情報のやりとりを行うことが可能となる。
次に、図6Aおよび図8を参照して、通信装置100が実行する、通常のデータパケット処理の場合を説明する。ここでは、管理番号が0の場合で説明する。
リンク層L001内の無線LANプロトコルP110が、外部からデータパケットを受信すると、通常のデータパケット処理を行い、管理番号「0」を設定し、その管理番号を含むメッセージとともにデータパケットを上位層であるインターネット層L002宛にインタフェースL012に送信する。
インタフェースL012は、無線LANプロトコルP110からメッセージとともにデータパケットを受信すると、上り処理テーブルを参照し、メッセージに含まれる管理番号に基づいてチェーンを特定し、特定したチェーンにしたがって処理を分岐させる。
図6Aに示した上り処理テーブルでは、管理番号が0の場合の通信層#002の欄が「P210」なので、インタフェースL012は、メッセージを含むデータパケットをIP P210に送信する。IP P210は、インタフェースL012から受け取ったデータパケットに予め規定された処理を行った後、メッセージを含むデータパケットをトランスポート層L003宛にインタフェースL023を介して送信する。
インタフェースL023は、IP P210からメッセージを含むデータパケットを受信すると、上り処理テーブルを参照し、メッセージに含まれる管理番号に基づいてチェーンを特定し、特定したチェーンにしたがって処理を分岐させる。
図6Aに示した上り処理テーブルでは、管理番号が0の場合の通信層#003の欄が「selectable」なので、インタフェースL023は管理番号だけでは送信先のプロトコルを特定できない。そこで、インタフェースL023は、IPヘッダに記述されたプロトコル番号を参照して、送信先のプロトコルを決定する(トランスポート層プロトコルの特定処理)。ここでは、プロトコル番号が「6」であるとすると、インタフェースL023は、送信先をTCP P310に決定し、TCP P310にメッセージを含むデータパケットを送信する。TCP P310は、インタフェースL023から受け取ったデータパケットに予め規定された処理を行った後、メッセージを含むデータパケットをアプリケーション層L004宛にインタフェースL034を介して送信する。ここでは、インタフェースL023が、IPヘッダを解析する場合で説明したが、IP P210内で通常実施される上述のトランスポート層プロトコルの特定処理の結果を受け取り、その結果に対応して処理を分岐させる、すなわちTCP P310にメッセージを含むデータパケットを送信することが可能である。
インタフェースL034は、TCP P310からメッセージを含むデータパケットを受信すると、上り処理テーブルを参照し、メッセージに含まれる管理番号に基づいてチェーンを特定し、特定したチェーンにしたがって処理を分岐させる。
図6Aに示した上り処理テーブルでは、管理番号が0の場合の通信層#004の欄が通信層#003の場合と同様に「selectable」なので、インタフェースL034は管理番号だけでは送信先のプロトコルを特定できない。そこで、インタフェースL034は、TCPヘッダに記述されたポート番号を参照して、送信先のプロトコルを決定する(アプリケーション層プロトコルの特定処理)。ここでは、動画アプリケーション用に規定されたポート番号が「10000」であるとすると、インタフェースL034は、送信先を動画アプリケーションP410に決定し、動画アプリケーションP410にメッセージを含むデータパケットを送信する。動画アプリケーションP410は、インタフェースL034からデータパケットを受け取ると、データパケットを処理して動画を表示部(不図示)に表示させる。
ここでは、インタフェースL034が、TCPヘッダを解析する場合で説明したが、TCP P310内で通常実施される上述のアプリケーション層プロトコルの特定処理の結果を受け取り、その結果に対応して処理を分岐させる、すなわち動画アプリケーションP410にメッセージを含むデータパケットを送信することが可能である。
管理番号が0である場合、クロスレイヤではなく、階層順に通常のプロトコル処理を行うことができる。このような処理手順で既存のデータパケットをアプリケーションに届けること可能となる。
なお、上述の動作の説明において、インタフェースおよびプロトコルの間で「データを送信する」と表現したが、実際にはインタフェースおよびプロトコルが記憶部190にデータを記憶させ、データの格納場所を示す情報(例えば、アドレスなど)を互いにやりとりしてもよい。また、ここでは上り方向の処理例を示したが下り方向も同様にして実現することが可能であり、その詳細な説明を省略する。
次に、本実施形態の通信装置100による情報処理方法の効果を説明する。
本実施形態では、各通信層間でやりとりする情報をイベントと規定し、各通信層の動作を、イベント受信、イベント処理およびイベント送信という要素からなるイベントモデルで表現し、各通信層間の接続情報と各通信層の処理動作の写像を通信単位でチェーンとして管理している。そして、通信層をまたがる際にチェーンを参照し、各通信層内での処理を分岐させることで、各通信層間で自由にアクセスすることを可能にしている。
そのため、各通信層が独立してイベントモデルとして動作し、複数の通信層の処理が総合的に最適化されるため、複数のアプリケーションが動作し、自由に入れ替えられるような環境下でも、無駄な処理を省いて、全体として最適化される。イベントとは、例えば、管理番号を含むメッセージと処理対象のデータの情報である。
また、クロスレイヤ処理の追加に際して、各通信層のインタフェースを増やすことなく、広い拡張性、移植の容易性を有している。その理由は、各通信層内にクロスレイヤ処理を追加し、その処理は整理、規定された共通に使用できるクロスレイヤインタフェースを利用できるからである。
さらに、複数のアプリケーションが動作し、自由に入れ替えられるような環境でも、アプリケーションの通信処理単位で各通信層へ情報を伝えることができる。例えば、リンク層で切断イベントが発生した場合に、アプリケーションの通信処理に対して迅速に通知することが可能である。その理由は、チェーンで管理されたクロスレイヤアクセスが提供されるため、各プロトコルにおいて、チェーンの使用を管理でき、チェーンにしたがって、使用中のチェーンの宛先を参照して複数のアプリケーションへ同報、または1つのアプリケーションへ通知できるからである。
なお、各通信層のプロトコルの処理と、図7に示したステップCF01の処理(図8のインタフェースに相当)の処理とを別々のハードウェアで実行させるようにしてもよい。例えば、各プロトコルに対応した専用の集積回路を設け、CPU182にインタフェースの処理だけを実行させてもよい。このことは第2の実施形態においても同様である。
(第2の実施形態)
本実施形態では、各通信層で実行される処理として、プロトコル内に含まれる機能単位で選択を可能にしたものである。
本実施形態の通信装置100の構成を説明する。本実施形態では、第1の実施形態と異なる点を詳しく説明し、第1の実施形態と同様な構成についての詳細な説明を省略する。
図9は本実施形態におけるプロトコル・スイートを説明するための図である。図9は図2に示したプロトコル・スイートをベースに、各プロトコルに含まれる機能を詳細に模式的に表したものである。
図9に示すように、動画アプリケーションP410は機能F411〜F415を有する。WebアプリケーションP420は機能F431〜F423を有する。TCP P310は機能F311〜F314を有する。UDP P320は機能F321〜F323を有する。IP P210は機能F211〜F215を有する。無線LANプロトコルP110は機能F111〜F114を有する。WiMAXプロトコルP120は機能F121〜F123を有する。
次に、本実施形態における制御部180がプロトコルに含まれる機能を、どのように管理し、実行するかを説明する。図10は制御部によるプロトコル内の機能の実行の手順を示すフローチャートである。
プロトコル内の機能F121〜F423を、例えば、図10に示すような処理フローの集まりで表すことができる。つまり、プロトコルは、図10に示す処理フローにおけるステップを1以上実行することによって構成されていると考えることができる。本実施形態では、プロトコル内の各機能を、図10に示すように、イベント受信処理A001、イベント処理A002およびイベント送信処理A003の要素からなるイベントモデルに分類することで、機能毎に管理しやすくしている。
図10では、イベント受信処理A001、イベント処理A002およびイベント送信処理A003を順に行う場合を示している。制御部180があるプロトコル内でイベント受信処理に続いてイベント処理を実行するが、機能によっては、その後、イベント送信処理を行わない場合があってもよい。また、制御部180がイベント受信処理を行うが、イベント処理を実行せずに、イベント送信処理を行ってもよい。
次に、記憶部190に格納されている処理テーブルの構成を説明する。
記憶部190には、制御部180が実行するプロトコルの処理手順を決めるための処理テーブルが格納されている。図11は通信層の上り方向の処理手順を決定するための上り処理テーブルの一例を示す。
処理テーブルには複数種の処理手順が予め登録されており、各処理手順は管理番号で管理される。図11に示すように、処理テーブルは、管理番号に対応して、各通信層で使用される機能が記述されている。図11に示す例では、管理番号が0からn(nは1以上の整数)までの(n+1)種の処理手順が登録されている。
図11の上り処理テーブルを参照すると、例えば、管理番号が0の場合の処理手順では、通信層#L001で無線LANプロトコルP110内の機能F111〜F113を使用するチェーンが規定されている。そして、通信層#L002ではIP P210内の機能F211〜F215を使用するチェーン、通信層#L003ではTCP P310内の機能F311〜F314を使用するチェーン、通信層#L004では動画アプリケーションP410内の機能F411〜F414を使用するチェーンが規定されている。
このようにして、本実施形態では、通信層間の接続情報および各通信層の処理動作だけでなく、各通信層のプロトコル内でどの機能を順に使用するかをチェーンとして管理している。
なお、本実施形態では、上り処理テーブルの構成を説明したが、下り処理テーブルも図11に示したテーブルと同様であり、その詳細な説明を省略する。
また、第1の実施形態と同様に、処理テーブルを上りと下りで別々に準備する場合で説明したが、上りと下りのそれぞれの場合に応じて使用する機能を特定できれば1つのテーブルであってもよい。また、処理手順を特定するための識別子は管理番号に限らず、通信相手のアドレスなど、制御部180が処理手順を特定できれば他の識別子でもよい。
次に、本実施形態の通信装置100の動作を説明する。
通信装置100が外部の装置からデータを受信したものとし、制御部180は、図11に示した処理テーブルを参照する。ここでは、管理番号が1の場合で説明する。
管理番号が1の場合、図11に示すように、機能F113、F114、F415を使用する上りチェーンであることがわかる。ここで、通信層間のインタフェースは図8に示したものと同様とする。
機能F114には、管理番号が1のチェーンを使用することが予め設定されている。または、機能F114は処理テーブルを検索することでチェーンを特定してもよい。検索してチェーンを特定する場合では、機能F114は、動作を実行するときに処理テーブルを参照して、通信層#L001に自身の番号であるF114が存在するチェーンを検索する。検索の結果、機能F114は、図11に示す処理テーブルから管理番号が1のチェーンを使用することを認識できる。
通信装置100が外部から無線LANプロトコルP110を介してデータを受信すると、無線LANプロトコルP110は機能F114に処理を実行させる。機能F114は、処理テーブルで管理番号「1」のチェーンを参照し、機能F113に処理を実行させる。機能F113は機能F114からデータを受信すると、処理を実行した後、上位層であるインターネット層L002宛にインタフェースL012を介して、管理番号を含むメッセージとともにデータを送信する。
インタフェースL012は、機能F113からメッセージとともにデータを受信すると、上り処理テーブルを参照し、メッセージに含まれる管理番号に基づいてチェーンを特定し、特定したチェーンにしたがって処理を行う。
図11に示した上り処理テーブルでは、管理番号が1の場合の通信層#002の欄が「NULL」なので、インターネット層L002では何も処理しない。インタフェースL012は、メッセージを含むデータをトランスポート層L003宛にインタフェースL023を介して送信する。
インタフェースL023は、インタフェースL012からメッセージを含むデータを受信すると、上り処理テーブルを参照し、メッセージに含まれる管理番号に基づいてチェーンを特定し、特定したチェーンにしたがって処理を行う。
図11に示した上り処理テーブルでは、管理番号が1の場合の通信層#003の欄が、通信層#002の欄と同様に、「NULL」なので、トランスポート層L003でも、何も処理しない。インタフェースL023は、メッセージを含むデータをアプリケーション層L004宛にインタフェースL034を介して送信する。
インタフェースL034は、インタフェースL023からメッセージを含むデータを受信すると、上り処理テーブルを参照し、メッセージに含まれる管理番号に基づいてチェーンを特定し、特定したチェーンにしたがって処理を行う。
図11に示した上り処理テーブルでは、管理番号が1の場合の通信層#004の欄が「機能F415」なので、インタフェースL034は、データを動画アプリケーションP410に送信する。動画アプリケーションP410は、インタフェースL034からデータを受け取ると、機能F415に処理を実行させる。このような処理手順で、インタフェースを共通にしたまま通信層を跨いで情報をやりとりし、通信層を跨いで処理を行うことが可能となる。
図11に示す処理テーブルにおいて、管理番号がnのチェーンと管理番号が0のチェーンを比較してみる。管理番号がnの場合では、管理番号が0の場合の通信層#L001〜通信層#L003のチェーンから機能F112、機能F212、機能F213、機能F214、機能F312および機能F313を「NULL」によってスキップさせていることがわかる。
このようにして、本実施形態では、プロトコル内の一部の機能をスキップさせる処理を簡単に実現することができる。
また、ここでは省略したが、図11に示した処理テーブルにおける機能設定の欄に「selectable」設定することで、各機能において特定した次の通信層のプロトコルに向けて処理を継続することも可能である。
以下に、プロトコルに含まれる機能の例と、プロトコルの機能の一部の処理をスキップする場合の具体例を説明する。
本実施例は、TCPにおけるセッション設定処理の場合である。
アプリケーションの機能がOS(Operating System)へ通信開始のためのシステムコールを行うと、TCPのセッション設定機能が選択される。セッション設定機能は、通信相手にSYNパケットを送信し、Ackパケットを受け取る処理、または、SYNパケットを相手から受け取り、Ackパケットを送信する処理を行う。これが、アプリケーションがTCPセッションを開始するときの流れとなり、処理テーブル内のチェーンで実現される。
ここで、もし通信装置が1対1のセッションしか必要としない場合、すなわち通信装置にアプリケーションが1つしかなくセッションが1本あればよい場合、電源投入直後から決まったポート番号を使用して通信すればよいため、TCPのSYN処理は不要となる。これを実現するには、セッション設定機能は不要とするために、処理テーブル内のチェーンを利用してスキップするだけでよい。
本実施例は、TCPにおけるウィンドウ制御の場合である。
TCPにおいて、受信側から伝送されるAckヘッダのWINDOWフィールドに、受信側が受信可能なオクテット数が入る。送信側は、そのオクテット数を超えないデータサイズを次回送信する。一般的にはTCP通信開始時点では通信装置間の伝送品質が不明であるため、当初のオクテット数は小さい値として受信側はAckを送信側に返送する。その後に送信側から送られてきたパケットのチェックサム検査により、伝送品質がよいと判断された場合にのみ、受信側は、WINDOWフィールドの値を増加させたAckを返送し、結果的に送信側がより大きなオクテット数を含むデータを送ることとなる。
ここで、もし受信側が当初から伝送品質が良いとわかっており、かつ、受信側のバッファサイズも十分に準備されていれば、受信側はTCPのパケットを受信するたびにWINDOWフィールドの値を増減する必要はなく、受信パケットのチェックサム処理を処理テーブル内のチェーンを利用してスキップし、予め決められた大きな固定値をWINDOWフィールドに設定すればよい。
万が一、通信装置間の伝送路に障害が発生した場合は、例えば、受信側が、リンク層のエラー検出機能から得られる値を参照、蓄積および統計処理などを行い、その値が予め決められた閾値を超えたときのみ、WINDOWフィールドの値を適切なオクテット数減らす処理を行えばよい。こうすることにより、通信開始時点から、低処理量で高速なTCP通信が可能となる。
その反対に、受信側が当初から伝送品質が悪いとわかっている場合、WINDOW制御を行っても得る効果は少ない。そのため、受信側は、初めから少ない固定値のオクテット数をWINDOWフィールドに設定し、処理テーブル内のチェーンを利用して、WINDOW制御をスキップすれば、TCP通信を低処理で行うことが可能となる。つまり、WINDOWフィールドを微小に増減しかできないWINDOW制御を省略することで、通信装置間で数多く行われるTCP処理を共通化することが可能となる。
次に、図12を参照して、エラーチェックのクロスレイヤ処理について説明する。
図12は図9に示したプロトコル・スイートのうち、エラーチェック処理に着目して機能を記述したものである。
リンク層L001における無線LANプロトコルP110は、パケットのエラーチェックを行うWLANエラーチェック機能F112を有する。具体的には、WLANエラーチェック機能F112は、通信装置100が無線LANパケットを受信した際、そのパケット内のCRCフィールドの値がパケット全体から計算したCRC(巡回冗長検査)と等しいか否かを確認し、それらの値が一致しなければ、基本的にそのパケットは破棄するという機能である。
また、インターネット層L002のIP P210は、パケットのエラーチェックを行うIPエラーチェック機能F214を有する。具体的には、IPエラーチェック機能F214は、パケット内のIPヘッダ部分に対して1の補数和の1の補数を計算し、チェックサムの値と比較することでエラーをチェックする。
IPと同様にTCPにも、パケットのエラーチェックを行うTCPエラーチェック機能F312がある。具体的には、TCPエラーチェック機能F312は、パケット内のTCPヘッダとペイロード部分に対して1の補数和の1の補数を計算する処理である。
ここで、IPエラーチェック機能F214とTCPエラーチェック機能F312は、その対象こそ異なるものの、処理内容は同じである。そこで、例えば、処理テーブル内で規定されたTCPエラーチェック処理F312の代わりに、IPエラーチェック機能F214を利用してもよい。すなわち処理テーブル内でTCPエラーチェック機能F312の代わりにIPエラーチェック機能F214を実行するように規定しておけば、TCPエラーチェック機能F312をIPエラーチェック機能F214に置き換えることができる。このようにすることで、各プロトコル内で共通的な処理をまとめることができる。
本実施形態によれば、第1の実施形態で説明した効果の他に、以下のような効果を得ることができる。
本実施形態では、イベントとチェーンによって、プロトコルの機能の使用有無を自在に決定することができる。例えば、通信層をスキップするようなクロスレイヤアクセスまたは通信層の一部機能をスキップする処理がチェーン上「NULL」と表現するだけで可能となる。
また、イベントとチェーンによって、プロトコル内の機能の使用有無、処理順序などを自在に変更することができる。例えば、プロトコルのフルセットを実行することや、プロトコルの一部のみを実行、さらには異なる機能を組み合わせて新たなプロトコルの機能を実行することが容易である。
さらに、チェーンによって、プロトコル内の機能のうち、共通的な処理をまとめて各プロトコルで指定して使うことができる。例えば、暗号化処理やデータのエラーチェック処理などの計算処理を個々のプロトコルで準備しておくことが不要となる。
上述の実施形態および実施例では、本発明の通信装置をわかり易く説明するために、構成および動作を具体的に説明したが、本発明の通信装置は少なくとも次のような特徴を有している。
図13は本発明の一実施形態の通信装置の構成例を示すブロック図である。
図13に示すように、本発明の一実施形態の通信装置101は制御部180を有する。制御部180は、階層化された複数の通信層を介して外部の通信装置とデータを送受信する際、各通信層間でやりとりする情報をイベントと規定し、各通信層のプロトコルの処理動作を、イベント受信、イベント処理およびイベント送信という要素からなるイベントモデルで管理し、イベントモデルの単位で処理を実行する。制御部180は、通信層間でのデータのやりとりおよび各通信層でのプロトコル処理をイベントモデルの単位で実行することで、ある通信層においてイベント受信の後にイベント送信が規定されていれば、その通信層でプロトコル処理を行わずに次の通信層にデータを引き渡すクロスレイヤ処理が可能となる。
本発明の通信制御方法を、電気通信の分野に属し、送信される情報および/または受信される情報を処理するために通信層(プロトコル・スタック/スイート)を用いるような通信システムの分野に適用することが可能である。
100、101 通信装置
180 制御部
190 記憶部

Claims (6)

  1. 階層化された複数の通信層におけるプロトコルの処理動作をイベント受信、イベント処理およびイベント送信という要素からなるイベントモデルで管理するための、前記プロトコルに含まれる機能が記述されたテーブルが格納された記憶部と、
    前記階層化された複数の通信層を介して外部の通信装置とデータを送受信する際、各通信層間でやりとりする情報をイベントと規定し、各通信層のプロトコルの処理動作を、前記イベントモデルで管理し、前記テーブルを用いて、各通信層間の接続情報および各通信層の処理動作の写像を通信単位でチェーンとして管理し、前記イベント受信時に前記テーブルを参照して前記チェーンにしたがって、各通信層内のプロトコルに含まれる機能のうち、どの機能を使用するかを決定して実行する制御部を有する通信装置。
  2. 請求項1記載の通信装置において、
    前記制御部は、
    前記イベント受信時に前記テーブルを参照して前記チェーンにしたがって、各通信層内に含まれるプロトコルのうち、どのプロトコルを使用するかを決定する、通信装置。
  3. 請求項1または請求項2に記載の通信装置において、
    前記制御部は、
    前記チェーンにしたがって、各通信層内のプロトコルの機能のうち、処理内容が同じ機能については異なる対象に共通に使用する、通信装置。
  4. 請求項1記載の通信装置において、
    前記制御部は、
    前記イベント受信時に前記テーブルを参照して前記チェーンにしたがって、前記複数の通信層のうち、1以上の通信層の処理動作をスキップさせる、通信装置。
  5. 階層化された複数の通信層におけるプロトコルの処理動作をイベント受信、イベント処理およびイベント送信という要素からなるイベントモデルで管理するための、前記プロトコルに含まれる機能が記述されたテーブルが格納された記憶部を有する通信装置による通信制御方法であって、
    前記階層化された複数の通信層を介して外部の通信装置とデータを送受信する際に、各通信層間でやりとりする情報をイベントと規定し、
    各通信層のプロトコルの処理動作を、前記イベントモデルで管理し、
    前記テーブルを用いて、各通信層間の接続情報および各通信層の処理動作の写像を通信単位でチェーンとして管理し、前記イベント受信時に前記テーブルを参照して前記チェーンにしたがって、各通信層内のプロトコルに含まれる機能のうち、どの機能を使用するかを決定して実行する、通信制御方法。
  6. 階層化された複数の通信層におけるプロトコルの処理動作をイベント受信、イベント処理およびイベント送信という要素からなるイベントモデルで管理するための、前記プロトコルに含まれる機能が記述されたテーブルが格納された記憶部を有するコンピュータに、
    前記階層化された複数の通信層を介して外部の通信装置とデータを送受信する際に、各通信層間でやりとりする情報をイベントと規定する手順と、
    各通信層のプロトコルの処理動作を、前記イベントモデルで管理する手順と、
    前記テーブルを用いて、各通信層間の接続情報および各通信層の処理動作の写像を通信単位でチェーンとして管理し、前記イベント受信時に前記テーブルを参照して前記チェーンにしたがって、各通信層内のプロトコルに含まれる機能のうち、どの機能を使用するかを決定して実行する手順を前記コンピュータに実行させるためのプログラム。
JP2012216431A 2012-09-28 2012-09-28 通信装置、通信制御方法およびプログラム Active JP6128580B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012216431A JP6128580B2 (ja) 2012-09-28 2012-09-28 通信装置、通信制御方法およびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012216431A JP6128580B2 (ja) 2012-09-28 2012-09-28 通信装置、通信制御方法およびプログラム

Publications (2)

Publication Number Publication Date
JP2014072647A JP2014072647A (ja) 2014-04-21
JP6128580B2 true JP6128580B2 (ja) 2017-05-17

Family

ID=50747494

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012216431A Active JP6128580B2 (ja) 2012-09-28 2012-09-28 通信装置、通信制御方法およびプログラム

Country Status (1)

Country Link
JP (1) JP6128580B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102176829B1 (ko) 2018-12-12 2020-11-11 삼원액트 주식회사 태양 전지의 전극 모듈

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6320938A (ja) * 1986-07-15 1988-01-28 Hitachi Ltd デ−タ通信制御方式
JPH05191474A (ja) * 1992-01-10 1993-07-30 Mitsubishi Electric Corp 通信プロトコル処理装置
US5509010A (en) * 1993-06-25 1996-04-16 At&T Corp. Communications signaling protocols
GB0011954D0 (en) * 2000-05-17 2000-07-05 Univ Surrey Protocol stacks

Also Published As

Publication number Publication date
JP2014072647A (ja) 2014-04-21

Similar Documents

Publication Publication Date Title
Li et al. ECCN: Orchestration of edge-centric computing and content-centric networking in the 5G radio access network
CN116405461B (zh) 一种数据处理方法、网元设备以及可读存储介质
KR101987784B1 (ko) 소프트웨어 정의 네트워크를 기반으로 내용 배포 네트워크를 구현하는 방법 및 시스템
US10999215B2 (en) Software-defined network-based method and system for implementing content distribution network
US9602389B1 (en) Method and system for defining logical channels and channel policies in an application acceleration environment
CN104255046B (zh) 可定制的移动宽带网络系统和定制移动宽带网络的方法
US12192055B2 (en) Software defined networking portal for custom-defined network routing
AU2012303738A1 (en) Implementing a 3G packet core in a cloud computer with openflow data and control planes
CN109361600B (zh) 一种获取路径标识的方法和设备
CN109362085A (zh) 通过openflow数据平面在云计算机中实现epc
CN116668511B (zh) 一种数据处理方法、网元设备以及可读存储介质
CN103746911A (zh) 一种sdn网络结构及其通信方法
JP5993817B2 (ja) キャリア網における経路制御システム及び方法
CN113383322A (zh) 信息处理装置和信息处理方法
JP6128580B2 (ja) 通信装置、通信制御方法およびプログラム
CN115708384A (zh) 分布式业务转发方法、装置、系统、存储介质及电子设备
EP1551142A1 (en) A gateway for coupling of passive and active networks
CN113973086B (zh) 一种数据传输方法、装置及存储介质
HK40083058A (en) Data processing method, apparatus, network element device and readable storage medium
KR101371568B1 (ko) 이기종 네트워크 기반 데이터 동시 전송 서비스 방법
CN119854212A (zh) 数据处理系统、方法、设备及存储介质
HK1239972B (en) Software defined networking portal
Park et al. A cross-layer approach for multiuser multiplexing on IP mobility
MX2014000641A (es) Sistema para el uso simultaneo de multiples interfaces de red heterogeneas para mejorar el rendimiento de red en dispositivos con varias interfaces.

Legal Events

Date Code Title Description
RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20140520

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150812

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160624

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160705

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160902

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170214

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170223

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170314

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170406

R150 Certificate of patent or registration of utility model

Ref document number: 6128580

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250