(57)【要約】【課題】独立して作成された複数のソフトウェアから共用されるＭＡＣレイヤを安全に動作させることができるようにする。【解決手段】本発明の通信装置は、１又は複数の上位部から無線通信に係る動作処理の依頼を受けて、依頼された動作処理を行う依頼動作処理手段と、依頼動作処理手段への依頼元である上位部で指定される依頼動作情報と、依頼元の上位部を識別する上位部識別情報とを対応付けた対応情報を記憶する対応情報記憶手段とを備えることを特徴とする通信装置である。【選択図】      図１
2014022880.tif 000002
【特許請求の範囲】
【請求項１】
１又は複数の上位部から無線通信に係る動作処理の依頼を受けて、依頼された動作処理を行う依頼動作処理手段と、
上記依頼動作処理手段への依頼元である上記上位部で指定される依頼動作情報と、依頼元の上記上位部を識別する上位部識別情報とを対応付けた対応情報を記憶する対応情報記憶手段と
を備えることを特徴とする通信装置。
【請求項２】
上記対応情報記憶手段は、上記上位部が動作依頼時に発行する上位部識別情報と、上記依頼動作情報とを対応付けて記憶するものであることを特徴とする請求項１に記載の通信装置。
【請求項３】
上記対応情報記憶手段は、依頼元である上記上位部が動作依頼時に指定する上位部識別情報と、上記依頼動作情報とを対応付けて記憶するものであることを特徴とする請求項１に記載の通信装置。
【請求項４】
上記１又は複数の上位部に対して予め上位部識別情報が割り当てられており、
上記対応情報記憶手段は、依頼元である上記上位部に割り当てられている上位部識別情報と、上記依頼動作情報とを対応付けて記憶するものであることを特徴とする請求項１に記載の通信装置。
【請求項５】
上記１又は複数の上位部から依頼された動作処理を取り消す動作取消依頼を受けると、上記対応情報記憶手段を参照して、動作取消依頼の依頼元の上記上位部で指定される依頼動作情報と上記上位部の上位部識別情報とに基づいて、上記動作取消依頼の依頼元を確認する確認手段を備えることを特徴とする請求項１〜４のいずれかに記載の通信装置。
【請求項６】
上記確認手段は、上記対応情報記憶手段を参照して、上記動作取消依頼を発行した上記上位部識別情報が、上記動作処理を依頼した上記上位部識別情報と一致しない場合、上記動作取消依頼を無効にすることを特徴とする請求項５に記載の通信装置。
【請求項７】
上記依頼動作処理手段による処理結果を応答する依頼動作応答処理手段を更に備え、
上記依頼動作応答処理手段が、上記対応情報記憶手段を参照して、動作依頼時の上記依頼動作情報に対応する上記上位部識別情報を取得し、取得した上記上位部識別情報と共に上記処理結果を応答することを特徴とする請求項１〜６のいずれかに記載の通信装置。
【請求項８】
上記依頼動作処理手段、上記確認手段、又は、上記依頼動作応答処理手段による処理が完了すると、上記対応情報記憶手段に記憶される対応する上記対応情報を削除する削除手段を備えることを特徴とする請求項５〜７のいずれか記載の通信装置。
【請求項９】
上記１又は複数の上位部から依頼される動作処理が、フレーム送信処理であることを特徴とする請求項１〜８のいずれかに記載の通信装置。
【請求項１０】
上記１又は複数の上位部から依頼される動作処理が、間接送信処理であることを特徴とする請求項１〜９のいずれかに記載の通信装置。
【請求項１１】
上記上位部識別情報が、上記１又は複数の上位部において管理される処理実行単位識別情報であることを特徴とする請求項２〜１０のいずれかに記載の通信装置。
【請求項１２】
コンピュータを、
１又は複数の上位部から無線通信に係る動作処理の依頼を受けて、依頼された動作処理を行う依頼動作処理手段
上記依頼動作処理手段への依頼元である上記上位部で指定される依頼動作情報と、依頼元の上記上位部を識別する上位部識別情報とを対応付けた対応情報を記憶部に記憶する対応情報記憶手段
として機能させることを特徴とする通信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置及び通信プログラムに関し、例えば、それぞれ独立に作成された複数の上位レイヤの機能が、媒体アクセス制御副層（ＭＡＣ（Media  Access）レイヤ）の機能を共用する通信装置及び通信プログラムに適用し得る。
【背景技術】
【０００２】
近年、いわゆるスマート社会を実現する技術としてIEEE802.15.4に規定される標準化技術が注目されている。
【０００３】
IEEE802.15.4は一般的にMACレイヤの機能であると分類される、様々なデータ伝送処理や管理機能を持つ。IEEE802.15.4は上位レイヤ（例えばアプリケーション等）からの依頼によってＭＡＣレイヤとしての動作を実施する。
【０００４】
MACレイヤの機能として、ハンドルを用いた動作処理単位の管理がある。これはたとえば，上位レイヤがＭＡＣレイヤに対して動作処理を依頼する場合、上位レイヤは、依頼する動作処理を示す１バイトの「ハンドル」を、要求毎に指定してＭＡＣレイヤに動作処理を要求する。ＭＡＣレイヤは、上位レイヤから指定されたハンドルを管理し、ハンドルを用いて動作処理を区別している。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】IEEE802.15.4-2011
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、IEEE802.15.4の標準化技術は、例えば、ＳＵＮ（Smart  Utility  Network）やＨＥＭＳ（Home  Energy  Management  System）等に利用される関係から、それぞれ異なる複数の上位レイヤで共用されることが予測される。
【０００７】
従来の一般的な構成は、ＭＡＣレイヤに対して上位レイヤが１個の場合には問題ないが、複数の上位レイヤがＭＡＣレイヤを共用する場合、上位レイヤ間でハンドルが重複することが生じ得、その場合、ＭＡＣレイヤが正しく安全に動作することができないおそれが生じ得る。
【０００８】
例えば、Ｘネットワークスタック及びＹネットワークスタックがＭＡＣレイヤを共用する場合、Ｘネットワークスタックが「ハンドルα」とする間接送信要求をした後に、Ｙネットワークスタックが、同じく「ハンドルα」に対してフレーム送信キャンセル機能が実施されてしまうことが生じ得る。
【０００９】
また、ＭＡＣレイヤは、ネットワークスタックからフレーム送信要求があると、そのフレーム送信要求に対する依頼動作応答を実施する。この場合にも、ＭＡＣレイヤはハンドルを利用して依頼動作応答を行うが、ＭＡＣレイヤはハンドルのみを管理しているので、ハンドルが競合したときには、複数のネットワークスタックが、果たして自己の依頼動作の応答であるか否かの判断をすることができない。
【００１０】
これらの課題に対して、それぞれ上位レイヤが利用するハンドルの番号の範囲を予め決めておくという方法も考えられる。しかし、上位レイヤは相互に独自に作成されることが多い。そのため、それぞれの上位レイヤとＭＡＣレイヤとの間で連携を取る仕組みを設けることは現実的でない。
【００１１】
また、１個のネットワークスタックは複数のアプリケーション等の上位レイヤにより共用される。現在最も利用されているネットワークスタックであるＩＰスタックはこういった課題を「ソケット」という方法で解決している。しかし、計算機資源が限られた組込みで利用されることが多いIEEE802.15.4でソケット相当のものを用意するのはオーバヘッドが大きく現実的ではない。
【００１２】
そのため、独立して作成された複数のソフトウェアから共用されるＭＡＣレイヤを安全に動作させることができる通信装置及び通信プログラムが求められている。
【課題を解決するための手段】
【００１３】
かかる課題を解決するために、第１の本発明の通信装置は、（１）１又は複数の上位部から無線通信に係る動作処理の依頼を受けて、依頼された動作処理を行う依頼動作処理手段と、（２）依頼動作処理手段への依頼元である上位部で指定される依頼動作情報と、依頼元の上位部を識別する上位部識別情報とを対応付けた対応情報を記憶する対応情報記憶手段とを備えることを特徴とする通信装置である。
【００１４】
第２の本発明の通信プログラムは、コンピュータを、（１）１又は複数の上位部から無線通信に係る動作処理の依頼を受けて、依頼された動作処理を行う依頼動作処理手段（２）依頼動作処理手段への依頼元である上位部で指定される依頼動作情報と、依頼元の上位部を識別する上位部識別情報とを対応付けた対応情報を記憶部に記憶する対応情報記憶手段として機能させることを特徴とする通信プログラムである。
【発明の効果】
【００１５】
本発明によれば、独立に作成された複数のソフトウェアから共用されるＭＡＣレイヤを、安全に動作させるためのものである。
【図面の簡単な説明】
【００１６】
【図１】第１の実施形態の通信装置の内部構成を示す内部構成図である。
【図２】第１の実施形態に係る、上位部から間接送信要求が依頼される場合の通信装置における処理の動作を示すフローチャートである。
【図３】第１の実施形態に係る、上位部から間接送信要求が依頼される場合の通信装置の処理を説明する説明図である。
【図４】第１の実施形態に係る、上位部から間接送信要求が依頼される場合の通信装置における処理の動作を示すフローチャートである。
【図５】第１の実施形態において、上位部がフレーム送信キャンセル要求を依頼したときの動作を説明する説明図である（その１）。
【図６】第１の実施形態において、上位部がフレーム送信キャンセル要求を依頼したときの動作を説明する説明図である（その２）。
【図７】第２の実施形態の通信装置の内部構成を示す内部構成図である。
【図８】第２の実施形態の通信装置における動作依頼処理及び依頼動作応答処理の動作を示すフローチャートである。
【発明を実施するための形態】
【００１７】
（Ａ）第１の実施形態
以下では、本発明の通信装置及び通信プログラムの第１の実施形態を、図面を参照しながら詳細に説明する。
【００１８】
第１の実施形態では、IEEE802.15.4の標準化技術を採用して、フレーム伝送処理を行う通信装置に本発明を適用する場合を例示する。
【００１９】
第１の実施形態は、上位レイヤから依頼された間接送信を行う場合に、その間接送信のフレーム送信を取り消すフレームキャンセル機能を実施する場合を例示する。
【００２０】
例えば、イーサネット（登録商標）等において、ＭＡＣレイヤのフレーム送信要求後に上位レイヤからフレーム送信をキャンセルすることは難しい。なぜなら、上位レイヤがＭＡＣレイヤに対してフレーム送信要求を行った場合、その直後にフレーム送信が実施されてしまうからである。よって、通常、ＭＡＣレイヤがフレーム送信キャンセルを行うことはない。
【００２１】
しかし、IEEE802.15.4で規定されているＭＡＣレイヤは、フレーム送信キャンセル機能がある（MCPS-PURGE.request）。これは、IEEE802.15.4の標準化技術が省電力のための「間接送信」という特殊なフレーム送信機能を持っているからである。
【００２２】
IEEE802.15.4準拠のＭＡＣレイヤは、フレーム間接送信要求（＝間接送信オプションを有効にしてMCPS-DATA.request）を出された場合、そのフレームを送
信先ノードからの間接送信フレーム送信要求（＝Datarequestコマンドフレームの受信）があるまで、ＭＡＣレイヤ内部で保持する。
【００２３】
よって、間接送信を実施する場合、従来のＭＡＣレイヤと異なり、フレーム送信要求直後にフレーム送信が実施されるとは限らない。「間接送信」の場合、フレーム送信が要求後すぐに実施されないのでフレーム送信キャンセル機能に意味がある。
【００２４】
（Ａ−１）第１の実施形態の構成
図１は、第１の実施形態の通信装置の内部構成を示す内部構成図である。図１は、第１の実施形態の通信装置１００の主な内部構成を示している。
【００２５】
図１において、第１の実施形態の通信装置１００は、複数の上位部１０３及び１０４と、ＭＡＣレイヤ及びＰＨＹ（物理）レイヤ１０２として、間接送信制御部１１１、フレーム送信キャンセル処理部１１２、依頼元確認部１１３、記憶部１１４とを有する。
【００２６】
上位部１０３及び１０４は、ＭＡＣレイヤ及びＰＨＹレイヤ１０２の上位レイヤであるネットワークプロトコルスタックに相当するものである。上位部１０３及び１０４は、例えばアプリケーション等の上位レイヤから取得したフレーム間接送信要求やフレーム送信キャンセル要求をＭＡＣレイヤ及びＰＨＹレイヤ１０２に与えるものである。上位部１０３及び１０４はそれぞれ、複数のアプリケーション等の上位レイヤから共用されるものであってもよい。なお、図１では、上位部の数が２個の場合を例示するが、上位部の数は特に限定されるものではなく、３個以上であってもよい。
【００２７】
間接送信制御部１１１は、依頼元確認部１１３と接続しており、上位部１０３又は上位部１０４からフレーム間接送信要求を受けると、フレーム間接送信を行うものである。
【００２８】
IEEE802.15.4に規定されるデータ送信は、上位レイヤからのデータ送信依頼時（MCPS-DATA.request発行時）に、複数の送信オプションを設定することができる。例えば、送信オプションには、ＡＣＫ要求有り送信、間接送信、セキュリティ有り送信等がある。上位部１０３及び１０４が間接送信を要求する場合、上位部１０３及び１０４は、設定パラメータ（Indirect  Transmissionパラメータ）を設定し、フレーム送信要求（MCPS-DATA.request）をＭＡＣレイヤ及びＰＨＹレイヤ１０２に与える。
【００２９】
間接送信制御部１１１は、フレーム間接送信要求を受けると、間接送信に係るフレームを一時的に保持し、図示しない送信先から間接送信フレーム送信要求（Datarequestコマンドフレーム）を受信すると、保持しているフレームを送信先ノードに送信する。
【００３０】
なお、間接送信制御部１１１がフレームを保持するデータ保持時間は、所定の設定時間を設定するようにしてもよく、又設定変更できるようにしてもよい。また、間接送信制御部１１１は、所定数のフレームを保持するようにしてもよい。
【００３１】
フレーム送信キャンセル処理部１１２は、依頼元確認部１１３及び間接送信制御部１１１と接続しており、上位部１０３又は上位部１０４からフレーム送信キャンセル要求を受けると、対応するフレームの間接送信をキャンセルするものである。上位部１０３及び１０４がフレーム送信のキャンセルを要求する場合、上位部１０３及び１０４は、間接送信を依頼したときの間接送信のハンドル（１バイトの番号）を指定してフレーム送信キャンセル要求を行う。
【００３２】
従って、フレーム送信キャンセル処理部１１２は、指定されたハンドルについての間接送信を取り消すことを間接送信制御部１１１に指示する。
【００３３】
依頼元確認部１１３は、上位部１０３及び１０４と、間接送信制御部１１１と、フレーム送信キャンセル処理部１１２と、記憶部１１４と接続するものである。
【００３４】
図１に示すように、依頼元確認部１１３は、対応情報取得部１１、間接送信要求指示部１２、確認部１３、フレーム送信キャンセル指示部１４、対応情報削除部１５を有する。
【００３５】
対応情報記憶部１１は、上位部１０３及び上位部１０４から間接送信要求を受けると、間接送信要求に含まれるハンドル及び上位部識別情報を取得し、取得されたハンドルと上位部識別情報とを対応付けた対応情報を記憶部１１４に記憶するものである。
【００３６】
間接要求指示部１２は、対応情報記憶部１１によりハンドル及び上位部識別情報の対応情報が記憶部１１４に記憶されると、上位部１０３及び１０４からの間接送信要求を間接送信制御部１１１に与えるものである。
【００３７】
確認部１３は、上位部１０３及び上位部１０４からフレーム送信キャンセル要求を受けると、このフレーム送信キャンセル要求に含まれるハンドル及び上位部識別情報と、記憶部１１４に記憶されるハンドル及び上位部識別情報とを比較して、一致するものがあるか否かを確認するものである。
【００３８】
フレーム送信キャンセル指示部１４は、確認部１３によりハンドル及び上位部識別情報が一致すると判断された場合、フレーム送信キャンセル要求をフレーム送信キャンセル処理部１１２に与える。また、フレーム送信キャンセル指示部１４は、確認部１３によりハンドル及び上位部識別情報が一致しないと判断された場合、依頼元確認部１１３は、フレーム送信キャンセル要求を無効にする。
【００３９】
対応情報削除部１５は、間接送信要求のときに、間接送信制御部１１１により間接送信が実施されると、記憶部１１４に記憶されるハンドル及び上位部識別情報を削除する。また、対応情報削除部１５は、フレーム送信キャンセル要求のときに、フレーム送信キャンセル処理部１１２によりフレーム送信のキャンセルが実施されると、記憶部１１４に記憶されるハンドル及び上位部識別情報を削除する。
【００４０】
ここで、上位部１０３及び１０４が間接送信要求を行う場合には、依頼する間接送信処理と紐付けしたハンドルを上位部１０３及び１０４が指定して行う。また、上位部１０３及び１０４がフレーム送信キャンセルを行う場合には、先に依頼した間接送信のハンドルを上位部１０３及び１０４が指定してフレーム送信キャンセルを要求する。
【００４１】
上位部識別情報とは、依頼動作の依頼元である上位部１０３及び１０４を識別する情報である。上位部識別情報は、依頼元である上位部１０３及び１０４を特定する情報であれば種々の情報を広く適用することができる。
【００４２】
例えば、上位部識別情報は、予め設定されている上位部識別情報や、ＭＡＣレイヤ及びＰＨＹレイヤ１０２に動作依頼を行った上位部１０３及び１０４の上位部識別情報や、動作依頼の際に上位部１０３及び１０４が指定した上位部識別情報等を適用することができる。
【００４３】
上記の上位部識別情報は、上位部１０３及び１０４に対して予め割り当てられている固有のＩＤや、上位部１０３及び１０４のタスク又はスレッドのＩＤ（以下、処理実行単位識別情報ともいう）等を用いることができる。
【００４４】
なお、上位部１０３及び１０４に相当するネットワークプロトコルスタックやアプリケーションは、マルチタスクＯＳやマルチスレッドＯＳを利用して実装される。従って、各レイヤは、１以上のタスク又はスレッドを利用して実装される。通常、マルチタスクＯＳ等は、個々のタスク等を区別又は管理する情報としてタスクＩＤ又はスレッドＩＤを用意している。依頼元確認部１１３は、上位部１０３及び１０４からの間接送信要求又はフレーム送信キャンセル要求を受けると、その間接送信要求又はフレーム送信キャンセル要求を依頼したタスクＩＤ又はスレッドＩＤとハンドルとを対応付けて記憶部１１４に記憶するようにしてもよい。
【００４５】
記憶部１１４は、依頼元確認部１１３が取得したハンドル及び上位部識別情報を対応付けて記憶するものである。
【００４６】
（Ａ−２）第１の実施形態の動作
次に、上位部１０３及び１０４から間接送信要求及びフレーム送信キャンセル要求が依頼されるときの通信装置１００における処理の動作を、図面を参照しながら詳細に説明する。
【００４７】
まず、図２及び図３を用いて、上位部１０３及び１０４から間接送信要求が依頼される場合の通信装置１００における処理の動作を説明する。なお、ここでは、説明便宜上、上位部１０３からＭＡＣレイヤ及びＰＨＹレイヤ１０２に対して間接送信要求があった場合を例示する。
【００４８】
図２は、上位部１０３及び１０４から間接送信要求が依頼される場合の通信装置１００における処理の動作を示すフローチャートである。図３は、上位部１０３から間接送信要求が依頼される場合の通信装置１００の処理を説明する説明図である。
【００４９】
図２において、上位部１０３がＭＡＣレイヤ及びＰＨＹレイヤ１０２に対して間接送信要求を依頼する場合、データ送信依頼時（MCPS-DATA.request発行時）に、上位部１０３は、設定パラメータ（Indirect  Transmissionパラメータ）を設定し、フレーム送信要求（MCPS-DATA.request）をＭＡＣレイヤ及びＰＨＹレイヤ１０２に与える。
【００５０】
ＭＡＣレイヤ及びＰＨＹレイヤ１０２では、図３に示すように依頼元確認部１１３が上位部１０３からの間接送信要求を取得する（Ｓ１０１）。
【００５１】
依頼元確認部１１３は、取得した間接送信要求に含まれるハンドルと、依頼元である上位部１０３の上位部識別情報とを取得する（Ｓ１０２）。
【００５２】
ハンドルは、上位部１０３が間接送信として指定したハンドル番号である。また、上位部識別情報は、上述したように様々な識別情報を適用することができる。例えば、上位部識別情報が、上位部１０３及び１０４に対して予め割り当てられた上位部識別情報である場合、依頼元確認部１１３は、間接送信要求の依頼元である上位部１０３の上位部識別情報を認識することで上位部識別情報を取得することができる。また、例えば、上位部識別情報が、上位部１０３により指定されたタスクＩＤ又はスレッドＩＤ（処理実行単位識別情報）とする場合、依頼元確認部１１３は、上位部１０３が指定するタスクＩＤ又はスレッドＩＤを取得する。
【００５３】
次に、依頼元確認部１１３は、取得したハンドル及び上位部識別情報を対応付けて記憶部１１４に記憶する（Ｓ１０３）。そして、依頼元確認部１１３がハンドル及び上位部識別情報を記憶した後、依頼元確認部１１３は、間接送信制御部１１１に対して間接送信要求を与える（Ｓ１０４）。
【００５４】
間接送信制御部１１１は、間接送信要求を受けると間接送信処理を行う（Ｓ１０５）。すなわち、間接送信制御部１１１は、間接送信に係るフレームを一時的に保持し、送信先から間接送信フレーム送信要求（Datarequestコマンドフレーム）を受信すると、保持しているフレームを送信先ノードに送信する。
【００５５】
そして、間接送信制御部１１１が、間接送信処理が完了すると（Ｓ１０６）、間接送信制御部１１１は依頼元確認部１１３に間接送信完了の旨を通知し、依頼元確認部１１３は、記憶部１１４に記憶される当該間接送信処理のハンドルと上位部識別情報とを削除する（Ｓ１０７）。
【００５６】
次に、図４〜図６を用いて、上位部１０３及び１０４からフレーム送信キャンセル要求が依頼される場合の通信装置１００における処理の動作を説明する。
【００５７】
図４は、上位部１０３及び１０４から間接送信要求が依頼される場合の通信装置１００における処理の動作を示すフローチャートである。
【００５８】
図４において、上位部１０３がＭＡＣレイヤ及びＰＨＹレイヤ１０２に対してフレーム送信キャンセル要求を依頼する場合、上位部１０３からフレーム送信キャンセル要求（MCPS-PURGE.request）がＭＡＣレイヤ及びＰＨＹレイヤ１０２に与えられる。
【００５９】
ＭＡＣレイヤ及びＰＨＹレイヤ１０２では、依頼元確認部１１３が上位部１０３からの間接送信要求を取得する（Ｓ２０１）。
【００６０】
依頼元確認部１１３は、取得した間接送信要求に含まれるハンドルと、依頼元である上位部１０３の上位部識別情報とを取得する（Ｓ２０２）。
【００６１】
次に、依頼元確認部１１３は、記憶部１１４を参照して、取得したハンドル及び上位部識別情報と一致するものがあるか否かを確認する（Ｓ２０３）。
【００６２】
取得したハンドル及び上位部識別情報が記憶部１１４にある場合、依頼元確認部１１３は、フレーム送信キャンセル要求を、フレーム送信キャンセル処理部１１２に与える（Ｓ２０４）。そして、フレーム送信キャンセル処理部１１２は、ハンドルに対応する間接送信処理の取り消しを間接送信制御部１１１に指示してフレーム送信キャンセル処理を行う（Ｓ２０５）。
【００６３】
例えば、図３のように上位部１０３からの間接送信要求が依頼されている場合に、図５のように上位部１０３が間接送信依頼時のハンドルでフレーム送信キャンセル要求を依頼したとする。このとき、ハンドル及び上位部識別情報が記憶部１１４に記憶されているため、依頼元確認部１１３は、フレーム送信キャンセル処理部１１２にフレーム送信キャンセル要求を与える。
【００６４】
一方、取得したハンドル及び上位部識別情報が記憶部１１４にある場合、依頼元確認部１１３は、フレーム送信キャンセル要求を無効にする（Ｓ２０８）。
【００６５】
例えば、上記と同様に、図３のように上位部１０３からの間接送信要求が依頼されている場合に、図６のように上位部１０４が、上位部１０３の依頼したハンドルでフレーム送信キャンセル要求を依頼したとする。この場合、ハンドルは同じであっても、上位部識別情報が異なる。つまり、ハンドル及び上位部識別情報が不一致なので、依頼元確認部１１３は、フレーム送信キャンセル要求を無効にする。
【００６６】
このとき、例えば、依頼元確認部１１３は、フレーム送信キャンセルが無効である旨を、依頼元の上位部１０３に通知し、取得したフレーム送信キャンセル要求を廃棄するようにしてもよい。
【００６７】
なお、Ｓ２０５において、フレーム送信キャンセル処理部１１２が、間接送信に係るフレーム送信キャンセル処理を完了すると（Ｓ２０６）、間接送信制御部１１１は依頼元確認部１１３にフレーム送信キャンセル完了の旨を通知し、依頼元確認部１１３は、記憶部１１４に記憶される当該間接送信処理のハンドルと上位部識別情報とを削除する（Ｓ２０７）。
【００６８】
（Ａ−３）第１の実施形態の効果
以上のように、第１の実施形態によれば、例えば、上位部１０３からの間接送信依頼発行時と同じハンドルで上位部１０４がフレーム送信キャンセル要求を発行したとしても、依頼元確認部１１３が上位部１０４からの依頼を無効とするので、ＭＡＣレイヤ及びＰＨＹレイヤ１０２が正しく安全に動作する。
【００６９】
また、第１の実施形態によれば、依頼元確認部１１３が、ハンドル及び上位部識別情報を記憶することで、ＭＡＣレイヤに対する処理の依頼元を確認し、処理の可否を判断する。上位部識別情報は、例えば、ネットワークプロトコルスタックやアプリケーション等の上位レイヤと連携を取るものではない。従って、従来のＭＡＣレイヤを前提として作られた上位レイヤに変更を加える必要なく、ＭＡＣレイヤの正しく安全な動作を実現することができる。
【００７０】
さらに、上位部識別情報として「依頼時に上位部から指定された上位部識別情報」を利用する場合、上位レイヤの都合でキャンセル依頼を発行する上位部を決めることができるので利便性があがる。
【００７１】
（Ｂ）第２の実施形態
次に、本発明の通信装置及び通信プログラムの第２の実施形態を、図面を参照しながら詳細に説明する。
【００７２】
第２の実施形態も、第１の実施形態と同様に、IEEE802.15.4の標準化技術を採用して、フレーム伝送処理を行う通信装置に本発明を適用する場合を例示する。
【００７３】
第２の実施形態は、上位レイヤから依頼された間接送信を行う場合に、その間接送信のフレーム送信を取り消すフレームキャンセル機能を実施する場合を例示する。
【００７４】
（Ｂ−１）第２の実施形態の構成
図７は、第２の実施形態の通信装置の内部構成を示す内部構成図である。図７は、第２の実施形態の通信装置２００の主な内部構成を示している。
【００７５】
図７において、第２の実施形態の通信装置２００は、複数の上位部２０３及び２０４と、ＭＡＣレイヤ及びＰＨＹ（物理）レイヤ２０２として、依頼動作処理部２１１、依頼動作応答部２１２、記憶部２１３とを有する。
【００７６】
上位部２０３及び２０４は、ＭＡＣレイヤ及びＰＨＹレイヤ２０２の上位レイヤであるネットワークプロトコルスタックに相当するものである。上位部２０３及び２０４は、例えばアプリケーション等の上位レイヤが依頼する動作要求をＭＡＣレイヤ２０２に与えるものである。なお、上位部２０３及び２０４はそれぞれ、複数のアプリケーション等の上位レイヤから共用されるものであってもよい。また、図７では、上位部の数が２個の場合を例示するが、上位部の数は特に限定されるものではなく、３個以上であってもよい。
【００７７】
ここで、上位部２０３及び２０４がＭＡＣレイヤ及びＰＨＹレイヤ２０２への依頼は、例えば、（ａ）データフレーム送信依頼（MCPS-DATA.request）、データフレーム間接送信依頼（MCPS-DATA.request  Indirect送信）、データフレーム送信キャンセル依頼（MCPS-PURGE.request）、ＭＡＣ・ＰＨＹレイヤ設定変更依頼（MLME-SET.request  PLME-SET.request）、ＭＡＣ・ＰＨＹレイヤ設定参照依頼（MLME-GET.request  PLME-GET.request）、ＲＳＳＩ値取得依頼（MLME-SCAN.request  EDスキャン）、周囲に対するビーコン要求依頼（MLME-SCAN.request  Activeスキャン）、受信部ＯＦＦ機能（MLME-RX-ENABLE.request）、コマンドフレーム送信依頼（その他MLME-XXX.request）等がある。
【００７８】
依頼動作処理部２１１は、上位部２０３及び２０４から動作依頼要求時（動作依頼発行時）されると、依頼された動作処理を行うものである。図７に示すように、依頼動作処理部２１１は、対応情報記憶部２１、依頼動作実行部２２を有する。
【００７９】
対応情報記憶部２１は、上位部２０３及び２０４からの動作依頼要求時（動作依頼発行時）に、上位部２０３及び２０４が指定したハンドル及び上位部識別情報を対応付けた対応情報を記憶部２１３に記憶するものである。
【００８０】
上位部識別情報とは、依頼動作の依頼元である上位部２０３及び２０４を識別する情報である。上位部識別情報は、依頼元である上位部２０３及び２０４を特定する情報であれば種々の情報を広く適用することができる。
【００８１】
例えば、上位部識別情報は、予め設定されている上位部識別情報や、ＭＡＣレイヤ２０２に動作依頼を行った上位部２０３及び２０４の上位部識別情報や、動作依頼の際に上位部２０３及び２０４が指定した上位部識別情報等を適用することができる。
【００８２】
上記の上位部識別情報は、上位部２０３及び２０４に対して予め割り当てられている固有のＩＤや、上位部２０３及び２０４のタスク又はスレッドのＩＤ（処理実行単位識別情報）等を用いることができる。
【００８３】
上位部２０３及び２０４に相当するネットワークプロトコルスタックやアプリケーションは、マルチタスクＯＳやマルチスレッドＯＳを利用して実装される。従って、各レイヤは、１以上のタスク又はスレッドを利用して実装される。通常、マルチタスクＯＳ等は、個々のタスク等を区別又は管理する情報としてタスクＩＤ又はスレッドＩＤを用意している。この場合、対応情報記憶部２１は、上位部２０３及び２０４からの依頼動作要求時（依頼動作発行時）のタスクＩＤ又はスレッドＩＤとハンドルとを対応付けて記憶部２１３に記憶する。
【００８４】
依頼動作実行部２２は、上位部２０３及び２０４から依頼された動作処理を実行するものである。
【００８５】
依頼動作応答部２１２は、依頼動作処理部２１１が依頼された動作処理を行うと、動作処理の処理結果を上位部２０３及び２０４に応答するものである。図７に示すように、依頼動作応答部２１２は、確認部２３、依頼動作応答部２４、対応情報削除部２５を有する。
【００８６】
確認部２３は、依頼動作応答を発行する際、発行された依頼動作応答に対する上位部識別情報を、記憶部２１３から取得するものである。
【００８７】
依頼動作応答部２４は、確認部２３により取得された上位部識別情報を、依頼動作応答と共に、依頼元の上位部２０３及び２０４に与えるものである。
【００８８】
対応情報削除部２５は、依頼動作応答後に、依頼動作応答に係る記憶部２１３に記憶されるハンドル及び上位部識別情報を削除する。
【００８９】
ここで、上位部２０３及び２０４がＭＡＣレイヤ及びＰＨＹ２０２に動作を依頼する場合、依頼する動作処理と紐付けしたハンドルを、上位部２０３及び２０４が指定して行う。
【００９０】
記憶部２１３は、対応情報記憶部２１によるハンドル及び上位部識別情報を対応付けて記憶するものである。
【００９１】
（Ｂ−２）第２の実施形態の動作
次に、上位部２０３及び２０４からＭＡＣレイヤ及びＰＨＹレイヤ２０２に対する動作依頼及び依頼動作応答の通信装置２００における処理の動作を、図面を参照しながら詳細に説明する。
【００９２】
図８は、第２の実施形態の通信装置２００における動作依頼処理及び依頼動作応答処理の動作を示すフローチャートである。
【００９３】
上位部２０３及び２０４は、依頼動作要求時（依頼動作発行時）に、依頼動作のハンドルを指定して行う。
【００９４】
ＭＡＣレイヤ及びＰＨＹレイヤ１０２では、依頼動作処理部２１１が上位部２０３及び２０４からの依頼動作要求を取得する（Ｓ３０１）。
【００９５】
依頼動作処理部２１１は、取得した依頼動作要求に係るハンドルと、依頼元である上位部２０３及び２０４の上位部識別情報とを取得する（Ｓ３０２）。
【００９６】
上位部識別情報は、上述したように様々な識別情報を適用することができる。例えば、上位部識別情報が、上位部２０３及び２０４に対して予め割り当てられた上位部識別情報である場合、依頼動作処理部２１１は、依頼元である上位部２０３及び２０４の上位部識別情報を認識することで上位部識別情報を取得することができる。また、例えば、上位部識別情報が、上位部２０３により指定されたタスクＩＤ又はスレッドＩＤ（処理実行単位識別情報）とする場合、依頼動作処理部２１１は、上位部２０３及び２０４が指定するタスクＩＤ又はスレッドＩＤを取得する。
【００９７】
次に、依頼動作処理部２１１は、取得したハンドル及び上位部識別情報を対応付けて記憶部２１３に記憶する（Ｓ３０３）。そして、依頼動作処理部２１１がハンドル及び上位部識別情報を記憶した後、依頼動作処理部２１１は、依頼された動作処理を行う（Ｓ３０４）。なお、依頼動作処理２１１が実行する動作は、IEEE802.15.4で規定されるＭＡＣレイヤ及びＰＨＹ２０２の既存の管理処理を行う。
【００９８】
依頼動作処理部２１１による依頼動作が実行され（Ｓ３０５）、依頼動作応答発行時に、依頼動作応答部２１２は、発行されたハンドルに対応する上位部識別情報を、記憶部２１３から取得する。そして、依頼動作応答部２１２は、取得された上位部識別情報を依頼動作応答と共に、依頼元の上位部２０３及び２０４に与える（Ｓ３０６）。
【００９９】
そして、依頼動作応答がなされると、依頼動作応答部２１２は、記憶部１１４に記憶される当該動作依頼に係るハンドルと上位部識別情報とを削除する（Ｓ３０７）。
【０１００】
（Ｂ−３）第２の実施形態の効果
以上のように、第２の実施形態によれば、依頼動作応答は上位部識別情報と共になされるので、例えば、上位部２０３及び２０４は、動作依頼応答に付された上位部識別情報に基づいて、どの上位部宛てのものか判断できる。
【０１０１】
また、第２の実施形態によれば、記憶部２１３で記憶される上位部識別情報として「ハンドル毎にあらかじめ設定されている上位部識別情報」「依頼をした上位部の上位部識別情報」を記憶することにより、従来のＭＡＣレイヤを前提として作られた上位レイヤに変更を加える必要なく、どの上位部の依頼動作応答を判断できる。
【０１０２】
さらに、第２の実施形態によれば、上位部識別情報として「依頼時に上位部から指定された上位部識別情報」を利用すると、上位レイヤの都合で依頼応答を確認する上位部を決めることができるので利便性があがる。
【０１０３】
（Ｃ）他の実施形態
上述した第１及び第２の実施形態においても種々の変形実施形態を説明したが、以下の他の変形実施形態についても本発明は適用することができる。
【０１０４】
（Ｃ−１）上述した第１の実施形態では、送信オプションとして間接送信及びフレーム送信キャンセルを行う場合を例示したが、間接送信以外のデータ伝送についても適用することができる。つまり、本発明は、ＡＣＫ要求有り送信、セキュリティ有り送信等を行う場合にも適用することができる。これにより、送信オプションの設定の仕方に応じて、仕組みを作り分ける必要がないので、処理や装置をコンパクトな実装とすることができる。
【０１０５】
（Ｃ−２）本発明は、上述した第１の実施形態と第２の実施形態とを組み合わせた構成としても良い。これにより、ハンドル及び上位部識別情報を対応付けて記憶することができるので、上位部から指定されたハンドルが重複する場合でも、ＭＡＣレイヤは上位部からの動作依頼に対して正しく安全に動作することができる。
【符号の説明】
【０１０６】
１００及び２００…通信装置、
１０２及び２０２…ＭＡＣレイヤ及びＰＨＹレイヤ、
１１１…間接送信制御部、１１２…フレーム送信キャンセル処理部、
１１３…依頼元確認部、１１…対応情報記憶部、１２…間接送信要求指示部、
１３…確認部、１４…フレーム送信キャンセル指示部、１５…対応情報削除部、
１１４…記憶部、
２１１…依頼動作処理部、２１…対応情報記憶部、２２…依頼動作実行部、
２１２…依頼動作応答部、２３…確認部、２４…依頼動作応答部、
２５…対応情報削除部、２１３…記憶部、
１０３、１０４、２０３及び２０４…上位部。
【図１】
2014022880.tif 000003
【図２】
2014022880.tif 000004
【図３】
2014022880.tif 000005
【図４】
2014022880.tif 000006
【図５】
2014022880.tif 000007
【図６】
2014022880.tif 000008
【図７】
2014022880.tif 000009
【図８】
2014022880.tif 000010