赤外線通信プロトコル
－IrDA 教科書（応用編）－

基礎編で学んだIrDA 規格の復習

IrDA 基礎編では、IrDA 規格の基本をなす、IrPHY、IrLAP、IrLMP、TinyTP について詳しく学習した。応用編ではこれらの基本規格が、Windows 98、Windows 2000 などのOS 上でどのように実装されているのか、また、実際の組み込みシステムでの実装について具体的に説明していこう。また、IrDA 基本規格の上位層にあるアプリケーション層であるいくつかのIrDA 規格についても学んでいきたい。はじめにIrDA 基礎編で学んだ事項の整理を行う。

リモコン通信方式とIrDA 通信方式

最近のノートパソコン、PDA に搭載されている赤外線通信や、デジタルカメラ、ビデオプリンタ、そしてイメージスキャナに搭載されている赤外線画像転送などにIrDA 規格が採用されている。最近では、携帯電話やISDN 公衆電話、その他産業機器などの応用にIrDAは採用されている。赤外線通信といえば、テレビ、ビデオ、エアコンでおなじみのリモコンがある。原理的には、電気信号を赤外線の光信号に変換してコードレスで通信するということにおいては、IrDA 規格もリモコンの赤外線通信も同じものと考えらる。しかし、通信手段としてリモコンとIrDA 規格を比較するとかなりの違いがある。

赤外線リモコンの方式赤外線リモコンは通信というよりも、「遠隔スイッチ」の代用として開発された。赤外線リモコンは、簡単なスイッチのオンオフ情報を赤外線信号に変換して家電製品に送信することを前提に作られている。リモコン機能の条件として、5ｍから10ｍ程度の到達距離が必要となる。そのために、リモコンボタンを押した瞬間に、「強力で短い瞬間的な赤外線パルス」を発生させるようになっている。赤外線変調方式は、40KHz 前後のキャリアを使用し、バースト信号の時間幅の変化によるものが主流となっている。キャリアを使用するのは、赤外線経路で発生する赤外線ノイズを電子回路によるバンドパスフィルタを使用して除去するためである。

しかしながら、通信速度は、キャリア周波数の1/10 程度になるため、通信速度は300～1200 ビット/秒程度である。また、リモコンと家電製品が1 対1 に対応して、リモコンを特定の家電製品にリモコンを向けて使用するため、赤外線信号は細いビーム状（赤外線ビームの広がりは５度以下）になっている。また、通信のためのプロトコル的なものは存在せず、リモコン信号が家電製品に正しく到達したかどうかは、操作する人がいるので、その人が確認すればよく、あえて通信の仕組みとして通信の成功、失敗を確認する構造にはなっていない。

そのために、通信の基本原理としては簡単な「単方向通信方式」である。このように、赤外線リモコンの通信方式は、人手に頼った通信方式であり、データ通信のエラーの検出が自動化できないこと、電力消費量が大きいこと、データ通信速度が比較てき遅いことなどのために、大量の連続したデータ転送に向いていない。また、赤外線リモコンという意味では、メーカー同士の互換性の必要性がほとんどないので、データ転送の方式として規格が統一されていない。最近の多目的リモコンなどは、各社のリモコンの通信規格を搭載したものや、実際の赤外線データを学習してリモコン機能を実現しているのはこのためである。

IrDA 通信方式IrDA の通信規格は、ポータブルなPDA、ノートパソコンをはじめとした情報家電製品のデータ通信方式として十分に活用できるように設計された通信方式である。そのために、低消費電力、通信速度の向上、データの信頼性を基本に設計されている。ポータブルな情報家電同士のデータ通信として、コードレスで通信できる範囲は、0ｃｍ～1ｍ程度であり。また、装置を手で持ったままデータ転送をすることを考えているため、多少のぶれをカバーできるように赤外線ビームも３０度程度に広げられている。基本は、長さ1ｍ程度の通信ケーブルの置き換えという発想から規格が作られた。

また、省エネルギーの観点から、赤外線の発光量を極力押さえてなおかつ十分な通信速度を確保できる赤外線変調方式を採用している。たとえば、IrDA 方式を使用して、1.68μのベースバンドパルスを使用し9600 ビット/秒のデータ転送を行っている場合、赤外線LED が発光している時間は1/64 以下となる。赤外線パワーもリモコンよりも小さく押さえられているため、電池駆動みよる連続した通信に適する。通信速度を含めて同じデータをリモコン方式で転送する場合とIrDA方式で転送する場合のデータ単位あたりの消費エネルギーは１/100 以下となる。

IrDA 通信方式は、赤外線の物理的な特性（パルスの形状など）以外に、通信データの互換性を保証するために、通信手順が定められている。簡単に言えば、どのように赤外線パルスとして必要なデータを載せるのか、データの誤りをどのように検査して、必要があれば修正して再送すればいいかをIrDA 規格で厳密に定義している。このような、通信手順の制御機構のことをプロトコルと呼ぶ。IrDA プロトコルスタックの構成IrDA 規格は、赤外線通信の規格であるが、特定の応用を目的としたものではなく、汎用の赤外線通信に環境を構築するために構成されている。

IrDA 規格はは、いくつかのレイヤによって構成されており、物理層（IrSIR）、データリンク層（IrLAP）、リンク管理層（IrLMP）、トランスポート層（TinyTP）、アプリケーション層（IrCOMM,OBEX,….）のように、層分けされている。アプリケーションプログラム

IrCOMM

OBEXアプリケーション層（目的指向型通信手順）IAS SERVER IAS CLIENT TinyTP(Flow Control)Information Access Serviceトランスポート層IrLMP(IrMUX)Link Management (Multiplexer)リンクマネージメント層（通信経路の多重化）IrLAP Link Access Protocolデータリンク層（信頼性のある通信経路）

IrPHY(赤外線物理層)物理層赤外線信号への変復調

基礎編で学んだように、赤外線物理層であるIrPHY の上位には、データリンク層として、

装置発見手順による、通信相手の発見と選択、リンクの接続／切断、データ転送をつかさどるIrLAP プロトコルがある。その上位層には特定の論理接続とデータ転送を行うIrMUX層と論理リンクや装置の特性を知るためのデータベースであるIASを持つIrLMPプロトコルが用意される。IrDA 規格では、最低限度この３層のプロトコル層を持つことが必須となっている。アプリケーション層によっては、データ転送の取りこぼしが起こらないようにデータの流れ（データフロー）を制御するTinyTP プロトコルを必要とするものもある。

OSI 参照モデルとIrDA 規格の関係IrDA プロトコルは、電気通信におけるプロトコルを記述するための国際標準である「OSI参照モデル（開放型相互接続モデル）」を基準にしており、それぞれの層のサービスも、この規定にしたがっている。プロトコルサービスの要求(Request)IrDA 提供するプロトコルサービスは、このOSI 参照モデルの命名規則に基づいている。上位層から、プロトコルのサービスを使用する場合、サービスを要求（Request）を行う。これにより、プロトコル・プロバイダは要求パケット（PDU）

を作成し相手局に送信する。（たとえば、IrLAP_CONNECT.要求など）相手からのサービス要求の通知（Indication）相手局からの要求PDU をサービス・プロバイダガ受信すると、相手局からの要求を上位層に通知するために、OSI 参照モデルでは、指示(indication)というサービスを使用して上位層に通知する。 (たとえば、IrLAP_CONNECT.指示など)指示に対する応答（Response）

プロトコル・プロバイダからの指示通知があった場合、それに対する応答を相手がわに行わなくてはならない場合がる。このことをOSI 参照モデルでは、応答（Response）と呼び、指示に対する応答を行う。（たとえば、IrLAP_CONNECT.応答など）サービス・プロバイダは、その応答に必要な応答パケット（PDU）をサービスを要求する上位層サービスを提供するプロトコル・プロバイダミドルウェアなど接続相手アプリケーション接続相手に実装されるプロトコル・プロバイダWindows 98 などIrDA 装置IrDA 装置作成し、相手局に送信する。

自局の要求に対する相手からの応答を確認する(Confirm)相手からの応答をプロトコル・プロバイダが受け取ると、相手局からの応答を上位層に通知するために、OSI 参照モデルでは、確認(confirm)といいうつうちを行う。 (たとえば、IrLAP_CONNECT.確認など)これらの仕組みを、IrLAP_CONNECT 手順を例に図示すると次のようになる。赤外線IrLAP_CONNECT.要求は、自局のプロトコル・プロバイダに対してIrLAP レベルでの接続要求を起動する。プロトコル・プロバイダは、IrDA プロトコルの規定に基づいて、IrLAPの接続要求に該当する赤外線パケットを作成し、相手局に送信する。IrLAP 接続要求パケットを受信した相手局のプロトコル・プロバイダは、パケットを解析し、ジョイ層に対してIrLAP_CONNECT.指示を行う。相手局の上位層は、接続を許可する場合、プロトコル・プロバイダのIrLAP_CONNECT.応答サービスを呼び出す。プロトコル・プロバイダ、IrLAPの接続応答に該当する赤外線パケットを作成し、相手局に送信する。IrLAP 接続応答パケットを受信したサービス・プロバイダは、パケットを解析し、上位層に対してIrLAP_CONNECT.確認を通知する。

IrLAP_CONNECT.要求IrLAP_CONNECT.指示IrLAP_CONNECT.応答IrLAP_CONNECT.確認自局プロトコル相手プロトコル

IrDA プロトコルの実装例

基礎編で学んだように、IrDA プロトコルやOSI 参照モデルにおけるプロトコルのサービ

スモデルの定義は、特定装置の実際の実装を規定したものではなく、プロトコルが提供するサービスについての抽象的な実体（エンティティー）を規定しているに過ぎない。しかしながら、実際に装置に組み込まれるミドルウェアや、OS などは、何らかのプログラム言語でそのサービスを使用できるように設計されている。ここでは、実際にIrDA プロトコルを実装しているWindows98 や、ミドルウェアの例を紹介することでプロトコルがどのように実装されるのかを見て行くことにする。

ミドルウェアでの実装例現在、いくつかのプロトコル・ミドルウェアメーカから、IrDA プロトコルが発売されている。ここで取り上げるIrDA プロトコルミドルウェアは、オカヤ・システムウェアがOEM向けにライセンスしている、IrDA プロトコルスタックのミドルウェアであるμ-DeepCoreを実装例として実際の実装を見ていこう。μ-DeepCore は、RAM 資源の少ない組み込みシステムのために開発されたIrDA プロトコルミドルウェアであり、IrDA プロトコルを構成する為に必要なIrLAP、IrLMP、TinyTPなどの基本的なプロトコルコンポーネントと、IrCOMM などの特定のアプリケーションに必要なアプリケーション層を含む。μ-DeepCore を使用するアプリケーションはC 言語で記述できるようになっており、IrDA の各プロトコル層のサービスは、C 言語の関数で提供されるAPI（アプリケーション・インターフェイス）によりプロトコルサービスを呼び出すことが出来る。IrCOMM、OBEX などのアプリケーション層は、ソースコードで提供されており、装置の環境に合わせてカスタマイズが可能となっている。

ミドルウェアにおけるOSI 参照モデルの実装μ-DeepCore におけるIrDA プロトコルの実装において、OSI 参照モデルにおける、要求、指示、応答、確認という４つの基本的なサービス・プリミティブをどのようにC 言語を使用して実装しているか見て行くことにしよう。プロトコルサービスの要求(Request)の実装μ-DeepCore が提供するAPI は、OSI 参照モデルの命名規則に基づいている。上位のアプリケーションから、プロトコルのサービスを要求（Request）する場合は、Req をサフックスとするAPI を使用する。

（たとえば、TtpConnectReq など）IrDAプロトコルは、上位のアプリケーションと平行動作が出来るように、要求API をμ-DeepCore が受理すると、IrLAP のPDU を作成し、そのパケットを送信するバックグラウンドのタスクを起動し即座にアプリケーションに戻る。相手からのサービス要求の通知（Indication）今度は、μ-DeepCore が相手局からの要求を受理すると、相手局からの要求をアプリケーションなどに通知するために、プロトコルからの指示(indication)を受け取るために、あらかじめアプリケーションに作りこまれたコールバック関数を呼び出す。μ-DeepCore のコールバック関数の命名規則は、Cb という、コールバックを意味する文字と、指示を表す Ind をサフィックスとするコールバック関数を呼び出すことになる。 (たとえば、TtpCbConnectInd など)アプリケーションが通知を受けるコールバックは、アプリケーションと非同期で呼び出される。μ-DeepCore は、IrDA プロトコルを赤外線ハードウェア、タイマーなどの割込みイベントにより駆動され、アプリケーションと平行してバックグラウンドで動作しプロトコル処理で必要となる通知を行う。

指示に対する応答（Response）μ-DeepCore からの指示コールバックがあった場合、それに対する応答を行なう必要がある場合がある。応答にするμ-DeepCore が用意するAPI は、Res というサフィックスを持つ。（たとえば、TtpConnectRes など）。μ-DeepCore は、その応答に必要な赤外線データフレーム作成し、そのパケットを送信するバックグラウンドのタスクを起動し即座に戻る。

相手からの応答を確認する(Confirm)相手からの応答をμ-DeepCore が受け取ると、相手局からの応答をアプリケーションなどに通知するために、あらかじめアプリケーションに作りこまれたコールバック関数を呼び出す。μ-DeepCore は、Cb という、コールバックを意味する文字と、指示を表す Cnf をサフィックスとするコールバック関数を呼び出します。(たとえば、TtpConnectCnf など)μ-DeepCore におけるTinyTP 層のAPI 仕組みを図示するとすると次のようになる。

赤外線TtpConnectReq()TtpCbConnectInd()TtpConnectRes()TtpCbConnectCnf()μ-Deep Coreμ-Deep Core TtpConnectReq 関数は、μ-DeepCore に対してTinyTP レベルでの接続要求を起動する。μ-DeepCore は、IrDA プロトコルの規定に基づいて、TinyTP の接続要求に該当する赤外線パケットを作成し、相手局に送信する。TinyTP 接続要求パケットを受信した相手局のμ-DeepCore は、パケットを解析し、アプリケーションに組み込まれたTtpCbConnectInd 関数をコールバックし、TinyTP の接続指示を通知する。アプリケーションが、接続要求を許可するならば、μ-DeepCore のAPI であるTtpConnectRes 関数を呼び出す。接続を許可しない場合はTtpDisconnectReq 関数を呼び出す。μ-DeepCore は、TinyTP の接続応答に該当する赤外線パケットを作成し、相手局に送信する。TinyTP 接続応答パケットを受信したμ-DeepCoreは、パケットを解析し、アプリケーションに組み込まれたTtpCbConnectCnf関数をコールバックし接続要求に対する応答の確認を通知する。

プロトコルサービスに必要な指示、確認などのアプリケーションと非同期で発生するIrDA プロトコルのイベント通知はすべて、アプリケーション内に組み込まれたコールバック関数により実装されている。IrDA プロトコルは、接続の維持を行うためにデータ転送がない場合でもIrLAP 層では、0.5 以内にRR（受信可）のパケットを交換し合う必要がある。これらの処理はアプリケーションと平行してプロトコルが行い、上位に通知が必要になった場合のみ（つまり、サービスプリミティブの指示、確認）アプリケーションに作りこまれたコールバック関数を呼び出す。

μ-DeepCore のAPI は、IrDA 規格のサービスプリミティブの命名規則に合わせてAPIを構成しているため、IrDA 規格との関連が明確で理解が容易である。プロトコルとアプリケーションの結合μ-DeepCore のほとんどのAPI は、呼び出すとサービスを予約して、即座に戻ってくる。μ-DeepCore がそのサービスを受理すると関数の戻り値が、DCR_ACCEPT（０）を戻す。プロトコルが管理する現在の状態で要求不可能なサービスを呼び出すと、その呼び出しは失敗に終わる。実際のプロトコルの動作は、ハードウエアの割込みによって動作が行われ、プロトコルの処理はバックグラウンドで自動的に行われることはすでに述べた。サービスが完了すると、アプリケーション内部に作りこまれたコールバック関数が呼び出されて処理の終了を通知する。したがって、μ-DeepCore がプロトコルを処理中でも、アプリケーションは平行して他の仕事をすることができる。

上位層からのデータ転送IrDA プロトコルの特性として、データフレームが実際に交換できるタイミングは、IrLAPのメディア・アクセス・ルールと、IrLAP の特定のタイミング以外は交換できない。また、IrLAP 層においてデータ交換を行うためのI フレームは、そのSDU（サービスデータユニット）に上位層からのデータが必要となる。μ-DeepCore は、プロトコルスタックで使用するRAM メモリを最小化するため、内部で使用するデータバッファを出来るだけ少なくするように設計されているため、IrLAP データ転送要求を保持するためのバッファをプロトコル側で用意していない。また、IrDA プロトコルにおいて、上位層から送信されるデータを受理し、赤外線で相手に送信しても、正しく相手に伝わったかどうかは、相手からの応答を待たなければならない。もしも、赤外線の経路に障害物があったり、外光によるデータ化けが発生した場合は、IrLAP の再送手順を使って、もう一度データを再送する必要がある。

メモリの最小化の観点から、アプリケーションのバッファをプロトコル側でも有効に活用するようにしている。μ-DeepCore は、上位層から設定されたデータの再送が必要な場合は、上位層にコールバックを行い、再度同じデータを与えるようにする方式を採用している。そのため、上位層、アプリケーション層からの明示的なデータ要求関数は存在しない。そのかわり、μ-DeepCore がデータ送信可能なタイミングでアプリケーションに作りこまれたデータセット要求コールバック関数(xxxCbDataSet)をよびだし、送信すべきデータをアプリケーションに要求する。プロトコルがデータを送信し、そのデータを相手が受け取れた時点ででデータ確認コールバック関数(xxxCbDataCnf)の２つをよびだし、そのデータをアプリケーション側でリリースするタイミングを与える。このようにμ-DeepCoreはアプリケーションと協調してデータを送信する。

μ-DeepCore が提供するAPI の概要μ-DeepCore が提供するAPI は、IrLMP よりも上位のAPI を提供する。IrLAP のAPIが存在しないのは、IrLMP が、IrLAP のすべてのサービスを掌握し、ステーション管理を行い、マルチプレクサであるIrMUX 実現するためである。バッファ関連の通信品質（IrLAP-QOS）設定IrLAP 層、IrLMP 層に必要な受送信バッファは、ユーザアプリケーションで用意する。μ-DeepCore で使用する送受信バッファ、送受信バッファサイズは、予約された名前をもつ変数でアプリケーションが用意する。アプリケーションは組み込むシステムのメモリとのトレードオフを行ってバッファサイズを決定できる。

DCBYTE SirTRxBuffer[]IrSIR 送受信バッファDCU16C SirTRxBufferLen IrSIR 送受信バッファバイトサイズIrDA で規定している送受信フレームサイズと確保するバッファのサイズ、バッファサイズ長の値は以下のようになるフレーム長SirTRxBuffer サイズSirTRxBufferLen の値64 68 66 128 132 130 256 260 258 512 516 514 1024 1028 1026 2048 2052 2050μ-DeepCore では、Window Size は１に固定されている。実際のバッファサイズは、IrLAP のフレームサイズにIrLAP のアドレス部、コマンドレスポンス部、CRC 部を加算した（4 バイト加算）したものとなる。

IrLAP 層（LmpLinkXXX API,LmpCbLinkXXX CallBack）IrLAP 層は、信頼性のある通信経路を構築する。信頼性のあるデータ通信経路とは、通信するデータに誤りがなく、送受するデータの順序が正しく保証されているということ基礎編で学んだ。IrDA 規格において、IrLAP のサービスはすべてその上位層であるIrLMP 層が管理することになっているので、μ-DeepCoreでは、Lmp レイヤから間接的にアクセスする。

IrLAP 切断、接続要求API LmpLinkConnectReq LAP レベルでの接続要求LmpLinkDisconnectReq LAP レベルでの切断要求アプリケーションで用意する通知関数LmpCbLinkConnectCnf LAP レベルの接続確認コールバックLmpCbLinkConnectInd LAP レベルの接続指示コールバックLmpCbLinkDisconnectInd LAP レベルの切断指示コールバック装置発見手順で自局の装置名称を格納する変数Const DCBYTE LapDeviceName[]装置名称Const DCU8C LapDeviceNameSize装置名称バイトサイズ装置発見手順に関連するデータDISCOVERYINFO LapDiscoveryInfoTab[]発見装置テーブルDCU8C LapDiscoveryInfoTabSize発見装置デーブルサイズDCU8C LapSlotSize発見スロット数DCU8C LapDiscoveryFounds発見した装置数ユーザが設定できる通信品質DCU16C LapQosDiscTimeリンク切断時間IrLMP 層（LmpXXXX API ,LmpCbXXXX CallBack）

IrLMP 層は、その上位にある、IAS 層（Information Access Service）や、TinyTP層に経路を分割する、リンクマネージメント層である。また、IrDA 固有の「装置発見手順」も行う。IrLMP 層の初期化、終了API LmpInit Lmp 層以下の初期化を行うLmpTerm Lmp 層以下のリソースの開放装置発見手順（Discovery）API LmpDiscoveryReq装置発見手順要求LmpChkServiceHint装置のサービスヒントの取得LmpGetShortDevNameIdx短縮機器名称インデックス取得装置発見手順（Discovery）API LmpCbDiscoveryCnf装置発見手順確認コールバック装置発見手順によって検出されたデバイスリストは、LapDiscoveryInfoTab[]に格納される。LMP 層で複数の通信経路（LSAP：Link Service Access Point）に分割され、分割された通信経路は、IAS サーバー、IAS クライアント、TinyTP クライアントの３つに分岐しそれぞれのクライアント、もしくはサーバーのAPI によりアクセスされる。それぞれのLSAP は次のようになっている。

IrMUX クライアント名LSAP 番号IAS サーバー0 TinyTP クライアント1 IAS クライアント2 IAS クライアント(IAS Client IasXXXX API,IasCbXXXX Callback)IAS クライアントは、IrDA プロトコルの相手局のデータベースにアクセスし、必要な情報（LSAP など）を取り出すためのIrMUX クライアントである。IAS クライアントの初期化、終了API IasCliInit IAS CLIENT の初期化を行う。

IasCliTerm IAS CLIENT の終了処理を行う。相手局のIAS サーバに接続、切断を行うAPI IasConnectReq IAS 接続要求 相手局のIAS へ接続要求を行なうIasDisconnectReq IAS 切断要求 接続中のIAS リンクを切断するアプリケーションで用意するコールバック関数IasCbConnectCnf相手のIAS に接続通知（接続確認）コールバックIasCbDisconnectInd相手のIAS が切断通知（切断指示）コールバックIasCbQueryDataSet問い合わせデータセット要求通知コールバックIasCbQueryDataCnf問い合わせデータセット完了確認コールバックIasCbQueryCnf IAS 問い合わせ処理が完了した（Query 確認）

相手局から取得したIAS データを照合するAPI IasQueryResult IAS 問合せ結果の合否を確認するIasQueryGVBCId'GetValueByClass '問合せ結果ID 値取得IasQueryGVBCInteger'GetValueByClass '問合せ結果INTEGER 値取得IasQueryGVBCListSize'GetValueByClass '問合せ結果リスト数取得IasQueryGVBCType'GetValueByClass' 応答結果種別取得IAS サーバー（IAS Server）

IAS サーバーは、装置名称(DeviceName)や、自分のIrMUX クライアントにどのようなアプリケーションが接続されているかを示すさまざまな情報をデータベース化します。相手局のIAS クライアントがアクセスし、要求のあった情報を適切に処理する。IAS サーバーには、２つのAPI だけがあり、データベースに登録されるデータは、すべてリンク構造を持った構造体で定義されたデータをROM 上に置くことで実現する。

IasSvrInit IAS SERVER 初期化処理IasSvrTerm IAS SERVER 終了処理IAS サーバーのデータベースに関連する構造体をは次のものですIASOBJ IasObject IAS データの最初のエントリ構造体TinyTP 層(TtpXXXX API,TtpCbXXXX Callback)通常、IrDA 規格のアプリケーション層は、TinyTP プロトコル上で作られる。μ-DeepCore は、TinyTP を使用する通信経路をひとつ提供する。

初期化終了API TtpInit TinyTP の初期化を行う。TtpTerm TinyTP の終了処理を行う。切断接続API TtpConnectReq相手局の指定LSAP に対して接続要求を行う。TtpConnectRsp相手局への接続応答パケットを送信要求する。TtpDisconnectReq接続中のTinyTP リンクを切断するTinyTP 接続時、切断時のデータ転送コールバックTtpCbConnectDataSet接続時のデータセット要求通知コールバックTtpCbConnectDataCnf接続時のデータセット完了通知コールバックTtpCbDisconnectDataSet切断時のデータセット要求通知コールバックTtpCbDisconnectDataCnf切断時のデータセット完了通知コールバック注意：TinyTP は、接続時、切断時にデータを交換することが出来ます。

データ転送関係API TtpAddCreditクレジット追加 クレジットを追加する。データ転送コールバックTtpCbDataSet送信データセット要求通知コールバックTtpCbDataCnf送信データセット完了通知コールバックTtpCbDataInd受信データ指示通知コールバック装置発見手順と接続アドレス装置発見手順を行うためにはIrLAP 規格書で規定されるLapSlotSize に検索する装置の最大個数（1,6,8,16 のいずれかを選択）をセットし、LmpDiscoveryReq 関数を呼び出す。

LmpCbDiscoveryCnf がコールバックされると、装置発見手順が終了する。LapDiscoveryInfoTab[]に発見したデバイスのログが確保できるが、発見した装置の個数はLapDiscoveryFounds で示される。LapDiscoveryInfoTab は、DISCOVERYINFO 構造体で定義したメンバーを持っている。装置アドレス(addr フィールド)この構造体にはaddr メンバー変数がある。addr は、IrLAP 接続に必要な装置アドレスが格納されており、この変数を使用して、LmpLinkConnectReq によりIrLAP 層の接続を行う。

name フィールドとLapDeviceName[]DISCOVERYINFO 構造体のmame フィールドと自局の装置名称を格納するLapDeviceName は、同じ構造である。これらの内部データ構造は、基礎編で学んだIrDA 規格の装置情報フィールド規格に従う。組み込みミドルウェアのまとめ組み込みシステム向けのIrDA プロトコルミドルウェアであるμ-DeepCore のプロトコル実装例を見てきた。プロトコルは、アプリケーションと平行動作し、IrDA プロトコルから発生する非同期なイベントを自発的に処理する。プロトコルは必要に応じてアプリケーションに通知を行わなければならない「指示プリミティブ」や「確認プリミティブ」は明示的にプロトコルがアプリケーションに組み込まれたコールバック関数を呼び出すことで行われる。

アプリケーションに組み込まれたコールバック関数を使用することで、IrDA 規格のサービスプリミティブとの対応（要求、指示、応答、確認）が明確になっている。組み込みシステムの場合は、OS やCPU が特定できないので多くのIrDA プロトコル・ミドルウェアはC 言語で記述されており、特定のプラットホームに依存しないようにハードウェアを制御する部分は、ユーザが作成するハードに依存するAPI をプロトコルが呼び出す構成となる。

Windows システムとIrDA プロトコル

WinSock とIrSOCK

マイクロソフト社が提供するオペレーティングシステムであるWindows 98/85、Windows CE、Windows 2000 にも、IrDA プロトコルが標準でOS に組みこまれている。マイクロソフト社は、これらのOS で動作する共通のオペレーティングシステムAPI であるWin32 API 用意しプラットホームの違いを最小化している。Windows OS 上のでのIrDA プロトコルサービスの実装は、Windows に組み込まれたネットワークソケットサービスであるWinSock（ウインドウズ・ソケットサービス）のサブシステムである、IrSOCK とよばれるソケットサービスプロバイダーに実装されている。

IrSOCK は、WinSockAPI のサブシステムであるため、IrDA プロトコル独自のAPI はなく、WinSock の標準的なネットワークサービス層API としてIrDA を間接的に使用することとなる。

WinSock は、バークレー版UNIX のネットワークサービス層であるソケットサービスベ

ースとして構成され、Windows アプリケーションからTCP/IP などのネットワークエンティティをアクセス可能にする。ソケットサービスは、インターネットやその他の様々なネットワーク層のアクセスプロトコルには共通点が多く、接続、切断、データ転送については共通な概念である。それぞれのプロトコルは、その特性として独自のサービスをもつが、この部分についてはソケット制御とよばれるサービスを使用し、プロトコル毎に用意されたデータ構造によりプロトコル独自のサービスを提供する。

アドレスファミリアプリケーションがソケットサービスを使用してOS の用意しているネットワークプロトコルを使用する場合、ネットワークプロトコルと関連付けするためのプロトコル識別子であるアドレスファミリとそれに付随した構造体によりプロトコルの動作を決定する。

WinSock の場合、TCP/IP プロトコルを使用したい場合は、AF_INET というアドレスファ

ミリーを、IrDA プロトコルを使用する場合はAF_IRDA というアドレスファミリを指定する。

WinSock のAPI

WinSock のAPI は、バークレー版のUNIX で使用されているAPI を踏襲しているので、

サービスAPI もほぼ同じである。ここでWinSock の用意する主なAPI について列挙しておく。Acceptイニシエータ側の接続要求を受け入れるBindソケットにローカル名を割り当てるClosesocket生成されたソケットをクローズしOS リソースを開放するConnect指定したソケットに対して接続を要求するGetsockopt指定したソケットに関連付けたプロトコルの拡張を取得するIoctlsocket指定したソケットのプロトコルを制御するListen特定のソケットの接続を待つRecv接続中のソケットからデータを受信するSend接続中のソケットへデータを送信するSetsockopt指定したソケットに関連付けられたプロトコルの拡張を設定するSocket通信のエンドポイントを作成しソケット記述子(ハンドル)を取得するIrDA とWinSock API の関係Socket の生成Windows 上でIrSOCK を使用する場合、IrDA プロトコルのサービスを呼び出すため、ソケット作成時に使用されるScoket()API において、アドレスファミリ

AF_IRDA を使用する。まず、未使用のSOKET ハンドルを用意し、WinSock サ

ービスに通信のエンドポイント作成を依頼する。SOCKET Handle;Handle = socket(AF_IRDA,SOCK_STREAM,0);このAPI を呼び出すことにより、IrDA プロトコルと関連付けられたソケットハンドルを生成しソケットハンドルを取得する。ソケットアドレスの指定とBind IrLMP のIAS で使用されるクラスネームを指定する。これにより、IAS クラスに登録されるクラス名と、LSAP が関連付けられる。Bind API で使用される構造体は、SOCKADDR_IRDA である。

typedef struct _SOCKADDR_IRDA{
u_short irdaAddressFamily;

// アドレスファミリ(AF_IRDA)u_char irdaDeviceID[4];// デバイスアドレスchar irdaServiceName[25];// 関連するIAS クラス名} SOCKADDR_IRDA, *PSOCKADDR_IRDA, FAR *LPSOCKADDR_IRDA;SOCKADDR_IRDA IrSockAddr = {AF_IRDA,0,0,0,0,”MyIasName”};bind(Handle,(const struct sockaddr*)&IrSockAddr,sizeof(SOCKADDR_IRDA));このAPI により、Handle で記述されたソケットに対してWindows は、LSAP を割り当て、”MyIasName”クラスの、”IrDA:TinyTP:LsapSel”アトリビュートをもつ値にこのハンドルに使用されるLSAP 番号を割り当てる。（このAPI を発行した時点でLSAP が割り当てられるわけではない）

サーバー動作指定とコネクション数の設定Listen （サーバー）Listen API は、Handle で記述されたソケットの動作をサーバー動作（Listen mode）にする。サーバー動作とは、接続を待つだけのレスポンダ（応答側）として動作することを意味する。また、IrSock では、イニシエータ（起動側）をクライアントと呼んでいる。Listen で指定できるパラメータは、いくつのクライアントがこのソケットに接続することが出来るかを指定する。

if (listen(Handle, 1) == SOCKET_ERROR){// サーバーモード起動失敗}// サーバーモードとしてソケットが動作する。サーバー接続待ちと新規ソケットの生成 Accept（サーバー）Accept API は、クライアントがこのサーバーに対して接続を行うまで待つ。接続がクライアントによって確立すると、新たなソケットが生成される。サーバーアプリケーションは、新たに生成されたこのソケットを使用してデータの受送信を行うことが出来る。

SOCKET NewSock;
sizeofSockAddr = sizeof(SOCKADDR_IRDA);

if ((NewSock = accept(Handle, (struct sockaddr *) &PeerSockAddr,&sizeofSockAddr)) == INVALID_SOCKET){// 接続待ちで以上発生}// 接続が完了し、新たなソケットが生成されたディスカバリ動作と接続 getsockopt 、connect（クライアント）IrSock を使用して、IrDA 接続を行うアプリケーションは、connect 動作を行う前に、getsockopt と、IRLMP_ENUMDEVICES オプションを使用して、ディスカバリ動作を起動し、デバイスログを取得する必要がある。

IRLMP_ENUMDEVICES オプションを使用してgetsockopt API を呼び出すと、IrSock は１回のディスカバリ動作を行いディスカバリログを取得するか、すでにディスカバリ動作が完了していればそのディスカバリログの複製を得ることが出来る。このAPI で取得できるディスカバリログは、IrLMP のDiscovery 要求サービスで取得されるログと基本的に同じものである。このディスカバリで取得したログの発見デバイス数と、装置単位のログにあるデバイスアドレスを使用して、connect API を使用して接続を行う。

typedef struct _IRDA_DEVICE_INFO{
u_char irdaDeviceID[4];

//デバイスアドレスchar irdaDeviceName[22];//デバイスネームu_char irdaDeviceHints1;//サービスヒント1 バイト目u_char irdaDeviceHints2;//デーバスヒント２バイト目u_char irdaCharSet;//デバイス名のキャラクタセット} _IRDA_DEVICE_INFO;SOCKADDR_IRDA DstSockAddr={AF_IRDA,0,0,0,0,"YourIASClass" };#define DEVICE_LIST_LEN 6 unsigned char DevListBuff[sizeof(DEVICELIST) -sizeof(IRDA_DEVICE_INFO) +(sizeof(IRDA_DEVICE_INFO) * DEVICE_LIST_LEN)];int DevListLen = sizeof(DevListBuff);PDEVICELIST pDevList = (PDEVICELIST) &DevListBuff;pDevList->numDevice = 0;// 発見デバイス数を0 にしておく// ソケットはまだ接続していないとする。(ディスカバリを行う)if (getsockopt(Handle, SOL_IRLMP, IRLMP_ENUMDEVICES,(char *) pDevList, &DevListLen) == SOCKET_ERROR){// ディスカバリ失敗}if (pDevList->numDevice == 0){// もし、デバイスが発見できない場合はnumDevice は0 になる}for (i = 0; i < (int) pDevList->numDevice; i++){// 通常はここでサービスヒント、デバイス名称等をチェックする}// 取得したログから、デバイスアドレスを取りだし、接続要求を行うmemcpy(&DestSockAddr.irdaDeviceID[0],&pDevList->Device[0].irdaDeviceID[0], 4);if (connect(Sock, (const struct sockaddr *) &DestSockAddr,sizeof(SOCKADDR_IRDA)) == SOCKET_ERROR){// WSAGetLastError}IAS の設定と取得 setsockopt getsockopt IrSock のオプション機能を使用すれば、IAS データベースに新たなクラスやアトリビュートを登録したり、接続相手のIAS データベースを検索することが出来る。

IAS に新しいデータベースエントリを生成するには、setsockopt API を使用し、IRLMP_IAS_SET オプションを指定する。IAS エントリを生成するために使用する構造体は、次の形式となる。

typedef struct _IAS_SET{

char irdaClassName[IAS_MAX_CLASSNAME]; //クラスchar irdaAttribName[IAS_MAX_ATTRIBNAME];//アトリビュートu_long irdaAttribType; //値の型union{LONG irdaAttribInt;//整数型struct{ //オクテット型u_short Len;u_char OctetSeq[IAS_MAX_OCTET_STRING];} irdaAttribOctetSeq;struct{ //ユーザストリング型u_char Len;u_char CharSet;u_char UsrStr[IAS_MAX_USER_STRING];} irdaAttribUsrStr;} irdaAttribute;} IAS_SET, *PIAS_SET, FAR *LPIAS_SET;実際にIAS を登録するためには次のようなAPI 操作を行う必要がある。

// IAS で使用するバッファを用意するBYTE IASSetBuff[sizeof(IAS_SET) - 3 + IAS_SET_ATTRIB_MAX_LEN];Int IASSetLen = sizeof(IASSetBuff);PIAS_SET pIASSet = (PIAS_SET) &IASSetBuff;// ソケットを用意するSOCKADDR_IRDA ServSockAddr = { AF_IRDA, 0, 0, 0, 0, "MyIASClass " };SOCKET ServSock;ServSock = socket(AF_IRDA, SOCK_STREAM, 0); //ソケットを生成する// クラス名’MyIASClass’,アトリビュートは’Parametsers’memcpy(&pIASSet->irdaClassName[0], "MyIASClass ", 10);memcpy(&pIASSet->irdaAttribName[0], "Parameters", 11);pIASSet->irdaAttribType = IAS_ATTRIB_OCTETSEQ; //オクテット型pIASSet->irdaAttribute.irdaAttribOctetSeq.Len = 6;//データ長は6 バイト//値の内容をコピーするmemcpy(&pIASSet->irdaAttribute.irdaAttribOctetSeq.OctetSeq[0],"ABCDEF”, 6);//IrSock のIAS データベースにこのデータを登録するsetsockopt(ServSock,SOL_IRLMP, IRLMP_IAS_SET,(const char *) pIASSet, IASSetLen);また、接続相手のIAS を検索するには、getsockopt API を使用し、IRLMP_IAS_QUERY オプションを指定する。IAS を取得するために使用する構造体は、次のような形式である。

typedef struct _WINDOWS_IAS_QUERY{
u_char irdaDeviceID[4];

//相手のデバイスアドレスchar irdaClassName[IAS_MAX_CLASSNAME]; //クラスchar irdaAttribName[IAS_MAX_ATTRIBNAME];//アトリビュートu_long irdaAttribType; //値の型union{LONG irdaAttribInt;//整数型struct{ //オクテット型u_long Len;u_char OctetSeq[IAS_MAX_OCTET_STRING];} irdaAttribOctetSeq;struct{ //ユーザストリング型u_long Len;u_long CharSet;u_char UsrStr[IAS_MAX_USER_STRING];} irdaAttribUsrStr;} irdaAttribute;} IAS_QUERY, *PIAS_QUERY, FAR *LPIAS_QUERY;実際に接続相手のIAS を検索するためには、次のようなAPI 操作を行う。

// すでにディスカバリを行い、ディスカバリログを取得しているとする// IAS 問い合わせのためのバッファを確保する#define QBSIZE sizeof(IAS_QUERY)-3+IAS_QUERY_ATTRIB_MAX_LEN BYTE IASQueryBuff[QBSIZE];Int IASQueryLen = sizeof(IASQueryBuff);PIAS_QUERY pIASQuery = (PIAS_QUERY) &IASQueryBuff;//ディスカバリログから、デバイスアドレスをセットするmemcpy(&pIASQuery->irdaDeviceID[0],&pDevList->Device[0].irdaDeviceID[0],4);//検索する相手のIAS クラス、アトリビュートをセットするmemcpy(&pIASQuery->irdaClassName[0], "MyIASClass", 10);memcpy(&pIASQuery->irdaAttribName[0], "Parameters", 11);//IrSock にIAS 検索を行わせるif (getsockopt(Sock, SOL_IRLMP, IRLMP_IAS_QUERY,(char *) pIASQuery,&IASQueryLen) == SOCKET_ERROR){//検索失敗}// 検索成功// pIASQuery->irdaAttribType には、値の型が格納されているデータの交換 send,recv実際のデータ交換は、send API と、recv API により行われる。

接続されているソケットから、データを取得するためには、次のようなAPI 操作を行う。Int BytesRead;//受信バイト数BYTE Buffer[1024];//受信バッファif ((BytesRead = recv(Sock, Buffer, sizeof(Buffer), 0)) == SOCKET_ERROR){// 受信失敗}if (BytesRead == 0){// 読みこみバイト数が0 の場合は相手が切断した}こんどは、接続相手にデータを送信するには、次のような操作を行う。

Int BytesSend;//送信バイト数BYTE Buffer[1024];//送信バッファif ((BytesSent = send(Sock, Buffer, sizeof(Buffer), 0)) == SOCKET_ERROR){//送信失敗}// 送信できたバイと数をチェックするソケットの開放 closesocket最終的にソケットの使用を終了しを開放するには、closesocket を使用する。

プロトコルから見たIrSOCK の制限Windows システムでは、WinSock のサブシステムであるIrSock を使用することにより、比較的容易にIrDA デバイスと接続をすることができる。しかし、IrSock がすべてのIrDA機能を満たしているわけではない。IrSock で取り扱えるのは、IrLMP レベルではディスカバリとIAS 登録/検索だけである。また、ソケットと関連つけられるLSAP は基本的にTinyTP 上のクライアントに限られる。

したがって、IAS エントリに登録されるLSAP 番号は自動的にIrSock 内部で生成され、そのLSAP アトリビュートは‘IrDA:TinyTP:LsapSel’となる。TinyTP 層でもいくつかの制約がある。IrSock では、TinyTP の分割再構成は提供されておらず、すべてバイトストリームのみしか取り扱えない。また、接続時の接続パラメータ交換や、切断時のパラメータ交換を明示的に行うことも出来ない。send , recv API を使用してデータ交換を行うときの注意としては、IrDA プロトコルのPDU の単位とsend , recv API によって取り扱うデータの境界は一致していない。

IrSock を使用する場合には、以上の制限があることを考慮しなければならない。とくに、IrSock によるデータ交換を行うことを考えている周辺装置についてはこの制約を考慮した実装が必要となる。IrDA アプリケーション層の構成この章では、基礎編で学んだIrDA 基本規格である、IrLAP、IrLMP、TinyTP 規格の上位にどのようにアプリケーション層を構築できるのかを検討することにしよう。基礎編では、IrDA 基本規格の詳細をPDU レベルまで踏み込んで議論した。この章ではこれらのレイヤをどのように使用するのかという視点でIrDA 基本層を眺めてみよう。まずは上位層から使用できるエンティティを復習する。

サービスヒントによるプロトコルの有無の確認IrLMP 規格で規定されているサービスヒントは、装置の種類、装置の持つプロトコルを接続前の装置発見手順上で上位層に提供する手段である。装置に新たな上位プロトコルがある場合、IrDAの管理のもとに上位プロトコルごとにサービスヒントビットが設定される。現在、IrCOMM、OBEX、IrLAN などのアプリケーションに対応するサービスヒントが規格化されている。したがって装置接続の前にこのサービスヒントの有無によりアプリケーションプロトコルの実装を確認することになる。

Byte 2 Bit Function 8 9 10

IrCOMM (Set)

11 12 13 14 15この例は、IrCOMM プロトコルを実装している装置におけるIrLMP 層のDiscovery ユーザデータの２バイト目には、IrCOMM プロトコルが実装されることを示すサービスヒントビットが設定されていることがわかる。IAS によるアプリケーションプロトコルのサービスレベルの照会サービスヒントは、アプリケーションプロトコルの有無を表す1 ビットの情報を提供するだけであり、広範な利用を可能にするようなアプリケーションプロトコルの場合、それだけでは情報不足である。たとえば、IrCOMM の場合、セントロニクスタイプのプリンタ、3 線式接続、9 線式接続によるRS232 規格などプロトコルのカバー範囲が広い場合もある。

IrDA 規格のアプリケーション層には、そのアプリケーション層固有の情報をIAS に登録することが決められている。IrCOMM の場合は次のようなIAS オブジェクトが登録されている。

IrCOMM クラス

IrDA:IrCOMM IrCOMM クラスの持つアトリビュートLSAP 番号IrDA:IrLMP:LsapSel 3-Wire Raw IrDA:TinyTP:LsapSel 3-Wire / 9-Wireプロトコル実装レベルParametersエミュレーションレベル上位アプリケーションInstanceName上位アプリケーション名この例からもわかるように、アプリケーション・プロトコルに接続する前に、IAP プロトコル（GetValueByCrass）によるIAS 検索によりアプリケーション・プロトコル層の特性が十分にわかるようになっている。新たなアプリケーションを定義する場合もこのようなエントリを含むことが望まれる。

IrLMP、TinyTP におけるLSAP 接続における接続パラメータの交換個別のLSAP を使用して、IrLMP、TinyTP クライアントに接続要求を行う時に、接続PCU に上位層が使用できるユーザデータの交換が可能になっている。IrLMP の上位にあるTinyTP はこのユーザデータの一部を使用して、フロー制御に必要な初期のクレジットと分割再構成に必要な最大PDU サイズの交換を行いTinyTP 層の初期化を行っている。このように、接続要求で交換されるユーザデータは上位のアプリケーション層でも使用される場合がある。IrCOMM プロトコルでは、モデム制御線の状態などをこの接続パラメータによって交換を行う。最近の傾向として、アプリケーション層は下位のプロトコル層と独立なプロトコルとして構成されることが多くなっている。このような構成をプロトコルの「コマンド/ランゲージ化（Commend/Language）」とよぶがこのようなマルチプロトコルを目指すアプリケーション層を設計する場合、マルチプロトコルを想定して接続パラメータ交換ができないことを考慮する必要がある。その場合は、接続パラメータを使用せずにアプリケーションが接続した場合の最初のデータ交換時に接続パラメータを交換する場合もある。OBEX プロトコルなどはそのように構成されている。

IrLMP、TinyTP におけるLSAP 接続における切断パラメータの交換アプリケーションプロトコルにおいて、切断が上位ユーザ層の切断要求の起動によって行われたのか、アプリケーションプロトコルによって切断されたかを通知する必要がある場合も想定できる。その場合の切断理由等は、IrLMP、TinyTP におけるLSAP 接続における切断パラメータの交換機能を使用して切断理由等を交換することが出来る。接続パラメータ、切断パラメータを使用する場合、考慮しなくてはならないのは、接続PDU サイズがIrLAP 層のデータサイズに依存しておりIrLAP の最小データサイズが64 バイトであることを考えると、パラメータは高々先頭から50 バイト程度しか保証されない。

アプリケーション接続シーケンス以上の復習から、一般的なアプリケーション層の動作はほとんど決まりきった流れとなる。図示すると次のようになる。起動側（イニシエータ）応答側（レスポンダ）IrDA アプリケーション層のひとつのセッションは、このような例と同様になる。ただし、IrLAP 層、IrLMP のステーションコントロール層がすでに接続している場合は、IrLAP 層が２次局であっても、アプリケーションは起動側になりうることに注意しよう。

Discovery 発行IrLMP or TinyTP LSAP の取得Service Hint の登録IAS エントリの登録Discovery レスポンスService Hint 検査IAS 接続IAP GetValueByClass 発行IAP 検索結果の取得IAS 切断IAS 接続受理IAP GetValueByClass 受理IAP レスポンス応答IAS 切断通知検索結果の確認LSAP 取得IrLMP or TinyTP 接続要求（接続パラメータを設定）

IrLMP or TinyTP 接続指示（起動側パラメータの確認）IrLMP or TinyTP 接続応答（接続パラメータを設定）IrLMP or TinyTP 接続確認（応答側パラメータを設定）IrLMP or TinyTPユーザデータの交換IrLMP or TinyTPユーザデータの交換IrLMP or TinyTP 切断要求（切断パラメータを設定）IrLMP or TinyTP 切断要求（切断パラメータを確認）

IrCOMM 規格

IrCOMM 規格の正式な名称は次のものである。

‘IrCOMM’:Serial and Parallel Port Emuration over IR (Wire Replacement)Ver 1.0 7 Novemver,1995タイトルのとおり、シリアルポートは歩調同期式のRS232E 規格と、パラレルポートについては、セントロニクス社およびIEEE1284 規格を赤外線に置き換えてエミュレーションを行うためのアプリケーション層である。IrCOMM は、IrDA 規格において、初めて制定されたアプリケーション層規格である。IrDA 規格アプリケーション層の最初の規格がケーブルのエミュレーションであるのは興味深いものがある。

IrCOMM は、IBM-PC パソコンの影響を受けており、その目的は、IBM-PC の既存のシ

リアルポート、パラレルポートをIrDA により代行し、ノートブック型PC などの携帯型パソコンと赤外線モデム、赤外線プリンタをケーブルを使用せずに接続することを目的としている。規格の範囲

IrCOMM 規格のカバーする範囲は、TinyTP を使用しない3-Wire Raw と呼ばれる3 線式

シリアルポートとIrLPT と呼ばれる接続とデータ転送のみの簡単な規格と、TinyTP を使用した、シリアルポートの3-Wire と呼ばれる３線式、9-Wire と呼ばれる9 線式の規格およびIEEE1284 プリンター規格を含んでいる。Windows98/95 では、このIrCOMM 規格のうち、9-Wire 規格、IrLPT 規格を標準で搭載している。3 Wire-Raw とIrLPT 規格の特長IrLMP 規格をベースとしている3-Wire Raw およびIrLPT 規格はIrCOMM 制定前の規格をIrCOMM が取り入れたものである。また、IrLMP のまるちぷレックスモードも使用していないため、3-Wire-Raw または、IrLPT がIrDA 上で動作し始めるとIrMUX で多重化されているプロトコルを同時に動作させることはできない。また、TinyTP のフロー制御を使用しないので、プリンタまたはシリアルポートがビジー状態であることを通知するためには、IrLAP 層のRNR（Receive Not Ready）を使用することになる。このように制約が多いものの、IrLAP、IｒLMP の２つのプロトコルのみで実装できるため、プリンターや複数のアプリケーション実装を必要としていない応用で多く使用されている。

3-Wire、9-Wire、IEEE1284 TinyTP 層を下位層として、本来のIrDA のトランスポート層までを使用したシリアルポートのエミュレーションおよびパラレルポートのエミュレーション規格である。3-Wire-Raw 規格では、接続とデータ交換のみしか扱えなかったが、3-Wire、9-Wire 規格では、TinyTP の接続パラメータを使用して、ポートの初期状態の通知、エミュレーションを行う回線速度、シリアルビットフォーマットなどがおこ行える。9-Wire 規格ではデータ転送中のモデム制御線の状態通知なども行える。本格的なRS232E 規格のエミュレーションを行うことが可能になっている。IEEE1284 は、双方向プリンタの規格であるがIrCOMMにおけるIEEE1284 規格を使用しているプリンターは現在存在していない。

IrCOMM のデバイスタイプ

IrCOMM では、ケーブルエミュレーションを行うデバイスを２つのタイプに類別している。

Type1 デバイスは、実際のケーブルは存在せず、純粋にプロトコルサービスとしてのシリアルポート、パラレルポートのエミュレーションを行うものである。たとえば、パソコンのアプリケーションと、IrLPT を実装したプリンターとのやり取りなどがこのType1の範囲に属する。一方、Type２デバイスは、赤外線で置き換えられたシリアルポートが実際のモデムやTAのデータ線を制御するために使用されるケースである。これらの例は、ISDN 公衆電話や

IrCOMM 対応の携帯電話などがあけられる。

エミュレートされるRS232E 信号グループ

IrCOMM でエミュレーションされるシリアルケーブルの信号線について説明しておく。

RS232 規格は、同期式、非同期式の25 ピンのシリアルケーブルについて言及しているが、

IrCOMM 規格でサポートされるのは非同期式（歩調同期式）に使用される信号のみを取り

扱う。3-WIRE エミュレーション3-Wire エミュレーションでは、EIA/TIA-232-E 規格で定義される次の信号線を用いる102 Signal Common共通信号グラウンド（赤外線では明示的に使用されない）103 Transmitted Data (TD)DTE がデータを送信する信号線104 Received Data (RD)DTE がデータを受信する信号線9-Wire エミュレーション9-Wire エミュレーションでは、3-Wire で使用される信号に加えてEIA/TIA-232-E 規格で定義される次の信号線を用いる。

105送信要求(RTS)Device A with IrDA(Type 1)Device B with IrDA(Type 1)IR Device A with IrDA(Type 1)Device B with IrDA(Type 2)Legacy Device IR Wire 106送信可(CTS)107データセットレディ (DSR)108/2データターミナルレディ(DTR)109キャリア検出 (CD)125被呼表示 (RI)

IrCOMM のサービスヒント

IrCOMM は、２つのサービスヒントを定義している。ひとつは従来からあるIrLPT のため

のサービスヒントとIrCOMM プロトコルのためのサービスヒントである。IrLMP をサービスするデバイスはIrLPT サービスビットを、その他のIrCOMM サービスを行うデバイスは、IrCOMM ビットを立てる必要がある。Byte 1 Bit Function 0 1 2 3 IrLPT (Set)4 5 6 7 Byte 2 Bit Function 8 9 10

IrCOMM (Set)

11 12 13 14 15 IAS エントリ

IrCOMM デバイスのIAS エントリは、クラス名をIrDA:IrCOMMとし、最低でもそのLSAP

を示すセレクタアトリビュートである、IrDA:IrLMP:LsapSel またはIrDA:TinyTP:LsapSel.を持たなければならない。IrLPT デバイスも同様に、クラス名IrLPT ,LSAP を示すセレクタアトリビュートであるIrDA:IrLMP:LsapSel を持つ。3-Wire、9-Wire デバイスのLSAP セレクタ用アトリビュートAttribute Name Value Type Description IrDA:TinyTP:LsapSel Integer(0x01)The IrLMP LSAP/TTPSAP of the TTP entity that provides access to the service being advertised Legal values are restricted to the range 0x01-0x6F.3-Wire-RawデバイスのLSAPセレクタ用アトリビュートAttribute Name Value Type Description IrDA:IrLMP:LsapSel Integer(0x01)The IrLMP LSAP of the service being advertised Legal values are restricted to the range 0x01-0x6F.IrLPTデバイスのLSAPセレクタ用アトリビュートAttribute Name Value Type Description IrDA:IrLMP:LsapSel Integer(0x01)The IrLMP LSAP of the service being advertised Legal values are restricted to the range 0x01-0x6F.Frame Formats 3-Wire (IrLPT) Raw のフレームフォーマット

IrCOMM のユーザデータは、IrLMP もしくはTinyTP パケットのユーザデータにぴったり

と収まるように構成されている。したがって、IrCOMM 規格はIrLAP の接続時に決定されるユーザデータサイズを把握する必要がある。IrLMP 上の3-Wire もしくはIrLPT の場合は、IrLAP データサイズから2（IrLMP の2 バイト）を減じたサイズがユーザデータサイズとなる。IrLAPmax - 2 bytes UserData Cooked (3-Wire and 9-Wire) のフレームフォーマット3-Wire および9-Wire モードのIrCOMM プロトコルを総称してCooked モードと呼んでいる。

これは、3-Wire-Raw とIrLPT のユーザデータが単純なデータである代わりに3-Wire、9-Wire では、ユーザデータの先頭には、モデム制御線の状態や、モデム動作変更を通知するコントロールデータが付加されているためである。3-Wire、9-Wire は、TinyTP 上で動作するが、TinyTP の提供する機能のうち、クレジットによるフロー制御のみを使用し、TinyTP も分割再構成機能は使用せず、単なるバイトストリームとして取り扱う。したがって、TinyTP の接続パラメータにおける最大データサイズは使用しないか0 とする（0 は分割再構成を行わないことを意味する）TinyTP を使用するIrCOMM のサービスデータ（SDU）は、先頭に、コントロールデータのバイト長、PI,PL,PV 形式のコントロールデータがあり、その背後にTD もしくはRD 信号で送受されるデータで構成されている。コントロールデータは、必ずIrLAP の１つのPDU に収まらなくてはならない。

また、複数の制御線通知を含むコントロールと複数の受送信データが１つのPDU に乗るために、データと制御線の時間的な順序関係は保証されないし、制御線のリアルタイム性も保証されないので、制御線をタイトに使用した応用にはIrCOMM のエミュレーションは適しないことがわかる。

IrCOMM 接続手順 ( 3-Wire or 9-Wire)

3-Wire-Raw、IrLPT では、接続時に交換される接続パラメータは、使用されないが、3-Wire、9-Wire の接続時には、IrCOMM における接続コントロールパラメータを交換する必要がある。そのひとつは、エミュレーションする、ポートのサービスタイプであり、もうひとつはエミュレーションに必要なモデム速度、データ構成、初期の制御線状態の通知である。エミュレーションサービスタイプの通知PI PI name PL PV data type PV Description PV Default value, notes 0x00 Service Type 1 Byte(bitmask)bit 0 bit 1 3-Wire raw 3-Wire default = highest order bit set in the IAS service type parameter Tiny TP UserData IrLAPmax-3 bytes 1 byte Clen=x Control Cvalue PI PL PV PI PL 1st Parameter(if present)2nd Parameter(if present)..........Length in Bytes:1 1 PL 1 byte x bytes PV bit 2 bit 3 9-Wire Centronics 0x01 Port Type 1 Byte(bitmask)bit 0 bit 1 Serial Parallel default = both setこのコントロールデータを交換することにより、要求するエミュレーションの種類を決定する。

▶1.5 if char len 5

Parity Enable 0 = no parity 1 = parity enabled Parity Type (if enabled)00 = odd 01 = even 10 = mark 11 = space 8 bits, 1 stop bit, no parity 0x13 XON/XOFF Flow control characters 2 byte sequence-XON character is first,followed by XOFF character characters used to represent XON/XOFF XON - 0x11 XOFF - 0x13 0x14 ENQ/ACK Flow control characters 2 byte sequence - ENQ character is first,followed by ACK character characters used to represent ENQ/ACK ENQ - 0x05 ACK - 0x06速度通知PI‘00’は、通信速度を通知する。この通信速度は、IrLAP の通信速度でなくIrCOMM でエミュレーションするTD,RD の回線速度を意味する。Type2 デバイスの場合は実際のRS232E コネクタのTD、RD の通信速度がこのコントロールで指定された通信速度となる。

ビットフォーマットPI‘11’は、TD,RD で使用するビットフォーマットを定義する。IrLAP では8 ビットのストリームデータを透過的に取り扱うが、IrCOMM の場合はこのパラメータに従う。Type2デバイスの場合は実際のRS232E コネクタのTD、RD のデータフォーマットがこのコントロールで指定されたデータフォーマットとなる。フロー制御文字PI‘13’、‘14’は、制御信号線を使用しないで、キャラクタによるフロー制御（XON/XOFF）

および、ACK/NACK 制御に使用されるキャラクタを定義している。デフォルトの値は、ASCII コードとなっている。IrCOMM をEBCDIC コードなどの非ASCII コードでキャラクタフロー制御を行いたい場合に変更する。9-Wire だけで使用される初期コントロールパラメータPI PI name PL PV data type PV Description PV Default value, notes 0x20 DTE Line Settings and Changes 1 Bit mask bit 0 bit 1 bit 2 bit 3 Delta DTR Delta RTS DTR State RTS State Delta 0 = circuit not changed 1 = circuit changed State 0 = state is low 1 = state is high 0x21 DCE Line Settings and Changes 1 Bit mask bit 0 bit 1 bit 2 bit 3 bit 4 bit 5 bit 6 bit 7 Delta CTS Delta DSR Delta RI Delta CD CTS State DSR State RI State CD State Delta 0 = circuit not changed 1 = circuit changed State 0 = state is low 1 = state is high 9-Wire エミュレーションだけで使用されるコントロールパラメータは、モデム制御線通知である。DTE からDTE に通知される、「DTR、RTS」の組と、DCE からDTE に通知される「CTS、DSR、RI およびCD」の組として、2 つの制御線状態通知コントロールがある。

上位のDELTA は、その信号線が変化したことを表し、状態変化があった場合に１になる。これらのこのパラメータは、接続した後のユーザデータに含まれるコントロールデータとしても使用され、現在の制御線状態を通知する。3-Wire、9-Wire のユーザデータに含まれるコントロールデータSend Break PI PI name PL PV data type PV Description PV Default value, notes 0x16 Break 1 Bit mask bit 0 Break 0 = Clear break 1 = Set break sender signals break state自局から送信されるRD もしくは、TD がブレーク状態になったことを通知するために使用するコントロールデータである。

9-wire のモデム信号線の通知Poll for Line Settings PI PI name PL PV data type PV Description PV Default value, notes 0x22 Poll for Line Settings 0 no data sender requests line settings and changes. Can be sent by either DTE or DCE.現在のモデム信号線状態をモニタする必要がある場合にこのコントロールを発行する。このコントロールを受信したDTE:は、DTE ステータス通知であるPI=20.のコントロールを返さなければならない。また、DCE の場合は、PI=21 を使用して状態通知を行う

IrCOMM の実装の留意点

IrCOMM をデバイスに実装する場合についてここで述べておくことにする。

IrLPT、3-Wire-Raw IrLPT、3-Wire-Raw モード接続は、接続が完了するとIrLMP のExclusive モードとなるため、非常に簡単な動作となる。接続が完了してしまえば、IrLMP、IrLAP のPDU は完全に同一のPDU 構成になるので、データ交換は簡単となる。留意点としては、TinyTPのフロー制御を使用することが出来ないので、装置内で受信に対するフロー制御を行う場合には、アプリケーションレベルでIrLAP、IrLMP に対して受信不可（RNR）状態に明示的に行わなくてはならない点であろう。

また、IrLPT は基本的にイニシエータからレスポンダに対する単方向のデータ転送しか行えないため、レスポンダであるプリンターデバイスからの状態通知（紙切れ、ジャミング等）が行えないので、これらの状況が発生した場合にどのような振る舞いをデバイスが行うのかを考慮する必要がある。3-Wire、9-Wire モード3-Wire、9-Wire のPDU は先頭にコントロール、その後ろに送受信データがある簡単な構造となっている。IrCOMM のPDU を受信した場合は、PDU の先頭にあるコントロールデータ長から、コントロール部分とそれに続く送受信データを簡単に分離することができる。

コントロールの構成は、PI、PL、PV 構成になっているので単純なループ処理でさまざまなコントロールを評価、処理することができる。まず、PI を評価し、コントロールのカテゴリを調べる。装置に実装されているPI と一致すれば、PL 長分のパラメータを取り出して処理する。未定義もしくは、装置に未実装なPI であれば、PL 長分スキップする。以上を先頭のコントロールバイト長分行えばよい。基本的に、残りの受信データは、そのまま処理すればよい。

一方送信の場合は、コントロールとデータを合成する処理に若干の注意点がある。

IrCOMM の3-Wire、9-Wire のPDU は、ひとつのPDU で完結していなければならない。

つまり、先頭にあるコントロールはPI、PL、PV の一組が必ずPDU に収まらなくてはならない。コントロールは種類によってデータサイズPV の長さが異なるため、複数のコントロールを含むPDU を構成する場合（イニシャルパラメータも同様）、LAP 接続時に交換される相手の受信可能最大データサイズに基づいて、コントロールとデータがPDU に収まるかPDU 送信前に常にチェックする必要がある。9-Wire の場合、複数の信号線コントロールと、データが存在するPDU については、前に述べたように、その時間的な順序関係は保証されない。したがって、明示的にコントロールとデータの順序関係を保証することが必要な場合は、コントロールのみのPDU とデータのみのPDU を作成し、必要な順序で送信を行わなくてはならないだろう。

制御線フロー制御とキャラクタフロー制御Type-2 装置のように実際のモデム等を赤外線経由で制御する場合、赤外線のデータ通信速度と、モデム-プロトコル間のデータ通信速度が異なる。通信速度の差があることを考えれば、何がしかのフロー制御を行わなくてはならないことになる。モデムなどのフロー制御はRTS/CTS などの制御線によりデータフロー制御をおこなうが、Type-2 装置の場合のケーブルエミュレーションを行う場合、ケーブルには存在しない

IrCOMM の特性について配慮する必要がある。

赤外線で転送されるデータは、すぐさまモデムのデータ線に到達するわけではなく、一旦プロトコルの持つバッファに蓄えられる。したがって、バッファの状況に応じてIrCOMM装置とモデム間にも独立のフロー制御が必要となる。したがって、IrCOMM のエンドポイントからコントロールとして通知される制御線制御と、ICOMM－モデム間のフローを複合的に処理し、モデムに対するフロー制御線を管理しなければならない。また、XON,XOFF、ACK、NACK などのキャラクタフローを使用している場合は、エンドポイントから送られるデータストリームに含まれるフロー制御文字をスキャンし、必要があれば削除を行い、ローカルフローが必要となれば挿入するなどの工夫が必要となる。

赤外線ターミナルアダプタIrTA

IrCOMM 規格のAnnex には、赤外線を使用したモデムやISDN－TA などの構成方法に

ついて説明がなされている。現在、NTT が設置しているISDN 公衆電話、携帯電話の赤外線対応などの赤外線ゲートウェイサービスは、このIrTA 規格に準拠している。IrTA の定義は、簡単に言えばType-2 デバイスの具体的な実装方法であると言える。IrTAの基本は、IrCOMM の３-wire 接続を使用して、ITU-T V.24 で規定している9-Wire インターフェイスを持つモデムなどのDCEについての接続に関するシステム構成を定義している。

(EP)From Endpoint EP ^ LF(LF)FromLocal Flow Local Queu Modem Flow Line IR-DTE(Type 1 device)IrTA( Type 2 device)DCE(ITU-T V.xx modem,etc)IR Wire(IrCOMM 3-wire service interface)(ITU-T V.24/9-wire interface)この図で示されるとおり、IrTA の定義範囲は、IrDA プロトコルとDCE の9 線インターフェイス間に挟まれたポートエミュレーションエンティティを指す。

IrTA への要求事項IrTA を実装するために、IrCOMM 規格、モデム制御等についていくつかの条件を規定している。以下がその条件である。１）IrTA は、IR-DTE 側がイニシエータ（起動側）として接続を行う。２）IrTA は、Modem とIrCOMM のサービスヒントを実装しなければならない。３）IrTA は、IrCOMM のコントロールにしたがわなければならない。また、IrTA 側の従来のアプリケーションPort Emulation Entity(for IrTA)

IrCOMM

Tiny TP IrLMP IrLAP SIR IrTA Service Entity (IrTA)(Proxy Server for handling DCE Service interface)

IrCOMM

Tiny TP IrLMP IrLAP SIR D C E IR cable(ITU-T V.24 Interface,9-wire)port interface(e.g. VCOMM)IrGW IrTA(IrTA D C E D T E ISDN/PSTN DTE(HOST)DCE cable(9-wire)(DTE)IR-DTE IrTA Specific Specification DCE Service IrLMP Service Interface IrCOM M Service IrDA Stack Service Interface(using on IrTA Specification)状態をIR-DTE 側にコントロールがわに通知する。

４）IrTA が、IR-DCE 側の要求を実行できない場合は、以前の設定を保持する必要がある。５）IrTA がIrCOMM 接続状態に推移した場合、DCE のデータ速度は9600bps、フロー制御は、RTS/CTS を使用するハードウェアフロー制御となる。それ以外のIrCOMMの設定値はIrCOMM のそれに従う。IrTA で使用するDCE への要求事項IrTA で使用されるモデムなどのDCE デバイスは、以下の条件をサポートしなければならない。

１）DCE は、データ転送速度として、300、600、1200、2400、4800、9600、19200bpsの転送速度をサポートしなければならず、データフォーマットとして、8N1、7E1、7O1、7N2（文字長、パリティ、ストップビット）をサポートしなければならない。２）DCE の持つIrTA とのインターフェイスは、GND、TD、RD、RTS、CTS、DSR、DTR、CD、RI のITU-T で定義された9 線インターフェイスを基本とする。

３）DCE は、DTR 信号ををON からOFF にすることにより、（PSTN/ISDN）回線の切断を実行することが出来なければならない。IrTA 内部での3-Wire 9-Witre 変換とその他の注意

IrCOMM 上でのデータフロー制御は、3-Wire モードを使用するため、TinyTP によるフ

ロー制御を使用している。しかし、IrTA とDCE 間のインターフェイスは9-Wire によるものである。DCE がハードウェアフローを使用する場合は、IrTA 内部のバッファがフルになるかTD の送信不可を示すCTS 信号がOFF になったところでTinyTP のクレジットを調整しIrTA 内部でTinyTP のフロー制御を実行する。また、DTE 側のTinyTP のクレジットによりフロー制御状態になった場合は、RTS 信号をOFF にすることでDCE からのRD データの送出を停止させる。

Windows95/98 などの赤外線仮想シリアルポートのエミュレーションは9-Wire のみをサポートするため、多くのIrTA は、3-Wire だけでなく9-Wire での接続を可能にするように設計されている場合も多い。

IrOBEX 規格

OBEX 規格の正式な名称は次のものである。

IrDA Object Exchange Protocol

IrOBEX

Ver 1.0 22 January,1997

IrOBEX は、簡単に言うと赤外線を使用したオブジェクト交換である。IrOBEX は、オ

ブジェクトをGET もしくは、PUT するという操作について定義している。

IrOBEX におけるオブジェクトとは何か

オブジェクトという概念は抽象的であり理解しにくいが、IrOBEX で交換されるオブジェクトは通常のリモートファイルシステムにおけるファイルと酷似している。簡単に理解するためには、オブジェクトという言葉をファイルと置き換えても大きな問題にはならない。オペレーティングシステムで使用されるファイルの概念は、そのファイルがプログラムであろうが、データであろうが、そのファイルを特定するための名前（パス名）、タイムスタンプなどを持ったデータ（オブジェクト）の塊であると理解することが出来る。

この範囲での概念では、ファイルを特定するためにファイル名を使用することになるがオブジェクトとしての概念ではさらにこの考え方を拡張する。拡張のし方は、IrOBEX を使用するアプリケーションによって決められるが具体的な例をIrMC におけるIrOBEX の使用方法の例を用いて説明することにしよう。

IrMC において、IrOBEX を使用して交換されるオブジェクトは、電話帳（Phone Book）、

カレンダ（ToDo Schedule）、メッセージ（messaging）などである。ここでは、IrMC 規格で取り扱われる電話帳についての具体例を説明する。IrMC の電話帳データは、/telecom/pbという名前によりデータ交換される。オブジェクト名が、/telecom/pb.vcf であると電話帳全体を取り扱う。一方、/telecom/pb/0.vcf という名前でオブジェクトを指定すると、電話帳のデータの0 番目データを指定したことになる。

通常のファイルシステムにおいて、/telecom/pb.vcf と、/telecom/pb/0.vcf は異なるファイルと考えられるが、IrMC での電話帳操作に使われる/telecom/pb.vcf は電話帳データ全体を示し、/telecom/pb/0.vcf は電話帳/telecom/pb.vcf の内部のレコード番号を指定したことになる。このように、IrOBEX を使用するアプリケーションにおいてオブジェクト名とオブジェクト操作が定義されている場合はその操作方法によりデータ（オブジェクト）の取り扱い方が異なるということに注意しよう。

この例を見てもわかることであるが、IrOBEX を使用するアプリケーションはアプリケーションで使用されるオブジェクトとオブジェクトの操作について何がしかの定義が必要となる。しかし、IrOBEX を単純なファイル交換として使用する場合はとくに定義は必要とされない。

IrOBEX においてGET とは、特定のオブジェクトをあいて装置から取り出す操作であり、

PUT 操作は特定のオブジェクトを相手の装置に送ることを意味している。オブジェクト名の命名規則はインターネットプロトコルであるHTTP におけるオブジェクトの命名規則に基づいているが、とくに複雑なファイルシステムを装置内に実装する必要はない。少なくとも装置で交換されるオブジェクト名を認識し、交換するオブジェクトデータを生成できればどのような実装でもかまわない。

IrOBEX のサービスヒント

IrOBEX を実装する装置はIrOBEX サービスを行うことを示すサービスヒントビットを立

てる必要がある。Byte 2 Bit Function 8 9 10 11 12 13

IrOBEX

14 15 IAS エントリ

IrOBEX デバイスのIAS エントリは、クラス名をOBEX とし、そのLSAP を示すセレクタ

アトリビュートである、IrDA:TinyTP:LsapSel.を持つ。

IrOBEX デバイスのLSAP セレクタ用アトリビュート

Attribute Name Value Type Description IrDA:TinyTP:LsapSel Integer(0x01)The IrLMP LSAP/TTPSAP of the TTP entity that provides access to the service being advertised Legal values are restricted to the range 0x01-0x6F.このことからわかるとおり、IrOBEX は、TinyTP のクライアントとして構成される。

IrOBEX とTinyTP のインターフェイス

IrOBEX では、TinyTP の分割再構成アルゴリズムを使用しない。したがって信頼性のあ

る接続経路、フロー制御とバイトデータストリームをIrDA プロトコルに要求しているに過ぎない。またOBEX で取り扱うPDU の境界と、TinyTP の取り扱うPDU の境界は一致していない。また、TinyTP で用意されている接続パラメータ、切断パラメータも使用されない。

IrOBEX のセッションモデルとセッションプロトコル

IrOBEX のセッションモデルは、クライアント／サーバーモデルを基本とし、クライア

ントが発行するリクエストに対してサーバーがレスポンスを行う形式になっている。

IrOBEX のセッションプロトコルは、クライアントの発行するひとつのリクエストに対し

てサーバーには必ずひとつの応答を行う単純な形式である。したがって、PDU を常に交互に交換するACK/NACK 形式のプロトコルである。

IrOBEX のPDU フォーマット

IrOBEX で使用されるPDU は、リクエストPDU とレスポンスPDU である。IrOBEX

では、PDU という表現は用いずにパケットフォーマットという呼び方をしている。要求パケットフォーマット0 バイト目1、2 バイト目それ以降のバイトオペコードパケット長ヘッダーまたは要求データ0 バイト目は、要求内容を示すオペレーションコードが格納されており、接続要求、切断要求、GET 要求、PUT 要求などの要求の種類を表す。１，２バイト目は以降に続くヘッダーもしくは要求データの長さを表し、先頭のバイトが上位、それに続くバイトが下位の16ビットのデータ長を示している。

応答パケットフォーマット0 バイト目1、2 バイト目それ以降のバイト応答コード応答長応答データ0 バイト目は、応答内容を示すコードが格納されており、成功、不正要求、などの要求に対する結果を示している。１，２バイト目は以降に続く応答データの長さを表し、先頭のバイトが上位、それに続くバイトが下位の16 ビットのデータ長を示している。

IrOBEX のオペコード

IrOBEX で使用されるオペコードは次のように規定される。

オペコードオペコードの定義処理の概要0x80接続要求(Connect)

IrOBEX の接続と能力の交換

0x81切断要求(Disconnect)

IrOBEX セッションの終了

0x02(0x82)PUT 要求オブジェクトの送信0x03(0x83)GET 要求オブジェクトの取得0x85パス設定要求カレントパスの変更0xFF中断（Abort）現在の処理を中断するオペコードのうち、最上位ビット（0ｘ80）は、そのリクエストが、そのパケットをもって終結することを意味する。PUT 要求、GET 要求など複数のパケットに分割されうるリクエストの場合、最後のパケットにおいて最上位ビットがON になる。また5、6 ビットは予約されており常に0 である。

IrOBEX の応答コード

IrOBEX で使用される応答コードはHTTP のステータスコードと対応しており、かなり

の種類があるがよく使用される応答コードについて抜粋して掲載しておく。応答コード応答コードの定義処理の概要0x10(0x90)処理の継続(Continue)分割された要求を継続する0x20(0xA0)OK、成功(Ok,Success)処理の成功0x40(0xC0)要求不可(Bad Request)不明な要求0x41(0xC1)要求拒絶(Unauthorized)要求が承認されない0x44(0xC4)発見できず(Not Found)オブジェクトが見つからない0x60(0xE0)サーバ内部エラーサーバー側でエラーが発生した応答コードのうち、最上位ビット（0ｘ80）は、その応答が、そのパケットをもって終結することを意味する。

接続手順接続時に交換されるIrOBEX パケットは次のような形式である。

IrOBEX 接続要求

0 バイト目1,2 バイト目3 バイト目4 バイト目5,6 バイト目7 バイト以降Connect Packet Size OBEX Version flags Max packet Optional 0x80 0xnn,0xnn 0x10 0x00 0xmmmm…..1 バイト目は接続要求を表すオペコード0ｘ00 であり1 パケットで完結するため、最上位ビットがセットされている。引き続く２バイトは継続するパケットのサイズを表わす。

３バイト目はIrOBEX のバージョンを表すが現在のバージョンは0x10 である。続く4 バイト目は、現在使用されていないが接続に関するフラグとして予約されており、0ｘ00 とする。5、6 バイト目は、自局の受信可能なIrOBEX の最大パケットサイズを表す。

IrOBEX 接続応答

0 バイト目1,2 バイト目3 バイト目4 バイト目5,6 バイト目7 バイト以降応答コード Packet Size OBEX Version flags Max packet Optional 0xA0(成功) 0xnn,0xnn 0x10 0x00 0xmmmm…..0x41(拒否)1 バイト目は接続要求に対する応答コードであり1 パケットで完結するため、最上位ビットがセットされている。接続が許可されれば応答コードは0xA0 になる。許可しない場合は、その理由を示す応答コードを使用する。続く２バイトは継続するパケットのサイズを表わす。３バイト目はIrOBEX のバージョンを表すが現在のバージョンは0x10 である。続く4バイト目は、現在使用されていないが接続に関するフラグとして予約されており、0ｘ00とする。5、6 バイト目は、自局の受信可能なIrOBEX の最大パケットサイズを表す。

この接続要求、応答はTinyTP の接続時に交換されるパラメータではない。基本的にTinyTP 接続の最初のデータに含まれる。切断手順切断要求は、切断オペコードと、成功応答コードの交換により構成される

IrOBEX 切断要求

0 バイト目1、2 バイト目３バイト以降0x81(Disconnect)Packet Size Optional Headers

IrOBEX 切断応答

0 バイト目1、2 バイト目３バイト以降0xA0(成功)Packet Size Optional Headers

IrOBEX では切断要求を定義しているが、実装によっては下位のTinyTP を切断して終了

する実装も容認している。OBEX ヘッダー

IrOBEX においてGET、PUT などを行う場合、オブジェクト名や、オブジェクトデータ

長、オブジェクト本体、オブジェクト作成日時などを交換する必要があるが、これらのオブジェクトの中身を表現するのに使用されるのがOBEX ヘッダーである。ヘッダび構成はヘッダ識別子（Header ID）1 バイトと、ヘッダーの値 (Header Value)荷より構成される。ヘッダ識別子の上位１ビットはヘッダーの値の構成を示している。7 6 5 4 3 2 1 0データ構造0 0 X X X X X X Null で終わるUnicode 文字 2byte len 0 1 X X X X X X２byte の長さとバイトストリーム1 0 X X X X X X 1 バイトのみの値1 1 X X X X X X４バイトの値OBEX ヘッダーの種類は以下のものである。

Header ID Header 名称ヘッダの意味0xC0カウント(Count)接続時にオブジェクトの数を指定する0x01名称(Name)オブジェクト名称0x42種類(Type)テキスト、バイナリなどの区分0xC3長さ(Length)オブジェクトのバイト長0x44日付(Time)ISO8601 フォーマット0xC4日付(Time)4 バイトフォーマット0x48 0x49本体継続(Body)本体終了(End of Body)オブジェクト本体(body)の部分オブジェクト本体(body)の最後オブジェクトの交換PUT 操作、GET 操作の基本動作IrBOEX の操作の中心となるのが、このオブジェクトの交換操作である。PUT 操作は、クライアントから、サーバーにオブジェクトを送付し、GET 操作は、サーバーからクライアントにオブジェクトを送付する。IrOBEX のPDU サイズは、IrOBEX の接続時もしくは、デフォルト（２５６バイト）であるので交換されるオブジェクトやファイルのサイズは通常それよりも大きい。したがって、オブジェクトの分割再構成が必要となる。IrOBEX 規格書には明確に述べられていないが、接続PDU がこなくてもいきなり、PUT やGET のPDU が交換される場合も想定する必要がある。その場合は、デフォルトのPDU サイズを使用することになる。

交換されるオペコードの構成

IrOBEX のオペコードレベルの解釈して、GET、PUT 操作を分割して行う場合、操作を

起動側するクライアントは、連続したGET またはPUT オペコードを伴ったPDU をサーバー側に送付する。また、PUT の場合、操作終了の最後のPDU を送信する場合は、ファイナルビットを立てる。GET の場合は、操作がサーバー側でつねに終了できるように、すべてのPUT オペコードにはファイナルビットが立てられる。応答側であるサーバーは、GET または、PUT の最初のPDU を受け取るとその操作が許されるかどうか評価し、受け入れることが出来る場合は、ファイナルビットを伴った、処理の継続(Continue)オペコードで応答する。GET の場合は、長さ（Length）、日付（Time）

などのOBEX ヘッダとデータ本体（body）を応答PDU に乗せる。それ以外は、該当するエラーレスポンスを使用して応答する。サーバー側はPUT/GET PDU を受信するごとに処理(ファイルのリード/ライトなど)を行い、操作結果が成功すれば、処理継続を示す(Continue)オペコードで応答する。 PUT の場合、End-Of-Body を含むPDU を受信した場合、もしくは、GET の場合、最後のEnd-Of-Body を含むPDU を送信する場合には、全体の処理が成功した場合のみ成功(Ok,Success)を使用して処理を完了する。

また、オペコードに付加されるファイナルビットは、PUT の起動するクライアント側が単一のオブジェクト操作を完了するPDU において使用し、サーバー側は応答パケットでは常にファイナルビットがセットされる。GET 操作の場合は、つねに起動側であるクライアントのPDU と、サーバーでである応答側のPDU のファイナルビットが常にセットされる。実は、IrOBEX1.0 規格ではPUT/GET 操作におけるファイナルビットの取り扱いについて、明確に述べられていないが次の規格の段階である程度明確になるであろう。

PUT/GET 操作における、無難な解釈としては、PUT 操作の場合のみ、起動側がその操作の単位ごとにファイナルビットを立てるようにし、それ以外の操作ではつねにファイナルビットを立てておくという構成にしておくべきである。OBEX ヘッダとオブジェクト本体の分割最初に転送されるPDU には、操作対象となるオブジェクトを示す名称（Name）OBEXヘッダが含まれる。またオブジェクト送信元からは長さ（Length）、日付（Time）などのOBEX ヘッダが追加される場合もある。また、最初のPDU の残り部分には、本体（Body）

を含んでもよい。

IrOBEX で分割再構成される部分は、オブジェクト本体をあらわす本体（Body）部分で

ある。オブジェクトを送信する側は、複数のPDU に分割されるオブジェクトについて、本体が引き続き継続されて送付されることを示すOBEX ヘッダー（0x48:Body）と、本体がこのPDU で終了することを示すOBEX ヘッダー(0x49:End-Of-Body)を使用してで分割して送信する。オブジェクトを受信する側のPDU には、オペコードのみが存在し、OBEX ヘッダーは含まれない。受信する側は受信したオブジェクトの分割単位での処理状態をオペコードを使用して通知するだけである。

IrOBEX に関する注意事項

IrOBEX プロトコルは、インターネットプロトコルのひとつであるHTTP のサブセット

をバイナリ－化したものであり、他のプロトコルと異なり、明確なユーザサービスであるとか、ステートダイアグラムなどの記述がなく、IrBOEX が参照している規格に頼っている部分が多く見分けられる。IrOBEX 規格1.1 が1999 年4 月のIrDA 総会に提案されることになっているのでどこまで自己完結されるのか待ちたいところである。

IrOBEX 規格1.1 では、接続時の認証であるとか、相手のオブジェクト（ファイル）構成

を照会する手順なども追加される予定になっている。PUT 操作の具体例アプリケーションが、PUT 操作をすることを想定する。オブジェクトは2000 バイトでオブジェクト名は、“/Telecom/pb.vcf”であり、タイムスタンプは(Mar 30, 1999, 12:00:00 UTC). とし、パケットサイズは512 バイトとしよう.OpCode/Resp(HEX)OBEX ヘッダ-(HEX)Final Bitヘッダの内容ヘッダ長交換されるデータバイト数要求PUT（02）

無01 Name“/Telecom/pb.vcf”35 C3 Length“2000”5 44 Time“19990330T120000Z”19応答CONTINUE(90）有ヘッダなし要求PUT(02)無48 Body Top of body data 509 506 bytes応答CONTINUE(90)有ヘッダなし要求PUT(02)無48 Body Next body data 509 1012 bytes応答CONTINUE(90)有ヘッダなし要求PUT(02)無48 Body Next body data 509 1518 bytes応答CONTINUE(90)有ヘッダなし要求PUT(02)無48 Body Last body data 485 2000 bytes応答CONTINUE(90)有ヘッダなし要求PUT(82)有49 E-O-Body Empty body 3 2000 bytes応答SUCCESS(A0)有ヘッダなしGET 操作の具体例PUT 操作と同様のオブジェクトを今度はGET 操作で取得する場合の具体例を見てみよう。

OpCode/Resp(HEX)OBEX ヘッダ-(HEX)Final Bitヘッダの内容ヘッダ長交換されるデータバイト数要求GET(83)有01 Name“Test File Object”37応答CONTINUE(90)有C3 Length“2000”44 Time“19990330T120000Z”48 Body Top of body data 499 496 bytes要求GET(83)有ヘッダなし応答CONTINUE(90)有48 Body Next body data 509 1002 bytes要求GET(83)有ヘッダなし応答CONTINUE(90)有48 Body Next body data 509 1508 bytes要求GET(83)有ヘッダなし応答SUCCESS(A0)有49 End-Of-Body Last body data 495 2000 bytes

IrOBEX 規格のまとめ

IrOBEX 規格は、IrDA の規格として規格化されているが、プロトコルの内容を見るとわ

かるように、下位層のプロトコルであるTinyTP のサービスにおけるフロー制御と、データ交換、IAS のLSAP エントリのみを使用しているため、IrDA のサービスと密結合しているわけではない。したがって、信頼性があり、フロー制御可能なIrDA 以外のプロトコルを下位層に持ってきてもIrOBEX は動作する。最近Blue Tooth などの赤外線通信以外の無線通信でも、IrOBEX を使用してデータを交換するという動きがある。

携帯電話の赤外線通信規格であるIrMC などでも電話帳、スケジュール、メッセージの交換などに広く活用されている。また、Windows 98 では、IrOBEX の規格に準拠したIrXferも採用されている（ただしIAS エントリが異なる）。米国で発売されている Palm Pilot や、IBM から発売されているWork Pad などのPIM のデータ交換にもIrOBEX が使用されている。IrOBEX Ver 1.0 では、その記述にあいまいな点が多く含まれているため、実装レベルでの互換性が問題となっているが、IrDA のIrOBEX テストガイドラインも1999 年中には整備されるため相互接続性の問題もクリアされるであろう。

NDM ブロードキャストを使用したUltra プロトコル規格IrDA 規格は、コネクション型（CO 型）を中心に議論され、信用のあるデータ通信経路のうえにさまざまなプロトコルを構築する形で新化してきたといってもよいだろう。しかし、通信の信頼性を得るためにはさまざまエラー検出の手順が必要となるために、ある程度の能力を持ったCPU が必要となる。しかし、IrDA の物理層は比較的安価に構築することができるために、高度なプロトコルを処理することが出来ないCPU を持った装置などにも物理層レベルでの採用した装置も現れるようになった。たとえば、4 ビット程度のCPUしか持たないポケットベル、簡易なデータ端末、時計、ゲームなどでがある。しかし、IrDA規格では、IrLAP、IrLMP を搭載することが必須条件とされているために、IrDA 物理層だけを搭載している装置の通信プロトコルはまちまちで統一されていなかった。

IrDA 内部でも、ポケットベルや携帯電話メーカから、このような不統一を解決できるプロトコルで、なおかつ従来のIrLAP、IrLMP と互換性のある方式を模索する動きが、携帯電話SIG 活発になり、IrMC 規格を制定するグループ内で討議された結果がこのUltra プロトコルである。

Ultra プロトコルは、独立した規格というよりもガイドラインとして用意されている。

IrDA の位置付けとしては、IrMC 規格の補助的なガイドラインとして、IrMC 規格とセットで現在IrDA から公開されている。規格書として独立していて、Infrared Data Association Guidelines for Ultra Protocols Version 1.0 October 15, 1997というタイトルを持つ。現在Ultra プロトコルの上位層としては、コネクションレス型のIrOBEX 規格であるUltra OBEX という規格が定義されており、IrMC 規格で活用されておいる。現在、赤外線通信を使用した腕時計の規格であるIrWW を討議しているIrDAのSIG でもUltra プロトコルを使用した時刻あわせのプロトコルなどを討議している。

Ultra プロトコルの構成

Ultra プロトコルで定義しているプロトコルは、基本的にコネクションレス型（CL 型）

の単方向プロトコルである。IrLAP、IrLMP では、コネクションレス型（CL 型）のデータ通信について定義されており、このPDU を使用して単方向のプロトコルを実現しようという構成になっている。この図は、IrLAP、IrLMP のNDM（正規切断モード）で転送できるコネクションレス型のデータフレームの構成、Ultra プロトコルで追加したPDU を示している。１）IrLAP 層IrLAP で定義される基本的なフレーム構成はBOF、アドレス、コマンド/レスポンス、ユーザデータ、FCS、EOF の各フレーム構成要素はそのまま使用する。

接続が行われていない状態（NDM）の状態でIrDA 装置同士のIrLAP の上位層が交換できるデータフレームは、同報アドレス（X‘FF）をもち、非番号制データ（UI）で構成されるフレームだけである。ネットワークでは、同報フレームとばれるが、このフレームを受信し、FCS が正しければIrLAP は上位層に対して、コネクションレス型のデータ到来の指示（Indication）サービスプリミティブを発行する。

２）IrLMP 層IrLMP のコネクション型のLSAP は、X’00 からX’6F までであり、X’70 のLSAPはコネクションレス型（CL 型）に予約されている。IrLMP の上位層で、このX’70のLSAP を取得している場合は、そのIrLMP クライアントにコネクションレス型のデータ到来の指示（Indication）サービスプリミティブが通知される。IrLMP のレベルでは、宛先LSAP（DLSAP）、発信元LSAP（SLSAP）がともにX70 になっていれば、問題なく上位層に通知することが出来る。

３）Ultra 層その上位にUltra プロトコルが構成される。IrLAP、IrLMP を透過して、NDM時の同報UI フレームはそのままUltra プロトコルに通知される。...FCS EOF XBOF BOF Framing 0xFF"UI"Framing...IrLAP Frame Payload Data IrLMP Frame Payload Data Service Data 0x70 0x70 C A DLSAP SLSAP 1)2)Protocol Data PID 3)

Ultra プロトコルのPDU 構成

PID プロトコル識別子

Ultra プロトコルを使用する上位層のプロトコルを示すために、Ultra PDU の

先頭１バイトが使用される。現在、ビット０がUltra OBEX のために使用されている。今後複数の上位プロトコルが定義されるとPID の各ビットがIrDA の承認の元に割り当てられる。PID の最上位は拡張ビットで、そのビットが立っていれば次の１バイトもPID である。この拡張方法は、IrLMP のサービスヒントと同様である。PID Octet Bit Function 0 Protocol ID bit 0 1 Protocol ID bit 1 2 Protocol ID bit 2 3 Protocol ID bit 3 4 Protocol ID bit 4 5 Protocol ID bit 5 6 Protocol ID bit 6 7 Extension分割再構成（SAR）

IrLAP 規格でNDM 状態にある局は、デフォルトのIrLAP QOS(通信品質)の状態になっている。つまり、通信速度9600bps、受信可能フレームサイズ64 バイト、ウインドウサイズ1、ミニマムターンアラウンドタイム20ms、追加のBOF は10バイトである。通信速度の問題を除くと、Ultra プロトコルの１つのPDU で送信できるデータサイズは高々60 バイト程度になってしまう。Ultra OBEX で取り扱うデータではサイズが小さすぎる。そこで、連続したUltraPDU を連結できるように、PID のつぎに分割再構成の連続番号を持つ１バイトのSAR 部（Segmentation and Re-assembly ）を付加している。

SAR Octet Bit Function 0 Bit 0 of current segment index 1 Bit 1 of current segment index 2 Bit 2 of current segment index 3 Bit 3 of current segment index 4 Bit 0 of final segment index 5 Bit 1 of final segment index 6 Bit 2 of final segment index 7 Bit 3 of final segment index SAR バイトの上位４ビットは、分割されて送られるシーケンス番号の最後の番号をもっている。使用できる値は、0 から14 までで、15 は予約されている。したがって、分割再構成によって転送できる最大バイト数はIrLAP SDU (64) – IrLMP PCI(2) – Ultra PCI(2) = 60 バイト× 15 = 900 バイトという計算になる。

下位の４ビットは分割されたデータのシーケンス番号であり、0 から始まり、上位４ビットのシーケンス番号までPDU ごとに１づつ増加する。これによりデータ抜けを検出出来る。メディアアクセスルールNDM 時のQOS もそうであるが、IrLAP 規格でのNDM 時のメディアアクセスルールにも当然適合していなければならない。IrLAP のMAC 層のルールとしては、データの送信権を得るためには、他の赤外線通信が0.5 秒以上ないことを確認しなければならない。したがって、データ送信をする場合もこのアクセスルールに従う必要がある。しかし、64 バイトごとに0.5 秒待つ必要があるので、あまり効率がいいとはいえない。900 バイトのデータを送るために必要な時間は、(500ms + 80ms) * 15 = 8.7 秒900[バイト] ／ 8.7 [秒] = 103[バイト／秒]であり、正味のビットレートは約1000bps 程度となる。

SAR [0/2]Media Sense Period SAR [1/2]Media Sense Period SAR [2/2]Media Sense Period 500 ms 500 ms 500 ms IrLAP、IrLMP を実装しない場合のUltra の応用

Ultra プロトコルで使用するIrLAP の同報アドレス、UI、そしてIrLMP のDLSAP、SLAP

はあくまでも既存のプロトコルに矛盾しないためのものである。また、この部分は、IrLAP、IrLMP を考えなければ４バイトの固定データであると考えてもよい。したがって、IrLAP、IrLMP プロトコルを持っていない装置であっても、少なくとも、次の要素を持っていれば

Ultra プロトコルを使用して、IrDA 規格を持つ装置とデータの交換が出来る。

１）9600bpsFCS を含めたIrSIR レベルのフレームを送信、受信出来ること。２）赤外線のアクティビティを検出できること。３）分割再構成に必要なメモリが用意できること。４）0.5 秒の時間計測が出来ること。この要素のうち、もっとも複雑なのはFCS の計算であるが、連続したデータは0.5 秒以内に続きのデータが送られてこないことを考えれば、かなりのローエンドのCPU であっても処理時間的な問題はないと考えられる。

Ultra プロトコルのまとめ

Ultra プロトコル規格書の本文のページ数は６ページ程度であるが、その中にはIrLAP、

IrLMP との整合性のとりかた、そして複数の上位層が存在する場合の配慮、実用的なデータ通信を保証するための分割再構成についての要素など関連するプロトコルを熟知していないと考えることが出来ないプロトコルであるとも言える。読者の中では、IrLAP、IrLMP との整合性のために16 バイト程度のオーバーヘッドがあることを気にする方もおられるだろうし、0.5 秒待つことにも抵抗があると思う。しかし、すでに存在するIrDA 規格と共存しなおかつ、すでにあるIrDA 装置と通信できることが重要であるともいえる。既存のIrDA 装置は、最小の変更でUltra プロトコルを実装することが出来るし、IrLAP、IrLMP を持ち合わせない装置であっても、先ほど述べた程度の能力でUltra プロトコルを実装することが出来るわけであり、これは十分に利用価値のあるものと筆者は考える。

IrDA Lite 規格（IrDA 規格の最小の実装方法）

IrDA 規格の根幹を成すIrLAP、IrLMP 規格はきわめて大きい規格であり、オプション規格を除いたとしてもかなり大きなボリュームである。PC やPDA などCPU パワーもメモリも比較的余裕のあるシステムであれば問題にならないが、コストの厳しい情報家電関連の通信用途を考えるとIrDA で採用した規格の大きさが問題となってきている。

IrDA Lite 規格は、規格というよりもむしろ、IrLAP、IrLMP 規格に定義された必須の

サービスプリミティブやステートなどを見直して、効率よりもコードサイズ、メモリサイズが最小にしつつも従来のIrDA 規格と互換性の取れる最小の実装方法はどのようにすればいいかを定義したガイドラインである。規格書のタイトルはInfrared Data Association Minimal IrDA Protocol Implementation (IrDA Lite)Version 1.0 November 7, 1996となっており、IrDA Lite が独立したIrDA の規格でないことがわかる。予断であるが、プロトコルのネーミングがまさにアメリカ的であり、前章のUltra 規格、そしてこのLite規格も名は体を表さない類のものである。そのために、IrDA の外部からはLite やUltraはIrLAP やIrLMP に代わるまったく別立てのプロトコルであると誤解を招いたこともある。IrDA Lite 規格のコードサイズと実際のフル実装のコードサイズを比較すると、1/3 程度で実装できる。16 ビットクラスのCPU であれば10K バイト程度のサイズになるであろう。

プロトコル最小化のアイデア最小の実装方法といっても、実際のデータ交換で不備があると困るのはいうまでもない。

IrDA Lite での最小化のアイデアは、データ交換に関連しない項目や、IrLAP 接続時の折

衝パラメータの解釈や副次的な機能の削除、IrLMP のマルチプレクサの振るまいの最小化、IAS サービスの最小化などに主眼を置きプロトコル処理を出来るだけ簡単にするようにしている。IrLAP 層のNDM 状態における最小化のアイデアNDM つまりは、IrLAP が接続されておらず、すべてのIrDA 装置が競合状態の場合に交換できるフレームや情報についての最小化を見ていくことにしよう。1スニッフィング、CL 型UI フレームTEST フレームをサポートしない。

2同報アドレスを持たないフレームは無視する。3 XID、SNRM、UA 以外のすべてのフレームは無視し、DM 応答も返さない。4ディスカバリ時に受信したニックネームをメモリに保存しない。5ディスカバリ応答のときにニックネームを送信しない。この項目のうち、1-3 までの項目は、接続、ディスカバリの２つの要素に直接関係しない処理要素について規定している。また、4、5 はメモリを節約するためのものである。IrLAP 層のNRM 状態における最小化のアイデアNRM つまりは、接続したのちの状態での要求される能力である。

1デフォルトの折衝パラメータを使用するBaud rate 9600 bps Data Size 64 bytes Window size 1 Additional BOFs 0 Max Turn around time 500ms Disconnect/Threshold time 3 secondsミニマムターンアラウンドタイムも常に10ms とし、追加のBOF 数もNDM 時の状態と同じ11 個のBOF を追加する。

2このようにすれば、折衝パラメータを参照しなくてもよくなる。ミニマムターンアラウンドタイムは最小のターンアラウンド時間であるし、追加BOF 数も最小のBOF 数であり、最大許されるパラメータで相手にデータを送ることは、効率以外問題にならない。3 NRM においては、同報アドレスを含むいかなるフレームも無視する。4監視フレーム（S）、情報フレーム（I）のN(s)のチェックを行わない。5 RESET 状態をサポートせず、切断するように振舞う6非番号フレーム（U）について、XID、UI またはそれ以外のいかなる未定義のフレームは無視する。（P/F ビットを送信する場合は監視フレーム（S）、情報フレーム（I）を使用する）

折衝パラメータは、交換してもデフォルトの動作になるようにすること、ウインドウサイズ1 にすることで、N(r)、N(s)の管理を簡単にしてしまうという目論見とともに、通常起こりにくいリセットや、接続中の再折衝などをすべて除くことで処理を少なくしている。IrLAP 層の二次局の最小化

IrDA Lite で定義する二次局の能力は次のように規定される。

二次局のみのガイドラインとアイデア1 Lite 規格の二次局はREPLY ステートや、ディスカバリに必要なquery timer も使用しない。これは、まれに起こることのあるディスカバリスロットの抜けを検出するための、簡単な方法でとして、ディスカバリ手順の開始/終了を処理する。2 Lite 規格の二次局は、ディスカバリ指示のプリミティブを生成しない3 Lite 規格の二次局は、P ビット（ポールビット）がクリアされているコマンドを無視する。これは、折衝時にウインドウサイズが１に指定されているため、一次局が（I）フレーム送信する場合にP ビットがたつはずであるし、シーケンスチェックで検出される。このことにより、二次局は、受信時に１つだけのフレームを受信できるだけでよくなる。

4 Lite 規格の二次局は、受信するすべてのレスポンスフレームを無視する。それらのフレームは他の接続を意味している。5 Lite 規格の二次局は、接続状態においてSNRM（リセット）を無視するためにDM（切断要求）を使用しない。二次局のみのサービスプリミティブ接続サービスl IrLAP_CONNECT.指示()l IrLAP_CONNECT.応答()データ交換サービスl IrLAP_DATA.要求(User-Data)l IrLAP_DATA.指示 (User-Data)切断サービスl IrLAP_DISCONNECT.要求 ()l IrLAP_DISCONNECT.指示()IrLAP 層の一次局の最小化ここでは、IrDA Lite の一次局の能力規定についてみて行く事にしよう。

1 Lite 規格でディスカバリを発行するイニシエータは、ディスカバリ、アドレス衝突解決手順をを使用する。2 Lite 規格でディスカバリを発行するイニシエータは、６スロットまでのディスカバリ操作を行う。3 Lite 規格の一次局は、一度だけの接続を試みる。その試みに対してUA レスポンスがないならば、接続は失敗する。たとえば、SNRM の衝突や、メディアビジー状態のときなどが考えられる。4 Lite 規格の一次局は、SETUP 状態のとき、UA もしくはF-Timer がタイムアウトすることだけを監視している。そしてそれ以外のどんなフレームも無視する。したがって、DM や、DISC コマンドを受け取ってもF-Timerがタイムアウトするのと動作は同じである。

5 Lite 規格の一次局は、F-ビット（ファイナルビット）がクリアされているレスポンスを無視する。また、常に送信するコマンドにはP-ビット（ポールビット）が立てられる。Lite 規格の一次局は、接続時の折衝でウインドウサイズは１になっているので、二次局は、I-フレームにF ビットを必ず立てるし、シーケンスチェックで検出される。このことにより、受信時に１つだけのフレームを受信できるだけでよくなる。一次局のサービスプリミティブディスカバリとアドレス衝突解決サービスl IrLAP_DISCOVERY.要求 (GenAddrBit)l IrLAP_DISCOVERY.確認 (List-of-Discovery-Logs)接続サービスl IrLAP_CONNECT.要求 (Target-Device-Address)l IrLAP_CONNECT.確認 ()データ交換サービスl IrLAP_DATA.request (User-Data)l IrLAP_DATA.indication (User-Data)切断サービスl IrLAP_DISCONNECT.request()l IrLAP_DISCONNECT.indication()最小のIrLMP のマルチプレクサ能力前節では、IrLAP 層での最小化の方法を調べたが、IrDA Lite においてIrLMP をどのように最小化するのか見ていくことにする。

基本的なIrLMP マルチプレクサの最小化のアイデア1 IrDA 接続時に、IAS 以外の１だけのアプリケーションだけがIrLMP 接続として存在する。2

IrDA Lite の一次局は、ポイント-マルチポイントをサポートしない。し

たがってIrLAP 接続は一度に１つの接続のみをサポートするだけである。3接続は、ひとつのアプリケーションに限られるため、IrLMP の切断はIrLAP の切断に置きかえることが出来る。仮に、IAS サーバー、IAS クライアント、アプリケーションの３との接続があったとしても次のようなシナリオの場合、IrLMP切断をIrLAP切断に置きかえることが出来る。l IrLMP 接続を行っているアプリケーションが切断する。

l切断したもしくは、存在しないLSAP 接続の接続確認LM-PDU を受信した。l切断したもしくは、存在しないLSAP 接続の接続要求LM-PDU を受信した。l切断したもしくは、存在しないLSAP 接続のデータ指示LM-PDU を受信した。l存在するLSAP 接続の接続要求LM-PDU を受信した。(half open)4

IrDA Lite は、排他的なモードをサポートしない。そして、IAS の“Device”

オブジェクトの中で、これらのオプション機能がサポートされていないことを示すように構成される。アクセスモード変更LM-PDU が受信された場合は、IrDA Lite はIrLAP 切断を実行する。このことは、排他的モードを使用する実装のにおいて問題を引き起こすことがある。つまり、他のデバイスがアクセスモード変更コマンドを発行する前にオプションの排他的なモード能力をサポートすることを確認するためにIAS の問い合わせを行う必要がある。

5 IrLMP 規格では、接続要求、接続確認、データ指示などのLM-MUX コマンドPDU が表されている。また、存在しないLSAP 接続に送られる切断PDU は無視される。IrDA Lite は、アクセスモードPDU を受け取ったり、存在しないLSAP に切断要求が発行されると、すぐに切断する。標準のIrLMP の振舞いと唯一異なるのは、切断PDU を受け取るとすぐに切断することである。6 Lite 規格のIrLMP ステートマシンを単純化するため、IrLMP の切断は、IrLAP の切断に置きかえられる。また、IrLAP の接続、切断プリミティブは、IrLMP のサービスユーザに公開される。通常、標準の規格では、ステーション管理として、IrLAP 接続切断はすべてIrLMP によって管理されるが、IrDA Lite 規格では、IrLAP の接続をアプリケーションが明示的に行う。

IrLMP のサービスプリミティブディスカバリサービスl LM_Discovery.要求()l LM_Discovery.確認(DeviceInfoList)リンクコネクトサービスl LM_LinkConnect.要求(Target-Device-Address)l LM_LinkConnect.指示()l LM_LinkConnect.確認()このプリミティブは、IrLMP 層から、IrLAP 層の接続管理を明示的に行うためのものである。したがって、標準のIrLMP にはないプリミティブである。

接続サービスl LM_Connect.要求(Called LSAP, Client Data)l LM_Connect.指示(Calling LSAP, Client Data)l LM_Connect.応答(Calling LSAP, Client Data)l LM_Connect.確認(Called LSAP, Client Data)切断サービスl LM_LinkDisconnect.要求()l LM_LinkDisconnect.指示()l LM_Disconnect.指示()このプリミティブのうち、LM_LinkDisconnect はIrLAP 層の切断接続管理を明示的に行うためのものである。したがって、標準のIrLMP にはないプリミティブである。

データ交換サービスl LM_Data.request(Data)l LM_Data.indication(Data)最小のIrLMP IAS 機能さて、IrDA Lite の最後の項目として、最小のIAS の構成について調べてみることにしよう。

同じ名称を持つIAS データベースには、複数のオブジェクトを持つことがない。通常、複数のオブジェクトが登録されても意味をなさない場合が多いためである。

IAS オブジェクトを構成する場合、唯一必要とされる属性（アトリビュート）は、LSAPセレクタ値を特定するためのものである。

GetValueByClass の問い合わせのIAS オブジェクトや属性の応答をIrLMP の64 バイトのパケットに収めることは可能である。

複数のパケットに分割されるIAS オブジェクト無視する。上のガイドラインに従うなら、典型的なIAS 問合せは一つのパケットの交換ですむ。そして、IAS の問合せ自体は、要求されたアプリケーションがサービスのLSAP セレクタ値を得るために、GetValueByClass 問合せをおこなうだけで、たかだか一つのパケットの交換だけである。この場合、その結果は、整数4 バイトの結果を含んでいるパケットとなる。

IrDA Lite 規格のまとめ

IrDA Lite 規格について、そのアイデアと骨子を述べたが、このガイドラインはあくまで

も「ここまで機能を落としても、従来のIrDA 規格の装置と接続が可能である」と解釈すべきであろう。IrDA Lite 規格ではかなりの部分を無理に省略している嫌いがある。この規格は、ある意味では、IrDA 規格が大きすぎるという批判、批評に答えた形で制定された嫌いもある。したがって、小さいだけで効率が悪いことを忘れてはならない。

目的指向型アプリケーション プロトコル枠組みを超えて

抽象指向と現実の問題IrDA の本来の目的（ミッション）は、IrLAP、IrLMP、TinyTP などの赤外線データコミュニケーションに必要とされる信頼性のある通信方式の規格化と整備し、オプションとして、IrCOMM、IrOBEX などの特定のアプリケーションを支援するための応用プロトコルを規格化するのが目的である。しかしながら、赤外線通信を使用するユーザの立場からの視点でみると、トランスポートレイヤーと多少の応用層だけのIrDA 規格の範囲はかなり限定的であるともいえる。従来のように、プロトコルを使用する側について、通信システムに理解をもつユーザを対象にしている市場であれば、ユーザが適切なアプリケーションを用意し使うことができる。しかし、IrDA 規格を利用する最終的なユーザは、コンシューマであるし、そのユーザを支えるアプリケーション・エンジニアも通信システムのプロであることを想定することはできないであろう。

民生レベルの規格と通信規格のギャップこれは、民生、家電製品の規格と、IrDA などの通新規格を比較すれば、なおわかりやすいであろう。 家庭電化製品における規格化の一つとして、VHS 規格を一つの例としてあげるならば、VHS マークの付いたビデオカセットは、VHS マークの付いた製品であればどの製品であっても録画、再生ができる。だから、ユーザはなんの迷いもなくVHS 規格を使うことができる。これは、電化製品の規格のすべてに当てはまることである。コンパクトCD、ミニディスク（MD）、古くは、アナログ式レコードの規格も同じである。

では、IrDA などの規格をユーザサイドから見るとどうだろうか。IrDA 規格を採用している赤外線通信規格をもった装置であったとしても、アプリケーションレベルまでの互換性を保証しているわけではない。IrDA やUSB、IEEE1394 などの最新のデータ通信規格は、できるだけ広い応用が可能になるように構成されているため、特定のアプリケーションを明示的に言及しない。しかし、IrDA は携帯情報端末指向であるとか、USB はPC の周辺インターフェイスであるとか、IEEE1394 は高速のデジタルビデオ通信指向であるとかそれぞれの特性があるはずである。 各規格化団体が、その規格のもつ特性を十分に生かすことのできるアプリケーションを明示的に示すことも、その規格を使用するユーザが使い方を理解する上で必要なことである。

引き続く章で紹介するIrDA アプリケーション規格であるIrTran-P とIrMC は従来のIrDA 規格とは異なり、限定した製品を想定したフルセット型の規格である。

IrTran-P 規格は赤外線通信によるデジタルカメラの画像転送方式の規格であるが、通信規

格だけでなく、通信で交換される画像フォーマットまで言及する。IrMC は携帯電話における赤外線通信の応用であるが、IrTran-P と同じように交換されるデータ形式や音声のコーディング形式まで言及する。

IrMC 携帯電話システムにおける赤外線通信の応用

携帯電話システムの発展と課題従来の携帯電話は、「自動車電話」として発展していったが、現在の携帯電話の位置づけとしては「パーソナル・コミュニケーション」の担い手として、ビジネスユースにとどまらず大人から子供まで幅広いニーズに支えられている。通信技術、電子技術の飛躍的な発展に伴って、手のひらサイズ、重さも１００グラムをきるレベルに達している。さらには、電波を利用した公衆データ通信網と携帯電話間のデータ通信、データ通信サービスなどの利用も可能であり、西暦２０００年以降にはすべての携帯電話システムを「グローバルスタンダード化」するIMT-2000 の技術開発が進行中である。IMT-2000 や、現在の携帯電話の、基礎となる技術は、従来のような「音声通信」を中心に置いた技術ではなく、高速な「無線データ通信」を携帯電話電話網で実現することをベースとし、「音声通信」はそのひとつのカテゴリにすぎないという考え方に基づく。

また、マイクロプロセッサ、DSP 等の技術革新も携帯電話側の機能の飛躍的な向上をもたらしている。携帯電話に内蔵される機能は、単純な「電話番号メモリ」だけではなく、「電子メール」機能、「無線モデム」機能、ベアラ通信機能などのさまざまなサービスを提供できるようになった。このような携帯電話システムの発展によって、携帯電話が情報の「端点」ではなく、むしろ広大な情報流通網の出入り口としての利用が目されており、そのためのインターフェイスのスタンダードが必要となってきている。そのインターフェイスを決める上で考えなければならない技術的な課題について考えていこう。

データ通信速度の向上IMT-2000 などの次世代携帯電話システムのデータ通信速度は、100kBps を超える通信速度を可能とする。このような高速データ通信網との親和性のあるインターフェイスを必要とする。PIM 機能、電子メール、新サービスへの対応携帯電話とノートパソコン、PDA などの携帯情報端末との連携が可能であるインターフェイスを必要とする。携帯電話内部の情報量の拡大への対応携帯電話自体のもつ情報量が、飛躍的に大きくなっている。貯えられる電話帳の数や、電子メール機能、高度な設定など、さまざまな携帯電話へのニーズに伴いその情報量は拡大の一途をたどっている。これらの情報をバックアップ／リストアするためのインターフェイスが必要とされる。

乗車中の携帯電話使用による事故の増加携帯電話の基本はやはり高速に移動する車中での電話使用であろう。しかし、携帯電話の普及に伴い、自動車運転中の携帯電話操作に関わる事故が増加している。それを防止するためには、ハンズフリーシステムなどの車載装置との手軽なインターフェイスが必要とされる。ケーブル接続システムの難点従来の携帯電話と周辺装置のインターフェイスの中心は、ケーブル接続とインターフェイスカードが一般的であった。国内のPDC システムでは、１６芯インターフェイスとよばれる形式のコネクタにより、データ通信、車載装置、メンテナンスのすべてをまかなっている。しかし、このケーブル接続方式にはさまざまな課題がある。

モデム通信と携帯電話現行のインターフェイスカードとケーブルによる接続は、使い勝手、拡張性に困難がある。通信の規格が変更される毎にインターフェイスカードを変更しなくてはならないためユーザは混乱せざるおえない。また、携帯電話とのインターフェイスはインフラサイドでまちまちであり、互換性もない。ノートパソコン、PDA との連携今後考えられるサービスに対応したノートパソコン、PDA との連携を視野に入れたスタンダードなけーブルインターフェイスは存在していない。また、携帯電話のもつ大量な情報のバックアップ／リストアの統一的な手段を用意できていない。

車載装置と携帯電話携帯電話は、その操作性のよさ、携帯性のよさから大いに普及したものである。ところが、ケーブル接続によるハンズフリーなどの車載装置とのインターフェイスはなかなか普及していないのが実状である。それは、コネクタ接続による操作の煩雑さがボトルネックとなっていると考えられる。複数の信号を車載装置と接続しなければならないために、充電器のように置くだけで接続できる車載装置インターフェイスの開発がなされていない。

以上のような携帯電話と周辺とのインターフェイスに関する課題を前提として、IrMC 規格を理解することにしよう。

IrMC 規格

IrMC 規格は、携帯電話に必要とされる周辺装置との通信機能のほとんどすべてを、赤外

線通信で行おうという、かなり野心的な規格である。このIrMC のイメージでもわかるとおり、「携帯電話」を中心に考えた場合の応用であって、パソコン、PDA も重要なファクターであるがあくまでもIrMC 規格の機能の一部であるという考えかたである。IrMC 規格は、以下のタイトルを持つ。Specifications of Extensions to IrOBEX for Ir Mobile Communications Version 1.0 October 15, 1997規格名は控えめで、携帯電話通信のためのIrOBEX 拡張となっているが、IrOBEX における拡張というよりもむしろ、携帯電話の周辺装置の通信において、IrDA 規格をどのように応用し、他の規格とどのように整合性を取るべきかを記述した奥行きの広いものとなっている。

IrMC のテリトリは、携帯電話、ポケットベルを中心としたモバイルコミュニケーション

における応用であり、そこに必要となる、IrDA 以外の規格を多く含んでいる。

それは、ネットワークに対するデータ通信、携帯電話周辺間のデータ交換、自動車などに装備されるハンズフリーユニットとの通信が想定されている。携帯電話におけるネットワークデータ通信携帯電話のデータ通信には通常、２通りのデータ通信がある。 一つは携帯電話の事業者が提供する、携帯電話同士のまたはポケットベル（ぺジャー）とのメッセージ交換システムである。これは、NTT DoCoMo が提供している１０円メールや、GSM システムで採用されているショートメッセージがこれに該当する。これらのデータ通信については、OBEX をベースとしたメッセージ交換としてIrMC規格で規定している。交換されるメッセージはvMSG という形式のデータフォーマットを採用している。

もう一つのデータ通信は、インターネットプロバイダが提供するダイアルアップアクセスポイントなどにアクセスするためのIrCOMM 規格によるモデム機能である。基本的には、IrCOMM 規格で言及されているType-2 デバイスである、IrTA を実装することになる。IrMC 規格において、IrCOMM 規格については言及しないが、携帯電話を赤外線モデムであると考えた場合のNCU 制御規格であるITU-T V25ter 規格（簡単にいうとモデムのAT コマンド）の携帯電話における拡張にについて広範囲に言及している。

Call Control Audio stream CSD IrDA-SIR FIR IrLAP IrLMP Connection Oriented Connection-less IAS

IrCOMM

TinyTP IrDA Physical Layers...Lite

Ultra

OBEX Phonebook Calendar Messaging TinyTP DeviceInfo Voice+ C.C.携帯電話における周辺装置とのデータ交換携帯電話には、簡易なPIM である電話帳や、アラーム機能、メモ帳機能などを搭載しているものが多い。これらのPIM データをPC やPDA などと交換するための方法をIrMC で規定している。電話帳については、vCARD 形式、アラーム機能は、vCAL 形式、メモ帳はvNote 形式のデータ形式を定義しておりOBEX によるデータ交換を可能にしている。また、データ交換については、いくつかのレベルを規定し、レベル１からレベル４までのデータ交換方式を定義している。

リアルタイム音声通信自動車の中で携帯電話を使用する場合、車内でハンドセットを使用せずにハンドルを握ったまま、ダイアル発信・着信ができ、そのまま通話できることが要求されている。これは、車内での携帯電話使用に起因した事故の急増のため、電話操作に起因している。欧米や、日本でも車内で携帯電話のハンドセットを使用した場合、道路交通法違反になったり、万が一事故を起こすと保険が利かない場合もある。IrDA 規格をうまく応用すれば、車載されるハンズフリー装置とのインターフェイスを赤外線で行うことも理論上可能である。車載されるハンズフリー装置は、音声とダイアル信号の組み合わせで構成され、ダイアル発信、着信ができる。IrMC規格ではこのリアルタイム音声通信規格をRTCON というあらたなアプリケーション規格として採用している。

IrOBEX とvCARD の交換

IrMC で行われるデータ交換は、IrOBEX を使用するが、電話帳、メッセージ、アラーム、

ノートなどは同じ方法で交換される。IrOBEX は、赤外線を使用したデータ・オブジェクト交換手順で、コネクション型（CO 型）、コネクションレス型（CL 型）の二つがあることを学んだ。コネクション型（CO 型）はおもに、パソコン、PDA とのデータ交換に利用され、コネクションレス型（CL 型）は能力の低いポケベル（ぺジャー）などとのデータ交換に利用される。

IrMC におけるアクセスレベル

IrOBEX の章でも述べたが、IrOBEX で交換するオブジェクトの操作にについては、IrMC

で定義している。IrMC で取り扱うオブジェクトは、単純な単一データ交換から、データバックアップ、レコード単位のアクセス、データ同期の、４レベルのアクセス方法が用意されている。レベル１アクセスレベル１アクセスは、簡単なオブジェクトを交換する。１件の電話帳、１件のアラームなどを取り扱う。データはインボックスに蓄積され、自動的またはユーザの選択によりデータベースに追加される。レベル２アクセスレベル２アクセスは、電話帳、アラーム、メッセージのデータベース全体を取り扱う。簡単に言ってしまえば、オブジェクト全体のバックアップ、リストアーが可能である。

レベル３アクセスレベル３アクセスは、電話帳などに含まれるレコード単位のアクセスを可能に

Ultra OBEX

PUT vCard OBEX GET/PUT vCard-stream OBEX PUT vCard OBEX GET/PUT vCard by index OBEX GET/PUT pb.log 1 2 3 4 Minimum Access Index Synchronizationする。これをインデックスアクセスという。レコード番号を特定することで電話帳などに含まれる個別データにアクセスが可能になる。レベル４アクセスレベル４は、データ同期を可能にする。データ同期とは、データ交換を行う相手先のデータベースと、携帯電話内のデータの、更新、追加状態を追跡し相互のデータ矛盾を解決する。データレコードには、データが生成されたときに付加されるユニークなID を保持し、更新、追加状態を追跡できるようになっている。

IrMC とvCARD,vCAL システム

vCARD とは、インターネット上で「電子名刺」を交換するために制定されたデータ形式である。また、vCAL とは、インターネット上でお互いのスケジュールなどのカレンダー情報を交換するために制定されたデータ形式である。これらは、IrDA 規格ではない。これらの規格は、Internata Mail Consortium(IMC)で規格化が行われれおり、IrMC 規格ではこれらのIMC 規格をベースに応用したものである。IrMC 規格では、ベースとなる規格については言及していないので、必要な情報を望むのであれば、以下の規格を参照する必要がある。

VCARD“vCard - The Electronic Business Card Exchange Format - Version

▶2.1”, The Internet Mail Consortium (IMC), September 18, 1996,

http://www.imc.org/pdi/vcard-21.doc VCALENDAR“vCalendar - the Electronic Calendaring and Scheduling Format -Version 1.0", The Internet Mail Consortium (IMC), September 18,1996,http://www.imc.org/pdi/vcal-10.doc vCARD の記述vCARD の表記例vCARD は、テキストベースのデータである。一連のテキストから容易にvCARD を抽出できるように、BEGIN:vCARD / END:vCARD にか困れたテキストブロックで構成される。

vCARD は、複数の行から構成され、各行には、プロパティとバリューによるデータ構成によって成り立つ。プロパティプロパティとは vCARD のデータ項目を指定する名称である。N は名前項目、TELは電話項目を意味する。プロパティとバリューを区切るために：（コロン）が使用される。とりうるプロパティはvCARD の規格書で定義される。プロパティ・パラメータプロパティはしばしば、パラメータを伴う。パラメータとはプロパティの属性を示し、WORK（勤務先）、HOME（自宅）などの属性を持つ。また、バリューのもつデータ属性を記述することもある。CHARSET は、文字種類を、ENCODINGはコーディングの種類をあらわす。これらの形式はインターネットMIME 形式と一致している。プロパティと分離をするために；（セミコロン）が使用される。

バリュープロパティーに対する値を与える。N:Kitazumi であれば、名前は Kitazumi であることを意味する。バリューに複数の項目を必要とするときは、区切り記号として；（セミコロン）を使用する。VCARD で定義されているプロパティは数十種類にのぼるが、IrMC で必須の項目は、名前（N）、電話番号（TEL）である。レベル４の同期をサポートするためにはユニークID である（UID）も必要となる。

BEGIN:VCARD N:Kitazumi;Gontaro TEL;WORK;VOICE:+81-3-3795-7601 END:VCARD CR CR CR CRその他のオブジェクトの記述

IrMC では、vCARD 以外に、カレンダ、メッセージ、ノート等を扱うことができる。デ

ータの記述方法は、vCARD 形式に準拠しており、ここでは例を挙げることにとどめておく。カレンダーオブジェクトこの例は、３つのカレンダーオブジェクトである。カレンダーオブジェクトは、「.vcs」というオブジェクト拡張子をもつ。カレンダーオブジェクトは、そのオブジェクトを識別するために、BEGIN:VCALENDAR/END:VCALENDAR のブロックに挟まれている。カレンダーの種類としては、イベントとTODO である。イベントやTODO は、特定の日時時刻になるとアラームを発生させる。

BEGIN:VCALENDAR VERSION: 1.0 BEGIN: VEVENT CLASS:PRIVATE DESCRIPTION:Lunch with Mark.END:VEVENT END:VCALENDAR BEGIN:VCALENDAR VERSION:1.0 BEGIN: VTODO DALARM:19970228T15 0000;2;2;Call Home!END:VTODO END:VCALENDAR BEGIN:VCALENDAR VERSION:1.0 BEGIN: VEVENT CLASS:PUBLIC SUBTYPE:TRAVEL END:VEVENT END:VCALENDAR<calendar-indexed-object> entries vCalendar objects Object Indices 1 2 0メッセージオブジェクトこの例は、３つのメッセージオブジェクトである。メッセージオブジェクトは、「.vmg」というオブジェクト拡張子をもつ。メッセージオブジェクトは、そのオブジェクトを識別するために、BEGIN:VMG/END:VMG のブロックに挟まれている。メッセージオブジェクトは電子メールの内容を交換するおオブジェクトであるので、差出人と、受取人が必要となる。これらの差出人と、受取人はそれぞれvCARD 形式で記述されている。VENV は、封筒を意味する。この例では、VBODYというメール本文をENV で囲い、宛先を記述した vCARD とともに VENV で囲っている。このようにメッセージ形式は若干複雑な構造を持っている。

BEGIN: VCARD VERSION:2.1 N:Mat EMAIL:ma@abc.edu END:VCARD<vmessage-object>BEGIN:VMSG VERSION:1.0 BEGIN:VENV BEGIN: VCARD VERSION:2.1 N:Tanaka TEL:+1123456 END:VCARD BEGIN:VENV BEGIN: VBODY Date: 20 Jun 96 Subject: Fish Let's go fishing!BR, Mat END:VBODY END:VENV END:VENV END:VMSG IrOBEX とアクセスメソッド

IrOBEX の章でものべたが、IrOBEX のオブジェクト名は、オブジェクトのアクセスも

指定している。IrMC におけるオブジェクトとオブジェクト名指定について説明しておこう。レベル１アクセスレベル１アクセスに使用されるオブジェクトは、パス名をもたない。オブジェクトの種類を識別するためにはオブジェクトの「拡張子」を用いる。たとえば、vCARD オブジェクトは、「.vcf」というオブジェクト拡張子を持つ。

IrOBEX でサポートコマンドされるのは「PUT」のみである。「PUT」コマンド

で外部から転送されたオブジェクトは、InBOX という仮想のフォルダに保管される。たとえば、InBOX にある、「.vcf」という拡張子を持つオブジェクトは、電話帳であると識別され、必要とあれば、telecom/pb.vcf の最後に追加されたのち破棄れる。電話帳のデータの一つが選択され、送信を要求されると、そのデータが切り離され、OutBOX という仮想のフォルダに配置され「PUT」コマンドにより相手側に送信され、後に破棄される。

レベル２アクセスレベル２アクセスに使用されるオブジェクトは、パス名を持つ。IrMC のオブジェクトはすべて、telecom というパスを先頭に持つ。telecom/pb.vcf は、電話帳全体をあらわすオブジェクト名である。このオブジェクト名で「GET」コマンドを実行すると、携帯電話のもつすべての電話帳データをまとめてバックアップすることができる。また、このオブジェクト名で「PUT」コマンドを実行すると、携帯電話のもつすべての電話帳データをまとめてリストアすることができる。

IrOBEX

トランスポートInBOX Telecom/pb.vcf OutBOX Pb/00.vcf BEGIN:VCARD N:Kitazumi;Gontar o TEL:03-3795-7601レベル３アクセスレベル２で命名されたオブジェクト名に、さらに数値のパスを加えたものは、そのオブジェクトのレコードレベルのアクセスをあらわす。たとえば、telecom/pb/01.vcf であれば、１番目のレコードをアクセスすることができる。このオブジェクト名で「GET」を行えば、レコード単位の読み取りができる。また、「PUT」を行えば、レコード単位の書き込みができる。

レベル４アクセスデータ同期に関しては、IrMC Ver 1.0 において正確な手法を確立できていないので説明を省略する。

IrMC のモデム機能

携帯電話の重要なデータ通信機能として、モデム機能がある。一般的なモデムは、DTE（Data Terminal Equipment）とRS232C で接続され、モデムのNCU 機能により公衆網にアクセスする。IrDA 規格では、IrCOMM 規格によりRS232C 規格のエミュレーションと、モデムなどのゲートウエイ接続方法を規定したIrTA 規格が制定されている。

IrMC 規格では、さらに、NCU のコマンドである、ITU-T V.24 ter 規格であるAT コマ

ンドの拡張について言及している。

IrTran-P 規格

IrTran-P 規格誕生の背景

IrDA 規格におけるアプリケーション層は、アプリケーション層を使用する装置、システムに深くそ依存する傾向にある。赤外線通信を使用したデジタルカメラ向けの規格である、

IrTran-P もその例外ではない。ここでは、IrTran-P 規格が誕生した背景についてスポット

を当てながら、IrTran-P 規格制定の意義を考察していこう。筆者は、IrTran-P の規格に参画した経験をもつので、IrTran-P 規格誕生における規格化の哲学を紹介しておきたい。1997 年6 月10 日、NTT、SONY、CASIO、SHARP、オカヤ・システムウェアの５社は、IrDA の提唱する赤外線通信規格に基づくデジタルカメラ向けの画像通信方式である

IrTran-P(Infrared Transfer Picture)を共同開発し、国内において記者発表を行った。この

５社は、IrDA 規格とともにこのIrTran-P 規格が、広く利用されていくことを願いこの規格を赤外線通信の唯一の業界団体であり、公開の場でもあるIrDA に提案し、最終的にはIrDA 規格のひとつとしてIrDA より業界標準規格として採用されるべく活動を開始した。

IrTran-P 規格を利用するメーカーやユーザの視点に立てば、IrTran-P 規格がパテントフ

リーのスタンダードとして自由に利用することが出来るというメリットが生まれることとなる。と同時に、IrTran-P 規格を策定するメーカーはオープンな規格における市場原理という競争に巻き込まれることになるのはいうまでもない。IrTran-P 規格を策定するメーカーには、規格開発に携わるという先駆者利益以外にプロフィットはない。しかし、デファクト・スタンダードが欧米企業から日本になだれこみ、けして国内のメーカ、ユーザにとって有利な規格になるとは限らない。IrTran-P 規格を策定した企業は公人としての立場を確認し合いながらIrTran-P 規格策定を行ったのはいうまでもない。

アプリケーション寄りの規格を制定し、広く利用される条件として、提案するメンバーがそのアプリケーションについて熟知しており、なおかつその市場での発言力、シェア等がなければ広まっていくことが危ぶまれるが、IrTran-P 規格制定メンバーの構成を見ると、世界に先駆けて、IrDA 方式の通信機能を搭載したデジタルカメラを発売したSONY、SHARP、国際的なデジタルカメラ市場でのシェアの上位にランクされているCASIO、IrDAプロトコル開発分野で積極的に活動しているオカヤ・システムウェア、電気通信分野でマルチメディアを積極的に取り入れている日本最大の電気通信企業であるNTT という構成になっている。

時代的な背景を見ると、NTT は、1998 年2 月から日本の長野で行われる冬季オリンピックの公式スポンサーであり、オリンピック会場を中心にISDN デジタル通信網を利用した、マルチメディアキオスク、IrDA の提唱する赤外線通信を搭載したISDN 公衆電話機を設置する計画があり、実際のオリンピック会場には100 台以上の赤外線搭載の公衆電話機が設置されたという事実がある。オリンピック会場に設置された、マルチメディアキオスク端末や、ISDN 公衆電話機による高速デジタル通信網において、わかりやすいマルチメディア応用製品であるデジタルカメラやＰＣ、ＰＤＡなどから、コードレスである赤外線通信を入り口としたデジタル通信網を媒介し幅広くマルチメディア的な利用ができないかという実践検討がなされた。

そのようなタイミングに呼応したように、現在のビデオ技術とマイコン技術の集大成ともいえるデジタルカメラが、コンシューマー市場でも徐々に普及しはじめた時代でもある。

IrTran-P 規格が制定される以前の段階においてもIrDA 規格を利用して画像転送ができる

商品もあった。しかし、たとえば、SONY およびSHARP はIrDA 搭載のデジタルカメラがすでに発売されていたが、その通信方式はIrDA 規格といっても同一のものではなく、IrDA の上位層が異なるため製品同士の互換性はない。ユーザから見れば、IrDA はつながらないと思えるだろう。これが通信規格のジレンマのである。つまり、赤外線通信付きのデジタルカメラなど、異機種間での通信やデータ共有するためには、規格を統一しそれを普及しなければならないというメーカ、ユーザにとっては頭の痛い問題がある。特に、デジタルカメラなどの複雑な応用製品における規格統一の場合、通信手順だけでなく、通信手順上位の構成、画像フォーマットなど広範な規格統一を図らない限り、ユーザレベルにおいての「真の互換性を保証する」とは言えない。

IrTran-P 規格を提案した企業は、デジタルカメラのユーザが簡単に取り扱え、なおかつ

相互の画像データのやり取りにおいての最低限度の互換性を保証することを可能とする「赤外線通信方式の手段の統一規格」を提唱するべきであると結論し、統一規格開発のプロジェクトを1998 年2 月に開始した。この提案は、「デジタルカメラのデータ転送」という広範なテーマをどう実現するかという問題を、このような製品が普及するマーケットセグメントや現在の技術将来の拡張性を勘案しながらプロジェクトを進めて行くことになった。その結果、技術的には、最小限度の規格統一で実用的な応用をが可能な規格を作ることが可能であると結論し、参加各社はそれを実証する為に試作機を作成して相互接続試験を成功させた。ここで重要なことは、規格書はいわば「ペーパー・ウェア」であり、実際にその規格を使った製品を試作し実際に使わないかぎり「実用」に供さない可能性があるという危険性について配慮しているということである。このような実践に基づく規格統一は、デジタルカメラ業界だけではなく、デジタル通信業界、プリンター業界、イメージングソフトウェア業界、報道機関など広い分野での期待に答えることができる。

デジタルカメラと通信の融合技術については、広範な応用がある。撮った写真を送るという機能から、カメラの自動制御と幅広い分野が考えられる。また、デジタルカメラといっても、一般消費者向けから業務用、写真家用と、使われかたや価格帯もさまざまであり、すべての分野を包含するような統一の規格は、当然困難が予想される。広範な規格統一は策定に時間がかかり、汎用性の為にどの分野でも中途半端なものになる恐れもある。そこでIrTran-P 策定において、一般消費者マーケット向けの機能を中心に規格統一を検討し、ベースラインを策定、その後拡張していくという方針がとられた。つまり規格制定において、もっとも効果的でかつ利用価値のあるモデルとは何かを、技術的な議論の前に徹底的に検証することがなされた。このことは、規格化の重要な側面である。簡単に表現すれば、統一規格に含まれるテクノロジーがたとえ複雑であっても、ユーザから見える部分として一言で表現できるような単純なもにしなくてはならということである。IrTran-Pの場合、あれもこれもという発想よりも普遍的な命題を解決するテクノロジーでなくてはならないという理念に基づき、「一枚の写真を赤外線により確実に転送し表示する」というもっとも普遍的で、単純なコンセプトにたちいたることになった。

このコンセプトには、NTT が参画していることで理解できると思うが、デジタルカメラ同士だけでなく、プリンタ、パソコン、PDA、公衆通信網、ネットワークなど広範なサービスへの応用も含んでいる。これらのさまざまなメディアで可能な限り早く実用が可能になるためには、当然のことながら、「枯れている既存の技術を生かした規格統一」であることが要求されよう。IrTran-P 規格制定の過程で、現在ある周辺技術に関する規格を拾い上げ、かつ、その技術が「現在のマーケットで受け入れられるコストである」という必要条件を勘案し、そのベースラインとなる規格は現在のハードウェアの要件、ソフトウェア要件を満たしうるという必要条件が課された。仮に新たな開発部分があってもそれは最小限度であることが望まれる。しかし、このような制約条件が仮定されているとしても、「未来にわたる適切な拡張性を保証できること」も重要であり、IrTran-P は将来の機能拡張についても十分に配慮されている。

IrTran-P 策定に参加している企業は、IrTran-P 規格化の前に、赤外線通信付きのデジタ

ルカメラを市場にすでに投入しているメーカもある。したがって、デジタルカメラ周辺の市場の動向を十分に把握しているといえる。IrTran-P が開発された時期は、デジタルカメラの黎明期であるとともに、煩雑な画像データ転送の簡便化が重要な課題であった。また、ユーザの層を広げるためには、ローコスト、ローエンドの機種において、写真の受け渡しが簡単にできることも望まれている。これらの背景があるため、IrTran-P 規格のベーシックな要求事項として、複雑な機能、複雑な操作を排除したもっともシンプルでもっとも使われる機能である、「一枚の写真を送る」という単純さが必要であり、そのことにより、ローエンド機種での実現を最小限度の機能追加で実現できるものでなくてはならないという結論に至った。キラーアプリケーションの条件としては、多くのメーカが参加できるハードルの低いものから実現していくことが望まれる。IrTran-P はこの条件を満すべく規格化されている。

IrTran-P は、すでにIrDA 規格として確立されている、IrSIR、IrLAP、IrLMP、TinyTP、

IrCOMM の上位層に、画像交換や、装置の持つ特性を交換し合うために必要となる、SCEP

（Simple Commend Execute Protocol）プロトコル、bFTP (Binary File Transfer Protocol)プロトコルを配置している。そして、その赤外線通信エンティティーの上で、UPF（Uni Picture Format）という画像フォーマット（ファイル）をやり取りする形式になっていいる。（UPF については画像フォーマットでありIrDA の範疇を超えるために、アペンディックスとしてIrTran－P 規格では取り扱われている）。しかしながら、これらのすべてを総称して、IrTran-P と定義する。

SCEP は、IrCOMM 上でのセッションを確立し、コマンドを上位層に通知する、透過的なセッションレイヤを提供する。SCEP の手順は、下位層であるIrDA プロトコルが「エラーフリー」である利点を生かし、またIrDA プロトコルにマッチングした高速なセッションレイヤとして開発された。転送の内容が著作権を含む画像データを取り扱う場合も考慮して、セッション開始時点での認証も含まれている。BFTP は、その名の通り、バイナリファイルを転送するためのサービスを提供する。bFTPは、通信プロトコルとともに仮想的なファイルシステムを仮定する。しかし、「バイナリファイルを名付きで保存」できるような単純なファイルシステムを仮定しているため比較的簡単に実装できるという側面がある。また、PUT モデルのみをベーシックな規格としているのは、ファイルシステムの複雑さを避ける目的である。一方、Query 機能により装置の持つ機能や特性、IrTran-P のテーマである画像転送における取り扱える画像フォーマットの照会などが行える特徴がある。このQuery 機能は、デジタルカメラのユーザインターフェイスを簡素化する。Query 機能により、画像転送の前に、対向したデジタルカメラやプリンタ同士で、転送する画像データでもっとも適したものを転送するチャンスを与える。

この機能によりユーザは、「送りたい写真を選択し、送信ボタンをおすだけ」で、適切な画像データを装置の違いを越えて転送や通信、印刷が可能になるわけである。

IrTran-P 策定にあたり、当初IrDA で規格化されている、オブジェクト交換手順である

OBEX も検討の対象としていた。しかしながら、開発時点において、OBEX がPC やPDAには実装されていないこと、新たなオブジェクトのカテゴリを作らなくてはならないなど時間的、市場的な問題があるという結論に達し採用を見合わせた経緯がある。また、既存のファイル転送などのパブリックドメインとしてXMODEM、YMODEM、ZMODEM などやインターネットの規格なども検討したが、拡張性やIrDA プロトコルとのバランス、プロトコルサービスレイヤのミスマッチなどから採用にいたらなかった。結果的には、IrDAのプロトコルの特性や、現在のIrDA 規格の普及状況などを勘案して新たなプロトコルレイヤとしてのSCEP、ｂFTP を新たに開発し採用することになった。

IrCOMM 上にSCEP、bFTP を配置したのは、PC、PDA、プリンタにおいてIrCOMM

のサービスとして用意されていることや、公衆電話網、携帯電話網のインターフェイスとして、IrCOMM が採用されていること、PSTN/ISDN の利用を目的としたIrTA 規格が

IrCOMM 推奨され電気通信分野においての親和性がよいことなどの理由による。（SCEP、

bFTP の構成ではIrLMP 上の上層として実装は可能であったがIrCOMM 上にあえて実装されている）画像フォーマットであるUPF については、前に述べたとおり、IrDA の規定の範疇におさまらない画像フォーマットの規定である。本来IrDA は赤外線通信についてのプロトコルを策定し標準化することを目的とするため、画像転送の内容について規定するのは範囲外といえる。しかしながら、デジタルカメラの応用として、相互接続性に関して保証するためにはどうしても画像フォーマットを取り決め、赤外線で送った画像データが確実に再生されなくてはならないことは言うまでもない。そこで、IrTran-P において、IrDA に規格として提唱する上で、画像フォーマットについてはアペンディックス（追補）として「推奨する画像形式」として具体的な内容について触れることとしている。

UPF は、JPEG ベースラインを基本とした画像ファイルフォーマットである。JPEG ファイルであるJFIF は、さまざまなカラー形式の画像を取り扱え、なおかつ高度な圧縮方式を採用しているため、画像ファイルフォーマットの業界標準であるといえる。JPEG は、多様なカラー形式を可能としたフォーマットのため、ローコスト化するためには、JPEG の一部のフォーマットを標準として採用するなどある程度の妥協が必要となる。UPF では、JPEG のベースラインに含まれるフォーマットのうち、確実にお互いの装置が最低限度表示と転送ができる形式を必須として定義し、それ以外のフォーマットについてはオプションとしている。

デジタルカメラの固有の特性として撮影日時や、画像のオリエンテーション（方向）、その他の付加情報など、JPEG フォーマット内での情報だけではデジタルカメラで撮影された写真に付随する情報のすべてをカバーできない。このような背景から、UPF は、JPEG の画像データ形式をそのまま含み、JPEG の画像データ形式には手をつけずに、ファイル内に固有のヘッダを配置し情報を分離して格納する形式としている。また、ヘッダには拡張性やベンダーユニークな機能追加も可能になっている。このことにより、デジタルカメラに必要な情報と画像表示展開に必要な情報が分離され、現在のJPEG 技術をそのまま継承できるメリットがありる。

とくに、デジタルカメラなどの小型装置においては、JPEG 圧縮展開などのアルゴリズムをハードウエアにより行うものとか、ミドルウェアを採用しているデジタルカメラの場合など、既存のハード、ソフトを利用する場合ＪＰＥＧそのものに手をつけることは望ましくないといえるだろう。UPF はさらに進んで、JPEG 形式のデータ内で定義のあいまいな点についての付加情報をヘッダ部分に配置している。たとえば、色再生に関わる白レベル、黒レベル、色基準など、画像再生時に必要となる要素なども規定していることは注目すべきことである。現在さまざまな機関においてデジタルカメラ向けのフォーマットの検討がなされているが、最終的な結論はまだ出ていないのが現状である。多くの場合、JPEG 形式にに新たなタグを付加するなどの工夫がなされているが、各社の思惑もあってなかなか結論が出ないというのが現状である。たしかに、そのような規格の決定を待つというアプローチもたしかにありうるが、デジタルカメラの市場動向を考えると、すでにある規格をできる限り利用し、デジタルカメラとして必要な情報は分離して付け加え、拡張性だけは確保しておくというアプローチのほうが現実的であると考えられる。UPF に関しては、IrDA規格に含めずに「推奨する画像方式」とIrTran-P で規定しているが、IrTran-P 規格としてはこの形式の画像フォーマットを取り扱えることが必須となる。

IrTran-P が誕生の背景は以上のような状況であったが、規格が誕生してから現在まで、

２年を経過しているが現在の状況を述べた後、プロトコルの説明に移ろう。IrTRAN-P の採用状況規格は、公的な機関において採用されても。実際に装置に実装され使われなければ意味がない。そういう意味では、多くの国際標準が生まれては消えていく運命にある。では、

IrTran-P 規格はどうだろうか。

IrTrn-P を採用しているデジタルカメラとビデオプリンタの例（CASIO）

IrTran-P を標準で採用しているパソコンの例(CASIO)

民生分野での採用状況現在、IrTran-P は、デジタルかカメラ以外にも多くの装置に採用されておりその幅も広がっていっている。ではどのような民生装置に採用されているか見ていこう。デジタルカメラ： SONY、SHARP、CASIO、JVCデジタルムービー：JVCイメージスキャナー：CASIOフォトプリンタ： SONY、SHARP、CASIO、JVCビデオプロジェクター：SHARPワードプロセッサ：SHARP携帯電話、公衆電話：NTT、NTT-DoCoMoデジタルムービーでの採用は、DV 規格の静止画をIrTran-P で転送するものである。また、イメージスキャナは、ポケットハンディスキャナで名刺や雑誌の画像を取り込みカメラやパソコンに転送するためにIrTran-P を使用している。変わったところではワードプロセッサである。デジタルカメラから取り込んだ画像をそのままワープロ原稿に貼り込むことができる。ビデオプロジェクタの応用では、プレゼンテーション原稿をカメラから転送することで可能にしている。つまり、パソコンを使用せずにプレゼンテーションが行えるというコンセプト商品である。

IrTran-P を採用しているメーカはIrTran-P 規格を制定したオリジナルメーカが

多いが今後は更に増えるであろうと予測される。

IrTran-P むけ専用プログラム (Okaya Systemware)

パソコン分野での採用状況パソコン分野では、IrTran-P 専用のアプリケーションは、オカヤ・システムウェア社のTran-P モニタ、CounterPoint 社のJet-Beam などがる。また、CASIO、SHARP からは、デジタルカメラや、ビデオプロジェクタに対応したソフトウェアやザウルス、Windows CE 対応の IrTran-P ソフトウエアが発売されている。現在もっとも注目されているのは、次期のマイクロソフトの基本OS であり、Windows NT とWindows 98 を統一したWindows 2000 におういて IrTran-P が正式に採用されたことである。西暦2000 年に発売されるパソコンには標準で

IrTran-P がついてくることになる。

Windows 2000 において採用されるIrTran-P は、OS そのものに、IrTran-P サーバーが標準で搭載されており、ただIrTran-P 対応のカメラをパソコンに向けて通信を行うと自動的にパソコンがIrTran-P 規格で画像データを受け取り表示する機能である。つまり、2000 年に発売されるパソコンは何も考えずに IrTran-P カメラと通信ができるということである。他のカメラのように専用のソフトウェアを別に購入しインストールすることは必要がない。したがって、IrTran-P プロトコルは、デジタルカメラとパソコンのプラグアンドプレイとしてWindows 2000において採用されたといってもいいだろう。

現在のパソコン基本OS のほぼ９０％以上が Windows であることを考えると、Windows 2000 がリリースされることでIrTran-P マーケットが大きく広がることになるであろう。デジタルカメラの通信規格の多くは特定のメーカがそのプロパティを保持しているため、一般の規格として、になかなか多くの周辺装置メーカが採用しずらいのが現状であるが、IrTran-P の場合、規格は公知されているし、IrDA 規格としてIrDA メンバーは自由に使用することができる。

最近では、LINUX というパブリックドメインのOS にもIrDA が搭載され、そのIrDA プロジェクトにおいてIrTran-P の開発の動きが活発になってきている。この活動はすべてボランティア活動であり、世界中の多くの技術者が共同でIrDA規格をLINUX に移植しようとしている。ミドルウェアの提供状況IrDA プロトコルのミドルウェアを発売している、オカヤ・システムウェア社、Counter Point 社および Phoenix 社から、IrTran-P プロトコルが発売されている。

以上のように、わずか２年で多くの装置やOS、そしてミドルウェアなどにIrTran-P が採用されつつあることがわかるであろう。また、市場を大きく左右するOS 分野での

IrTran-P の採用はすくているメーカには脅威となると思われる。したがって今後とも多く

の民生分野、産業分野でIrTran-P が採用されていくことは間違いのないところであろう。

IrTran-P のユーゼージモデル

IrTran-P が想定しているユーセージモデルつまりは使い方のモデルについて説明しよう。

IrTran-P の通信の主体は、デジタルカメラ同士、あるいはデジタルカメラとプリンタが中

心となっている。ユーセージモデル１（シンプルモデル）ユーセージモデル１はもっとも単純な通信モデルである。送信側は、写真を撮るか、すでに撮ってある写真を選択する。受け取り側は受信待機する。送り側は、送信ボタンなどを押すことで、接続要求を出し、受信側はその要求を受理する。送信側は、IrTran-P 標準のVGA 画像を送信する。送信が成功すると、送信側は通信経路を切断する。このユーセージモデルでは、必要最小限の手順だけで構成されている。接続、送信（PUT）、切断というシンプルなモデルで構成されている。したがって、交換される画像は、IrTran-P の標準画像であるVGA のみが通信の対象画像となる。

IrTran-P の最小構成はこれだけであり、このユーセージモデル１だけが必須項

目になっている。つまり、IrDA のプロトコルと、VGA 規格のJPEG 画像を持つことで少なくともIrTran-P 規格が採用できることになる。現在の技術水準であれば、この標準モデルは現在販売されているほとんどのデジタルカメラが採用できるレベルであり、採用しているマイコンにIrDA のトランシーバとインタフェイスできる機能があれば実現可能なレベルである。

ユーセージモデル２（画像サイズの拡張）

ユーセージモデル２はVGA 以外のサイズの画像を交換する通信モデルである。送信側は、接続を確立した後、受け取り側が受信可能な画像サイズを問い合わせている。この問い合わせを、QUERY という。受け取り側は、VGA とXGA が受信可能であると答える。送信側もXGA をサポートしているならば、お互いにVGAよりもより高画質であるXGA サイズの画像を交換することができる。したがって、このばあいは、送信側はXGA サイズの画像を受けて側に送信する。もしも、QUERY に対する応答でVGA 以外に共通する画像サイズがない場合は当然のことながらVGA 画像を交換することになる。

これは、すべてのIrTran-P はVGA 画像を送受信できることを要求している。

IrTran-P 規格では、IrTran-P カメラ同士は必ずVGA 画像交換ができなければな

らない。なぜならば、規格のインプリメントの違いによって画像交換ができないという最悪の状況にユーザが陥らないようにするための必須条件である。この条件は民生レベルの応用において必要不可欠な機能ともいえる。往々にして、通信規格において、インプリメントの違いによる接続不可能という例はすくなくない。同じ規格でもインプリメントが異なるだけで接続できないのは、技術レベルでは許されるだろうがユーザレベルでは許されないだけではなく、規格そのものの信頼を失いかねない。同じ規格のロゴがありながら、画像転送ができないのはユーザの立場では許されないのである。

ユーセージモデル３（複数画像の転送拡張）

ユーセージモデル３は一度のセッションで、複数の画像を一度に交換する通信モデルである。送信側は、接続を確立した後、受け取り側が複数の画像を一つのセッションで複数受信可能であるかを問い合わせている。受け取り側は、複数の画像を一度のセッションで受信可能である場合はその旨を送信側に応答する。すると、送信側は、一度のセッションで複数のPUT コマンドを発行し複数の画像を受信先に送ることができる。この機能は、主にデジタルカメラで撮影された画像をまとめてパソコンにバックアップしたりリストアしたりする場合に活用される。自分自身が一度のセッションで複数の画像を受信できなくても相手がサポートしていればバックアップは可能である。

ユーセージモデルのまとめ

IrTran-P 以外のデジタルカメラ向け通信プロトコルの場合、その主体はパソコン

との通信であり、カメラをサーバーとして、パソコンがクライアント側になってバックアップ（GET）とリストア（PUT）を行うモデルがほとんどである。しかし、IrTran-P は、カメラ同士、もしくは送り手側のカメラが主体となって画像交換を行うモデルを採用している。カメラが自発的に画像の送り手になることにより、パソコンとの通信以外のいろいろなシーンでの幅広い応用が可能になる。

IrTran-P ではあえて、GET コマンドを採用しなかったのは興味深い。

IrTran-P の通信プロトコル

BFTP SCEP

IrCOMM

アプリケーション層（目的指向型通信手順）IAS SERVER IAS CLIENT TinyTP(Flow Control)Information Access Serviceトランスポート層IrLMP(IrMUX)Link Management (Multiplexer)リンクマネージメント層（通信経路の多重化）IrLAP Link Access Protocolデータリンク層（信頼性のある通信経路）IrPHY(赤外線物理層)物理層赤外線信号への変復調

IrTran-P プロトコル層の位置の意味

デジタルカメラの通信相手が、パソコンやカメラ同士などの近距離通信だけを考えればIrOBEX と同様にTinyTP 上にアプリケーション層を構築すればいいが、ISDN 通信網や、携帯電話などの通信網を利用して遠距離の画像交換を可能にするためには、ISDN 公衆電話（IrTA 規格）や、携帯電話（IrMC 規格）で採用されているIrCOMM をプロトコルの下位層に選択する必要がある。IrTran-P が

IrCOMM の上にSCEP、bFTP プロトコルを構成している理由の重要なポイント

はここにある。

IrTran-P からIrDA 規格に対して要求しているのは、信頼できる高速な通信経

路で、バイト列が透過的に寿送信が可能であることだけである。したがって、同様の条件を満たすことができる通信網であればIrTran-P を上位に持つことができる。その例が、IrTran-P over ISDN や Tran-P over Blue tooth である。IrTran-P over ISDN は、ISDN のエンドポイント同士にIrCOMM を配置し、IrCOMM はそれぞれのローカルなカメラとIrTA 間の通信プロトコルとして使用する。SCEP／bFTP は、ISDN 網を隔てたカメラ－カメラ間で交換される。ISDN 網で提供するのはB チャンネルのLAPD 上のV110 エミュレーションなどによる信頼できる高速な通信経路だけである。また、Tran-P over Blue tooth は、IrCOMM と同等な、Blue tooth 規格におけるモデムエミュレーション規格を使用し、無線区間を信頼できる通信経路として使用する。このようにIrTran-P 規格はIrDA 規格と若干の距離を置くことでさまざまなシチュエーションの応用に適合できるメリットを持っている。

bFTP 層のサービス(ISO モデル)SCEP 層のサービス(ISO モデル)なぜSCEP とbFTP に別れているのか

IrTran-P のアプリケーションプロトコルは、前途のようにSCEP とbFTP の２

つのレイヤーにより構成されている。単純に画像を転送するだけであれば、一つの層にすべてを実装してしまったほうがプロトコルが簡単になると考えられる。しかしながら、IrTran-P は下位層に対して信頼できるデータストリームを要求しているだけであり、そこにセッションという概念があるかどうかをあえて問うことをしていない。IrDA 規格において、IrLAP はデータリンクを保証し、IrLMPはリンクマネージメントを保証する。TinyTP はフロー制御のみであり、IrCOMMはシリアルポートのエミュレーションである。IrLAP には、接続時に物理レベルでの折衝を行うが、通常のセッション層に要求される相手局の認証などの手順は行わない。IrLAP の接続時に交換される、コネクションパラメータにアプリケーション層において、認証パラメータを乗せてセッション関係のデータを交換することも可能であるが、IrCOMM というアップリケーションが他の目的のためにコネクションパラメータを使用しているので、さらにその上位層からコネクションパラメータを利用することはできない。SCEP は、信頼のおけるバイトストリーSCEP SCEP Services

bFTP bFTP Services

User Application SCEP Services

SCEP SCEP Services

SCEP Services

ことを担当している。SCEP は、その名のとおり、簡単なコマンドを交換するプロトコルを与える。SCEP は、５つのプロトコルサービスを提供し、独自の状態遷移によってプロトコルが動作する。SCEP は、セッションに関係する２つのサービスである、S_Connect およびS_Disconnect と、コマンドに関係する、S_Command とS_CommendID およびS_Abort の３つのサービスを提供している。

S_Connect はセッションを確立するために使用され、S_Disconnect は、セッションを切断するために使用される。IrTran-P の下位層の接続、切断プロトコルとともに使用される。いっぽう、S_Command は抽象的なコマンドを双方向で交換できる手順を上位層に提供する。S_Command を発行すると、それに付随して、S_CommandID サービスが指示(Indicate)される。またコマンドを中断するためにS_Abort コマンドも使用される。

bFTP は、SCEP のサービスプロトコルのうち、コマンドに関係するS_Command とS_CommendID およびS_Abort の３つのサービスを使用し、SCEP の上位層で、バイナリーデータの交換プロトコルを実現する。実現するサービスは、２つである。一つは、バイナリーデータを起動側（イニシエーター）が送信することのできるF_Put サービスである。F_Query は、起動側（イニシエータ）が、応答側（レスポンダ）に対しての問い合わせを可能にする。

SCEP からみると、F_Put もF_Query も単なるS_Command の交換交換に過ぎない。S_Command に意味を持たせるのはbFTP 側の仕事となる。セッションプロトコルであるSCEP とファイル転送プロトコルであるbFTP に分けることにより、それぞれのプロトコルの状態遷移などの内部状態は、一つのプロトコルのそれに比べるとシンプルになる。SCEP のしくみを見ると、複数の上位層が存在できることに気づくであろう。このことからわかるように、IrTran-Pの採用しているプロトコル手法は、セッションレベルおよびアプリケーションレベルの拡張を容易にしメンテナンスやテストをしやすくしていることが分かる。

以上のことから、なぜSCEP とbFTP が必要になるか理解できたことと思う。

IrTran-P がむやみに複雑なプロトコルを選択したり、意味もなくプロトコル層の

構成を歪めたりしていないことが理解いただければ幸いである。SCEP (Simple Command Execute Protocol)サービスの定義SCEP は、接続と、コマンドの管理を行う。サービスモデルSCEP は前に述べたように、５つのサービスを定義する。また、下位層には、Open,Close,Read,Write の４つのサービスを要求する。SCEP サービス SCEP サービスは、SCEP のユーザに対して５つのサービスを提供するSCEP接続の管理、コマンド管理およびコマンドの分割再構成を管理する。

SCEP は、PDU サイズを超えた大きなサイズのコマンドの実行を可能にするために大きなコマンドを分割し送信し、受信側で再構成する機能を持っている。Commandサーバー上で実行されるレメントであるCommandIDコマンドを実行する際に発行されるID であり、コマンドの実行単位ごとに割り振られる。MachineIDマシンID とは、その装置を識別するために使用する個別のID である。このID はIEEE EUI64 フォーマットで構成される。マシンID のすべてが0x00 であるばあいはマシンID がないことを意味する。マシンIDは８バイトで構成される。

PID PID はサーバーにあるアプリケーションを識別するために使用される。このID は上位のアプリケーションに固有のID である。SCEP SCEP Services

SCEP Services

SCEP は次のサービスを供給するn Connect接続n Disconnect切断n Commandコマンドn CommandIDコマンドID n Abortアボート接続サービスS_Connect.req (Primary MachineID,Secondary MachineID,Primary CFLG,Primary NegInf)S_Connect.ind (Primary MachineID,Secondary MachineID,Primary CFLG,Primary NegInf)S_Connect.rsp (AckOrNackFlag,Primary MachineID,Secondary MachineID,Secondary CFLG,Secondary NegInf)S_Connect.cnf (AckOrNackFlag,Primary MachineID,Secondary MachineID,Secondary CFLG,Secondary NegInf)接続サービスは、SCEP 同士のピア接続を確立する。このサービスは確認(Conf)を持つ。

接続の許可不許可は、AckOrNackFlag により交換される。パラメータ：PrimaryMachineID, SecondaryMachineIDマシンID は、既に述べたように、その装置の固有のID である。接続を試みる側のID はPrimary MachineID であり、接続を受け付ける側のID が Secondary MachineID である。CFLGこのフラグは、A flag indicating whether or not being able to be Responder. If not being able to be Responder, neither Req PDU nor Rqs PDU is acceptable.NegInf折衝情報は、接続時のPDU サイズやその他の情報を交換するために使用される。

AckOrNackFlagこのフラグは、受付の合否を示す。Ack接続を受け入れたことをあらわすNack接続が拒否されたことをあらわす切断サービスS_Disconnect.req( ReasonCode )S_Disconnect.ind( ReasonCode )切断サービスは、SCEP 同士に確立した接続を終結させる。このコマンドは確認なく受け付けられる。パラメータ：ReasonCode理由コードは、切断理由を上位相に通知する。

Unspecified Reason未定義の理由User Disconnectユーザの意志で切断したProvider Disconnect下位層による切断S_Connect.req S_Connect.ind S_Connect.rsp S_Connect.cnf Primary Secondary SCEP Servicesコマンド サービスS_Command.req (Requester MachineID,Responder MachineID,Requester PID,Responder PID,UserData)S_Command.ind (Requester MachineID,Responder MachineID,Requester PID,Responder PID,CmdID,UserData)S_Command.rsp (AckOrNackFlag,Requester MachineID,Responder MachineID,Requester PID,Responder PID,CmdID,UserData)S_Command.cnf (AckOrNackFlag,Requester MachineID,Responder MachineID,Requester PID,Responder PID,CmdID,UserData)コマンドサービスはSCEP ユーザ同士がコマンドとその結果を交換するために使用する。

パラメータ：RequesterMachineID, ResponderMachineIDコマンドを発行する側のマシンID をRequester MachineID、コマンドを受理する側をResponder MachineID とする。S_Disconnect.req S_Disconnect.ind SCEP Services S_Disconnect.ind S_Disconnect.ind SCEP Services Primary Secondary Primary Secondary‘User Disconnect’ or‘Unspecified Reason’‘User Disconnect’ or‘Unspecified Reason’‘Provider Disconnect’ or‘Unspecified Reason’‘Provider Disconnect’ or‘Unspecified Reason’S_Disconnect.req S_Disconnect.ind SCEP Services Primary Secondary‘User Disconnect’ or‘Unspecified Reason’‘User Disconnect’ or‘Unspecified Reason’RequesterPID, ResponderPIDコマンドを発行する側のマシンにあるアプリケーションのID をRequester MachinePID、コマンドを受理する側のアプリケーションID をResponder MachineID とする。bFTP を実行するアプリケーションのPID は 8 とする。

UserDataユーザが交換するデータAckOrNackFlagコマンドの実行結果を表す。Ackコマンドが正常に完了したことを通知する。Nackコマンドが以上終結したことをあらわす。コマンドID サービスS_CommandID.ind (Requester PID, Responder PID, CmdID)コマンドを発行する単位ごとに発行側のアプリケーションに対して個別のコマンド発行を識別するためのコマンドID をSCEP が生成する。その場合に、このサービスによって子コマンドID を通知する。

パラメータ：RequesterPID, ResponderPIDコマンドを発行する側のマシンにあるアプリケーションのID をRequester MachinePID、コマンドを受理する側のアプリケーションID をResponder MachineID とする。CmdIDコマンド固有のID である。これは、S_Abort コマンドで使用される。アボート サービスS_Abort.req ( Requester MachineID,Responder MachineID,Requester PID,Responder PID,CmdID )S_Abort.ind ( Requester MachineID,Responder MachineID,Requester PID,Responder PID,CmdID )このサービスは、実行中のコマンドをアボートさせる。

RequesterMachineID, ResponderMachineIDコマンドを発行する側のマシンID をRequester MachineID、コマンドを受理する側をResponder MachineID とする。RequesterPID, ResponderPIDコマンドを発行する側のマシンにあるアプリケーションのID をRequester MachinePID、コマンドを受理する側のアプリケーションID をResponder MachineID とする。

CmdIDアボートさせるコマンド固有のID S_Command.req S_Command.ind S_Command.rsp S_Command.cnf SCEP Services Primary Secondary Requester Responder S_Command.req S_Command.ind S_Command.rsp S_Command.cnf SCEP Services Primary Secondary Responder Requester S_CommandID.ind S_CommandID.ind S_Abort.req S_Abort.ind SCEP Services Requester Responder S_Abort.req S_Abort.ind SCEP Services Requester Responder bFTP (binary File Transfer Protocol)サービス定義bFTP は、１対1 のファイル転送サービスと問い合わせ機能を提供する。

サービス モデルbFTP Services bFTP が供給するサービスbFTPファイル転送を供給するプロトコルSCEP Services SCEP の供給するサービスSCEP SCEP Services

bFTP bFTP Services

User Application SCEP Services

Query （問い合わせ）サービスF_Query.req (Responder MachineID,Requester MachineID,Requester PID,What)F_ Query.ind (Responder MachineID,Requester MachineID,Requester PID,What)F_ Query.rsp (AckOrNackFlag,Responder MachineID,Requester MachineID,Requester PID ,Result)F_ Query.cnf (AckOrNackFlag,Responder MachineID,Requester MachineID,Requester PID ,Result)Requester PID F_Query.req を発行するアプリケーションID.Whatなにを問い合わせるのかを記述するRIMG画像に関する問い合わせRINF応答側の状態の問い合わせRCMD 実行可能コマンドの問い合わせAckOrNackFlag問い合わせの合否を示すResult AckOrNackFlag がAck の場合は、問い合わせ結果。

AckOrNackFlag がNack の場合はエラーコードF_Query.req F_Query.ind F_Query.rsp F_Query.cnf bFTP Services Requester Responder Put サービスF_Put.req ( Responder MachineID,Requester MachineID,Requester PID,FileName,UserFileName,Time, FileHeader,Thumbnail,File)F_Put.ind ( Responder MachineID,Requester MachineID,Requester PID,FileName,UserFileName,Time,FileHeader,Thumbnail,File)F_Put.rsp ( AckOrNackFlag,Responder MachineID,Requester MachineID,Requester PID ,Result)F_Put.cnf ( AckOrNackFlag,Responder MachineID,Requester MachineID,Requester PID ,Result)Requester PID F_put を発行したアプリケションID FileName ASCII 8.3 フォーマットのファイル名UserFileNameロングファイル名TimeファイルのタイムスタンプFileHeader未使用Thumbnail画像サムネイルFileファイル本体AckOrNackFlag Ackコマンド実行成功Nackコマンド実行失敗Resultもし、AckOrNackFlag が Ack 場合は、受け取り側のファイル名もし、AckOrNackFlag がNack の場合は、エラーコードF_Put.req F_Put.ind F_Put.rsp F_Put.cnf bFTP Services Requester Responder

応用編のまとめ

応用編では、基礎編で学んだIrLAP、IrLMP、TinyTP 上に構成されるプロトコルである、

IrCOMM、IrOBEX について学んだ。この２つのアプリケションはシリアルポート／パラ

レルポートのエミュレーションと、ファイルおよびオブジェクトの交換がIrDA で可能となった。さらに、具体的なIrDAプロトコルの例として、ミドルウェアの実装ケースとWindowsにおけるIrDA の実装としてのIrSock について検証した。これにより読者は、IrDA 製品側のドライバーについての具体的な構成と、IrDA のクライアントとしてのパソコン側、PDA側のプログラミングについても学んだ。これらの知識をベースとして、さらに上位のアプリケーションであるIrMC およびIrTran-P についても深く解説をした。ここでは、IrDAのキラーアプリケーションがどのようなコンセプトとユーセージモデルを想定してプロトコルを応用しまた拡張する必要があるのかを理解することができたと思う。

一つの通信プロトコルを学ぶことによって、そこに息づくさまざまな時代の要求、技術の発展、市場との駆け引きなどさまざまな要因がプロトコルの構成に関わってきているのかがわかる。IrDA 規格は、その生まれから、かなりアカデミックな要素の強い技術者の集まりから生まれたため、かなり技術的には高度な内容となっている。IrDA 誕生して３年が過ぎたころには、現実の実装に対して、IrDA は異常に複雑すぎるとか、もっとシンプルにするべきだという意見が合ったが、いまを振り返ってみると、意外と現在の電子工学の技術的進歩を先取りしていたともいえるだろう。

１９９９年の今年は、本当の意味で、IrDA を搭載した装置が市場をにぎわしはじめている。長年、IrDA に関わってきた筆者としては、５年がやはりこのような新しい通信規格の節目であると実感している。筆者は、現在でもIrDA において、次のアプリケーション規格の制定に関わっているために本書にかける時間がかぎられてしまったことを率直におわびせねばならないだろう。そのために、現行の進みが芳しくなく、出版社のみなさまにご迷惑をかける結果となった。

しかし、その遅れの代償として、Windows 2000 などの最新の情報を盛り込むことができたのは幸運であったといえよう。さいごに、本書がきっかけとなって新たなIrDA に参加される方が生まれ、新たなIrDAのプロトコルを生む種となれば、筆者としてうれしい限りである。