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

赤外線を使用したコードレス通信は、家電製品のリモコンをはじめとしてすでに一般的なものになっている。しかしながら、多くの赤外線通信方式は各メーカが独自に開発製品化したものであり互換性に乏しい。すでに家電で採用されている赤外線通信方式は1000 種類以上であるとも言われている。従来の電気通信といわれているものは、特定の装置や媒体、利用目的を限定した通信方式を想定して構築され、実用化されていった。しかし、現在では、家電、計算機、電気通信網という従来の枠の中で通信を考えることは無意味になってきている。なぜなら、現在の身の回りに存在するあらゆる電化製品にはマイクロコンピュータが搭載され「インテリジェント化」されていて、かなりの規模のデータや処理システムが備わっているという状況がカテゴリやジャンルの分類をなきものにしているからである。

そのような時代背景の中で、通信というものが特に注目されているのは、あらゆる電化製品や装置において「データの流通」という問題が常に付きまとっているからであり、新たに生まれてきたテクノロジーの結果ではない。従来なら単独の装置として閉じていたシステムが相互にデータを交換することでより便利で、高度な応用が可能になることがわかっているからである。本書は、長い歴史を持った赤外線通信方式の終着駅ともいえる国際規格であるIrDA 赤外線通信規格を学び取ることを目的とする。赤外線通信は、従来の電気通信にあてはまらない特殊性を持っている。そこで、IrDA 規格がどのようなモデルを想定して規格化されいったか、従来の電気通信の基盤となっている通信プロトコルを赤外線通信でどのように適合していったかについても論じた。どのような規格であってもそれは、規格化の歴史の1 ページにすぎない。こなれた規格を想像力によって進化、発展させていく試みが新しいインフラを誕生させる原動力である。IrDA 規格の理解もこの流れにそって考えるべきであろう。

本書は、通り一遍にIrDA 規格を紹介するものではない、IrDA 規格のを理解する上で必要となる予備知識や関連する通信規格、通信規格などを含めて平易に説明し、IrDA規格書と本書だけで、初学者や技術者にもIrDA 規格の理解ができるように配慮したつもりである。

▶0.1 IrDA規格とその周辺

赤外線通信といっても、その活用範囲は幅広い。ＰＨＳ、プリンタ、モデム、LAN などのケーブル置き換えをまず想定するだけでも、通信速度や、装置の能力や応用範囲は多岐わたっているので、通信速度、コストなどを考えると通信方式に柔軟性がなくてはならないことがわかる。しかも、赤外線通信はケーブル接続による確実な通信でないため、外光や、物理的な遮断など物理的な信頼性が低い。これらの技術的な問題をIrDA の通信方式ではどのように解決しているのだろうか。

また、コストの問題も考えなくてはならない。PHS や、ポケットプリンタなどは、搭載されているマイコンなどの能力やメモリが小さいため、LAN などの高速な通信よりも通信に必要となるハードウェアやソフトウエアコストが小さくなることがのぞまれる。一方、光通信でのLAN 接続の場合コストよりも速度とパフォーマンスを要求されるだろう。この矛盾をどう解決するかが、利用価値のある通信規格の第一歩といえる。IrDA の通信方式には赤外線通信をおこなう装置の能力情報を通信開始時に情報を交換し合い最適な通信速度や、一度に送受するデータ量などを調整することができる機能が備わっている。

耳慣れない言葉であるが、IrDA の規格であるディスカバリー（発見）と呼ばれる手順がその機能である。接続する相手の名前や装置の基本的な種別を接続前に判断する機能や、 複数のIrDA 装置がパソコンの周辺にある場合は要求された装置を識別して接続することもできる。通信速度もIrSIR と呼ばれる方式では9600bps から、4Mbps の高速通信も可能となる。これらのフレキシブルなIrDA の規格のおかげで、様々な周辺装置がノートパソコンや、ＰＤＡなどの自由に、そして、その通信に見合ったコストで携帯情報端末に接続することが可能になる。

通信技術に必要とされるのは、「信頼性のある通信方式」の確保と、実際的な応用にむけての「機能的な通信手順」である。IrDA の提唱する標準化の中で、赤外線通信の高速 性と信頼性を確保するためにIrLAP (IrDA Link Access Protocol)と呼ばれるHDLCに似た通信手順を制定している。これは、半二重の連続したデータを高速に転送することを 主眼においた手順であるといえる。先ほど説明した、発見手順もこの規格の中に含まれている。その上位には、複数の装置を識別するためのIrLMP (IrDA Link Management Protocol)がある。接続する相手の固有情報サービスや、複数の装置のやり取りなどをつかさどる。 さらに、その上位には、装置のデータフロー制御をつかさどるTinyTP (IrDA Tiny Transport Protocol)がある。接続する相手がデータを受け取れない場合などの調停に使用される。その上位には、応用として、従来のRS232C や、セントロニクスプリンタの通信をIrDA規格上でシミュレートするIrCOMMや、IrDAの規格のパフォーマンスをLAN 上で最大限に生かせるLAN を構築するためのIrLAN(IrDA LAN)などの多くの通信プロトコルが提唱されている。IrDA 規格も、基本的には、ISO/IEC の提唱しているOSI のプロトコルスタック（OSI 参照モデル）の構造を踏襲している。今後、さまざまな装置がIrDA を採用されるに従い、IrDA の規格のに様々な装置を接続できる規格が次々に現れてくるだろう。IrDA は、特定の企業の規格ではないため、今後もはばひろい分野で採用されていくにちがいない。また、日本国内では、IrDAの規格を幅広く告知するために、電信電話技術委員会TTCの第4部会で日本の標準化を進め、いくつかのIrDA 規格はTTC 標準になっている。

▶0.2 モバイル・コンピューティングと赤外線通信

▶0.2.1 携帯情報機器の現在

電子ブック、携帯電話、PHS、携帯パソコン、携帯情報ツールなど、この数年の間にアウトドアやモバイル環境でも使える携帯情報機器が爆発的に売れるようになった。読者のかたも、このなかのどれか１つ以上はお持ちのことだろう。これらの携帯情報機器の便利なところは、ＴＰＯを選ばずに「いつでもどこでも」利用できるからだ。オフィスでも家庭でも、情報化がすすみ情報がどんどん電子化されつつある現在、アウトドア、インドアに限らず個人生活にもこの電子化の波がどんどん押し寄せてきている。個人の利用する携帯情報機器がたくさん発表されるのは喜ばしいが、それらの装置間で簡単に情報のやり取りができなくてはこまることがますます多くなる。なぜなら、「情報機器」という名前が物語るように、一つ一つの情報機器には、個人にとって重要な情報が数多く貯えられているからだ。

せっかく集めた情報も分散したり、重複したりでは、面倒は増えるばかりだ。たとえば、携帯電話には電話番号簿があり、同じ情報が携帯情報ツールには住所録に、会社や家庭のパソコンにはそれとは別に存在している場合などは、困ったことが起こる。もし、貯えられた情報の交換手段がなければ、同じ内容の情報を三回も、「手で別々に打ち込む」ことになってしまう。また、携帯パソコンで、出張の移動中に書類のミスを発見して修正したとしても、客先のプリンタに簡単に接続して、打出すことができなければせっかくの携帯パソコンの意味がなくなってしまう。たとえ小さな情報ツールとしても「データの流通性」が保証されなくては、「情報機器」の便利な活用は半減してしまうデータの洪水でおぼれてしまうかもしれない。

▶0.2.2 ケーブル接続のデメリット

携帯情報機器あっても、デスクトップ並みの周辺装置とやり取りをしたいと考えるのは当然の成り行きだろう。電話回線、ISDN、LAN、プリンタ、ＣＤＲＯＭなどの周辺装置と接続できるからこそ情報装置としての意味がある。デスクトップパソコンであれば、固定して使うため、ケーブル接続は一度限りの面倒だが、携帯情報装置だとそうはいかない。接続する相手ごとにさまざまなケーブルが必要になるし、付けたりはずしたりが面倒くさい。どこでもデスクトップなみの通信環境を用意しようとすれば、かばんの中はＰＣカードとケーブルで占領されてしまう。新しい情報ツールが増えるたびに、新しいＰＣカードやじゃまなケーブルが増えていく。これでは、便利なモバイル・コンピューティングも一部のパワーユーザだけのものになってしまうだろう。そのうえ、技術が高度化して、携帯情報機器がより小さくより多機能になれば、ケーブルをつなぐためのコネクタさえつける場所さえなくなってしまうだろう。

▶0.3 情報装置の赤外線利用

テレビやクーラーのリモコンは、赤外線を使用した通信技術の応用製品である。リモコンのボタンを押すと、ボタンごとに異なる赤外線の信号が発信される。テレビやクーラーに取り付けられた赤外線センサーはその信号を受信するとボタンに対応した動作をするわけだ。このリモコン技術は素朴な単方向の通信であるが、この技術を双方向にして情報通信に利用した赤外線通信がにわかに注目されてきた。卑近な例では、シャープの発売している携帯情報ツール「ザウルス」の光通信がある。赤外線を使って、ザウルス同士で名刺の交換や、文書のやり取りが簡単にできる。これ以外にも、業務用としてＰＯＳ端末のデータエントリマシンなどの通信に現在でも応用されている。

現在までに多くの赤外線通信や無線通信方式が多数実用化されているが、これらの通信方式は、特定の用途を目的として開発されているため、幅広い利用を可能とするものではなかった。しかし、赤外線通信は、コストが安いこと、電波を使用しないためにさまざまな法的な規制を受けにくいことなど多くの利点があるため業界の各方面で汎用化、実用化を目指して開発が展開されていった。

▶0.3.1 国際業界団体IrDAの登場

そのような状況の中で、赤外線通信を応用した携帯情報機器のケーブルレス化を目標にIrDAという、業界団体が1993 年６月から活動を開始した。IrDA (Infrared Data Association)は、Hewlett-Packard 社、IBM 社、シャープ、NTT などを中心に赤外線通信技術の標準化を目指している国際的な企業団体である。現在では１4０社を越える。パソコン、ＰＤＡ、プリンタ、電子部品、電話会社、自動車関連メーカ、ＬＳＩメーカやソフト開発会社が参加している。

▶0.3.2 IrDAの沿革

IrDA の規格の歴史をたどると、実用的なＰＤＡの元祖ともいえる、Hewlett-Packard 社製HP 100LX の赤外線通信方式にさかのぼることができる。HP 100LX には、HP-SIR という規格の光通信機能が内蔵されていた。この赤外線通信の特徴は、最大で115Kbps の通信速度をもち、赤外線ダイオードの発光時間が少ない方式を採用しているために、省電力で、そこそこの通信速度（115200bps）での赤外線通信や、ファイル転送がが可能である。また、通信可能な範囲が0cm から1m までと、限定されているが、ケーブルの置き換えと考えれば、携帯情報装置間の通信方式としては非常に便利であった。この規格をベースにHP 社は、自社のプリンタにIrDA を搭載し、IBM 社ぱThink-Pad などのノートパソコンに早々と1Mbps の赤外線通信機能を搭載した。

IrDA の通信方式が注目を集めだしたのは、W 指示ows 95 で正式に採用され、OS 内部にIrDA赤外線通信機能がとりこまれたことにあるだろう。新たなアプリケーションを搭載しなくても、赤外線を使用して、プリンタ、LAN、モデムと接続する機能を W指示ows95は持っているためだ。また、1996 年の秋口からは、ノートPC の通信速度について9,600bps-115,200bps の段階から、IrDA規格の高速通信規格である1.15M,4MBPSの高速赤外線通信に移行しはじめた。その後、小型端末である W指示ows-CE Ver2.0,そして、W指示ows98もともにの高速版IrDA規格の正式採用などにより、現在、市場にあるノートPCの9割にIrDAが搭載され、W指示ows98対応のノートPCは高速版のIrDA が搭載されるにいたるようになった。W 指示ows98,NT5.0,CE には、IrDA をネットワーク通信のひとつとして考えられたIrSock という共通の通信サービス機能を内蔵している。してがってこの機能を使えばIrDA 規格の細かなサービスが自由に使用することだ出来る。

PC や、携帯端末側に赤外線通信ポートが搭載されるようになり、1997 年あたりから、その通信手段を通じてメリットが生まれるような対向するソリューションが多方面で開発されるようになった。その先鞭をきって登場したのが、赤外線通信利用したデジタルカメラ間の画像転送方式である「IrTran-P :Infrared Transfer Picture 」と、携帯電話の通信規格である「IrMC Infrared Mobile Communication」の２つの規格である。1997 年10 月にIrDA 規格として制定された。

▶0.3.3 IrDA規格のパラダイムシフト

IrDA の規格はPC 対PC の発想で始まったために、PC を基軸とした、PC 対周辺機器での利用という構図が暗黙のうちに出来上がってきたと思う。しかし、IrDA の通信方式は、通信能力の差を解消する、「見えないケーブル」を携帯電子機器や小型民生機器が手に入れたとも解釈できる。つまり、ＰＣを軸とした応用の構図から、なにも中心にないフラットな赤外線通信利用の構図が応用面ではっきりと認識されてきた。このような赤外線通信の利用構図にIrDA 規格の見方を変えていくと、無限の応用が可能になると筆者は考える。

さきに挙げた、新たに制定されたこのIrTran-P とIrMC の2 つの規格は、従来のIrDA 規格と大きくパラダイムシフトが行われていることに注目したい。従来のIrDA のアプリケーションで想定していたのは、「PC と周辺機器のケーブルを赤外線に置き換える」ことが中心のモデルであった。しかし、IrTran-P 規格で目を見張るのは、PC を介さずに、カメラ－カメラ間、カメラ－プリンタ間などで赤外線を利用して画像を転送することに主眼を置いていることである。またIrMC でも、PC とのやり取りも重要な機能として考えられているが、メッセージや、電話番号簿の交換を携帯電話－ポケベル間でも行えるように工夫されている。つまり、赤外線通信の手軽さをPC 以外で積極的に活用しようとした試みであるといえよう。

1998 年の現在、データ端末腕時計に関する赤外線通信規格(IrWW Infrared wrist watch)であるとか、自動車内LAN 規格とIrDA 規格のゲートウェイ規格であるとか、PC オリエンテッドな規格から離れて、赤外線通信の真のメリットを生かした規格が次々にIrDA で討議されてきている。

1. OSI参照モデルとIrDA規格

さて、少しIrDA規格からはなれて、通信に関する基本的な考え方を整理しておこう。最新の通信テクノロジーの基本的な考え方は共通化されている。したがって、IrDA 規格を理解するためにもIrDA 規格の詳細に入る前に一般的な通信の概念を学ぶことは大切なことである。現在、インターネットから携帯電話の通信に至るまでさまざまな通信方式が具体化し、利用可能である。しかも、これらの通信システムを利用したさまざまなサービスやアイデアが次々に現れ実用化されている。インターネットを例にあげれば、メールの交換からはじまり、WWW に見られるよな、画像、音声の複合的なデータ通信、そして、インターネット電話、インターネットテレビ電話とその技術革新のとどまるところを知らない。では、なぜインターネットシステムが次々に新しいメディアを開拓していくことができるのだろうか。確かに、ISDNやATMなどの新技術によりデータ通信の高速化が図られているのはわかるが、それらの新しい技術が、古いシステムと矛盾せずに共存する技術的なキーアイデアは何なのであろうか。いまだに古いモデムと電話線でメールをやりとりすることだって可能なのはなぜか。

ここで必要な基本的な考え方として「通信の目的」と「通信の手段」が別物であるという認識である。通信の目的が、映像を送ることや、音声を送ること、そしてデータを送ることなどとさまざまな目的であったとしても、「通信の目的」は、「通信の手段」を限定するものではない。たとでば、画像データを通信で送るという概念において、手段として、電話回線やISDN 回線を使っての通信なのか、赤外線を使っての通信なのか、LAN を使用したワークステーション同士の通信なのかは「通信の目的」から考えれば本来的ではない。むしろ完全に独立であることが望ましいのはいうまでもない。

このことは、抽象的な意味において、通信システムには、通信の概念においてのいくつかの「抽象的な層（機能のあつまり）」を持たなければならないことを意味する。小規模な通信システムや従来の問題発生解決的な通信システムの概念ではこのような抽象的なアプローチはなかなか実現しなかったが、最先端の通信システムはこのような、データ通信における抽象的なサービス層をきっちりと定義した上で、各階層を具体化していくというアプローチがとられている。

新たな通信方式を学び理解する上で必要なことは、これらの抽象化されたおのおのの通信の階層的な構造を理解することである。現在、さまざまな通信方式が実用化しているが抽象的な部分に関してはほとんどにかよている。そのベースになっているのがOSI 参照モデルである。赤外線通信規格であるIrDA 規格を理解するためにもOSI 参照モデルの理解が必要となる。まずは手始めとして、OSI 参照モデルについて調べてみることにしよう。

▶1.1 規格書の読みにくさの本質

規格書を読むと、「規格を実装するための実体」はわかるが、「なぜそのような方式を採用したのか」とか、「どのように使えばいいのか」についての記述はすくない。そのために、抽象的な用語や記述に翻弄されてしまって、初学者や、一般の技術者にとって、規格書は読みにくく、わかりにくいものになっている。規格書は、いわば法律書と同じで、「記述の正確さ」、「再現性」を中心として構成されており、規格を理解する上で必要とされる概念規定や考え方を記述しているものではない。概念規定を必要とする場合の多くは、規格書の正確さをきすために、基本的な概念や抽象化はOSI 参照モデルなどの通信の基本的な規格を参照し、その規格の出典を記載するにとどめていることが少なくない。

通信に関する規格のモデルはそれぞれの規格が単独で存在するのではなく、共通したモデルや概念の上に成り立っている。ほとんどの通信規格は、ISO（International Organization for Standardization 国際標準化機構）とIEC(International Electro-technical Commission 国際電気標準化会議)の合同技術委員会JTC1(Joint Technical Committee One)の提唱しているOSI(Open System Interconnection 開放型システム間相互接続)参照モデルを基本として定義さている場合が多い。IrDA 規格のプロトコル記述もOSI の記述に準拠している。ここでは、OSI 規格で想定しているプロトコルモデルについて学習し、IrDA 規格書を読むための準備をしておこう。

IrDA 規格もそうであるが、多くのプロトコルがOSI 参照モデルを利用するのは、「プロトコルの実体定義の仕方」が優れているためで、IrDA 規格の場合も、格階層におけるプロトコルモデルと定義において、OSI参照モデルを活用しているに過ぎない。したがって、ここでくどくどとOSI参照モデルについて立ち入ることはしないで、IrDA 規格を理解するに必要な基本的な概念の要点を学習する。

▶1.2 OSI参照モデルの基本概念

OSI参照モデルを理解するためには、通信システム階層化という概念と階層化された通信階層ごとの実体であるエンティティの理解が重要になる。

▶1.2.1 階層化の概念

最終的な目的を達成するための「アプリケーション層（ユーザから見える通信）」から最終的な情報の乗り物としての「物理層（具体的な伝達の手段）」には、大きな隔たりがある。たとえば、電話をかけているものにとって、電柱に敷設されている電話線のことを意識する必要はない。しかし、電話会社に勤務している保守職員にとっては、電柱にある電話線の一本いっぽんに関心があるに違いない。複雑な系を理解し応用するためには、議論すべきの実体を「相互に密接な機能の複合体(集合)」として合理的に区分けし階層化することが大切なアプローチとなる。また、区分けの指標は、「相互に密接な機能の複合体」をどう捕らえるかで変わってくるが、より抽象的な機能や概念は上位層に、より細かい問題は下位層に分離することで複雑な系を比較的単純な概念集合の階層的なの積み重ね（スタック）として考える。

OSI 参照モデルというと、７階層のモデル（物理層、データリンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層、アプリケーション層）を思い浮かべると思うが、TCP/IPをはじめ、業界標準(デファクトスタンダード)となっている規格は、歴史的な要因、応用分野での物理的な制限などからOSI参照モデルにおける階層について正確に適合していない場合が多い。これは、IrDA 規格の場合も同様である。しかし、ISO 参照モデルで規定している階層は、「プロトコル階層化の指針」としての意味があるため、多くの業界標準で採用されている。

▶1.2.2 通信の実体 エンティティ(Entity)

OSI 参照モデルの各階層における「通信の実体」のことを「エンティティ(Entity)」とよび、プロトコル間のやりとりはすべてこのエンティティを主体として行われる。つまり、エンティティの中に該当するプロトコルのすべてが詰まっており、エンティティーの外から見える部分にアクセスすることで通信を実現する。エンティティには、「エンティティ間のサービス関係」、「エンティティの通信路」、「エンティティの内部状態状態」「情報フォーマット」などが規定される。IrDA 規格の各階層についてもこのエンティティ単位で記述されている。

通信の規格書というものは、簡単に言ってしまえば、このエンティティをいかに正確に定義していくことに尽きるともいえる。そこで、OSI 参照モデルを理解するため、章をあらためて通信の主体であるOSI 参照モデルのエンティティの概念とIrDA 規格との関係について論をすすめることにしよう。

▶1.2.3 通信の主体OSIのエンティティとIrDA規格

通信の主体（実体）としてのエンティティには、前章で述べたように「エンティティ間のサービス」、「エンティティの通信路」、「エンティティの内部状態と事象／行動の記述」「情報フォーマット」が規定される。IrDA規格を学ぶ上でもこの概念は随所に登場し、プロトコル定義の要になる部分といえるのでしっかりと理解することが重要である。

▶1.2.3.1 エンティティ間（N層N-1層 間）のサービス

相互に接している格階層間の通信のことをOSI 参照モデルでは「サービス」といいう。エンティティとの具体的なやり取りは、すべてこのサービスを使って行われる。オブジェクト指向の概念で考えればメソッドに該当する概念と言ってもよい。

▶1.2.3.2 サービス・ユーザとサービス・プロバイダ

下層で提供するサービスを受ける上位層のことを「サービス・ユーザ」といい、下層でサービスを提供する側を「サービス・プロバイダ」という。エンティティを上から眺めれば、「サービス・プロバイダ」であり、エンティティそのものは、下位層の「サービス・ユーザ」となるわけである。これが層をなして、全体としての通信サービスを提供することになる。OSI 参照モデルで、現在議論している階層のエンティティのことを単に「N 層」という表現を使い、下の階層を「N-1 層」と表記する場合が多い。上位層はいうまでもなく「N+1 層」という表現になる。

▶1.2.3.3 要求側ユーザと受諾側ユーザ

通信の目的は、通信経路を媒介とした向こう側に情報を送ることにあるから、ある層（N 層）のサービス・ユーザがサービス・プロバイダー（N-1 層）に発行した情報は、結果として、相手側の同じ層（N層）に位置するサービス・ユーザに発信された情報が通知されることになる。そこで、サービスを発行(要求)する側を「要求側ユーザ」とよび、サービス・プロバイダを経由してサービスの通知を受け取る側を「受諾側ユーザ」として定義しておく。ただし、要求側ユーザと受諾側ユーザは通信中に交互に入れ替わる。概念的には、１つのサービスを実行するにあたっての瞬間的なものとかんがえておく。

OSI 参照モデルをある層で輪切りにすると、「要求側ユーザ」、「サービス・プロバイダ」、「受諾側ユーザ」という関係が常に成り立っており、「サービス・プロバイダ」の下位に存在するエンティティについては、この階層における「サービス・プロバイダ」が掌握しているとみなされるため、要求側と受諾側のサービス・ユーザ（N 層）は、下位にひとつの「サービス・プロバイダ（N-1 層）」あると考えればよい。

▶1.2.3.4 サービス・プリミティブとサービス・アクセス・ポイントSAP

エンティティの用意するサービスの一つひとつのことを「サービス・プリミティブ」（単にプリミティブ）といい、実際にエンティティに対してやり取りするための具体的な方法は、すべてこのサービス・プリミティブによって実現される。サービス・プリミティブは、隣接する階層（N層とN-1層）の接点である「サービス・アクセス・ポイント(SAP Service Access Point)」に対して発行されることを覚えておこう。サービス・アクセス・ポイントSAP は、IrDA 規格でも広く登場する概念である。サービス・アクセス・ポイントは、階層間のインターフェイス点であり、そこにおける各種の条件をインターフェイス条件と呼び、エンティティの固有の要素としての条件が定義されている。（通信サービスの品質、信頼性などを規定するパラメータ）

サービス・プリミティブは、いわばアプリケーションプログラムがオペレーティングシステムやサブシステム（ランタイムサービスや、サブルーチン集）にサービスを要求するときに使用するAPI に該当するものである。実際、ベンダーが提供するプロトコルを使用する場合は、サービス・プリミティブをAPI化したものを使用することになるだろう。しかしながら、OSI 参照モデルの場合、サービス・プリミティブは、サービスを提供するための手段ではなく、提供されるサービスそのもののみを記述することを抽象化したものであると定義している。

つまり、サービス・プリミティブ定義は、あらゆる特定のインタフェース実装から独立である。したがって、これらのプリミティブは特定API を構成するものではないことを頭においておこう。

▶1.2.3.5 要求／指示／応答／確認

サービス・プリミティブと、オペレーティングシステムやサブシステムが提供するAPI と大きく異なる点は、発信側のサービス・ユーザが、サービス・プロバイダに対してサービス・プリミティブを実行すると、サービス・プロバイダを通して、下位層にあるいくつかのエンティティを経たのち、通信相手側にある、同じ層のサービス・ユーザに通知が届くという点である。また、発信側のサービス・プリミティブによっては、発信側が何がしかの確認を必要とする場合もある。このような場合は、相手側に通知が届いた後、今度は逆方向に、確認のための通知が必要となる場合も想定できる。このような、サービス・プロバイダをは仲介にしたさんだやり取りを明確にするために、サービス・プリミティブの実行の流れに即しての明確な記述が必要になる。

▶1.2.3.5.1 要求 Request

要求側ユーザ（N層）が、サービス・プロバイダ（N-1層）にサービスを実行する要求を発行するために発行するプリミティブを「要求プリミティブ」という。

▶1.2.3.5.2 指示 Indication

要求側（N 層）の発行した要求または、サービス・プロバイダにより生じる受諾側ユーザ（N 層）に対するサービス・プロバイダからの通知を行うプリミティブを「指示プリミティブ」という。サービス・プロバイダから、「指示プリミティブ」が発行される例としては、通信不能による「切断プリミティブ」などを想起すればよい。

▶1.2.3.5.3 応答 Response

要求側ユーザからの接続要求などは、受諾側ユーザへサービス・プロバイダから指示があったとしても要求に受け入れるか受け入れないかは一義的に決まらない。そのような状況が想定できるプリミティブには、サービス・プロバイダからの指示プリミティブを通知された受諾側ユーザは、応答を返す必要がある。この受諾側の応答を、「応答プリミティブ」という。

▶1.2.3.5.4 確認 Confirm

応答リミティブを受け取ったサービス・プロバイダは、その原因を生じさせた要求側ユーザに対して、通知を行う義務がある。この場合に使われるプリミティブを、「確認プリミティブ」と呼ぶ。IrDA 規格書におけるサービスもこの、要求 → 指示 → 応答 → 確認という表記でサービスを定義している。通常、これらの表現を記号化して表現する場合がある。たとえば、送信に関するプリミティブの場合は、xxx_Send.要求 → xxx_Send.指示 → xxx_Send.Res → xxx_Send.確認 ように表記される。

ｘxx_の部分に、プロトコル（エンティティ）の省略表示を持つ場合もある。(ex: LM_Send.要求など)

▶1.2.3.6 エンティティの通信路(コネクション型、コネクションレス型)の区分

▶1.2.3.6.1 コネクション型（CO型）

サービス・ユーザが通信サービスを利用する場合、情報を交換する前に、お互いの認証や、通信方式、通信の品質などの取り決めを行い、サービス・ユーザ同士の合意の上で通信を開始することがほとんどである。このような合意を必要とする通信方式を「コネクション型(CO 型Connection-Oriented Mode)といい、通常「接続プリミティブConnect」、「切断プリミティブDisconnect」を持つ。また、接続合意がなされている状態を「コネクションの確立」という。この場合、コネクションを要求するサービス・ユーザを「起動側 Initiator」とよび、コネクションに応答した側を「応答側 Responder」という。先ほどの要求側ユーザと受諾側ユーザの概念とは異なる概念である。

▶1.2.3.6.2 コネクションレス型（CL型）

一方、取り決めを行わないで、いきなり情報の送受信を行う方式をコネクションレス（CL 型Connectionless Mode）」という。コネクション型は、コネクションレス型に比べると多くの処理が必要となるが確実な通信が行える。また、コネクションレス型は比較的処理が簡単であるが、ほとんどの実装では、応答プリミティブ、確認プリミティブを省略する場合があるため、確実な通信の応用には向かない。IrDA 規格では、コネクションレス型の通信をIrDA 固有の処理に応用しているがこれについては、後で述べることにする。

▶1.2.3.7 エンティティの情報フォーマット PDU PCI SDU

まわりくどいいい方になるが、サービス・ユーザ（N+1 層）が交換するプリミティブがエンティティ（N層）のサービスのインターフェイスであるとすると、サービス・プロバイダ（N 層）は、サービスを実現するために、サービス・ユーザである上位層（N+1 層）から送られてきた情報に、サービス・プロバイダ（N 層）の固有のサービスを実現するための情報を付加して下位層（N-１層）に送る。また、相手側のサービス・プロバイダ（N 層）が下位層（N-1 層）からこの情報を得ると、上位層（N+1 層）に通知する情報と、自分自身（N 層）で処理する情報を分離して、処理を行い、その結果サービス・プリミティブを上位層（N+1層）に通知する。ここで付加される情報は、このサービス・プロバイダ（N層）固有の情報でありすべて、このサービス・プロバイダ内部で生成、処理、消費される。通信の両端の同じ階層サービス・プロバイダ（N 層）間で交換されるのは、サービス・ユーザ（N+1 層）の情報と、サービス・プロバイダ（N 層）固有の情報で構成される。

▶1.2.3.7.1 PCI(Protocol Control Information)

このサービスプロバイダ（N 層）を実現するために必要となる付加的な情報をプロトコル制御情報PCI(Protocol Control Information)という。

▶1.2.3.7.2 SDU(Service Data Unit)

上位のサービス・ユーザ（N+1 層）がこのサービス・プロバイダ（N 層）に通知する情報ユニット（情報の単位）をサービス・データ単位SDU(Service Data Unit)といい、通信の両端にあるサービス・ユーザ同士が交換する情報の単位である。SDU の情報は、上位のサービス・ユーザ（N+１層）間でみると、加工しないでそのままの形でサービス・プロバイダ（N 層）を通過する。サービス・プロバイダ（N 層）は通常、データの透過性（トランスアペアレンシー）を保証することが原則になっている。

▶1.2.3.7.3 PDU(Protocol Data Unit)

プロトコル・データ・単位PDU(Protocol Data Unit)とは、両側にあるサービス・プロバイダ（N層）どうしが交換する、PCIとSDUを含む複合体である。情報フォーマットの関係を階層的に整理すると、下位層のサービス・プロバイダが受け取る「サービス・データ・単位SDU」は、上位の「プロトコル・データ単位PDU」であるということになる。PDU(N)= SDU(N-1)PCI は、ほとんどのプロトコルの実装で、SDU の前に付加され、PDU = PCI+SDUという構成になっているため、多くの記述として、PCI のことを「プロトコル・ヘッダ Protocol Header」といういいかたをすることが多い。

▶1.2.3.8 エンティティの内部状態

プロトコルが実際に正しく動作させるには、内部状態という概念が必要となる。たとえば、コネクション型の通信を行う場合、「コネクション確立」前にデータの交換を行うことは出来ない。このような簡単な例でもわかるように、プロトコルは、過去の事象の結果としての現在の状況（状態）と、上位層から発行されるプリミティブや、下位層から送られてくるPDU の通知などによって、次の状態が決定される有限ステートマシン（有限オートマトン）を構成する。それを正確に動作させることで、どんなサービスが受け入れ可能なのか、またどんなPDU を受け取り、または無視するのかが決まる。つまり、これらの、エンティティの状態と状態の遷移に関する正確な記述が必要となる。したがって、サービス・プリミティブだけを定義するだけでは、動的に変化する通信サービスを記述したことにはならない。エンティティの状態を正しく記述することは、プロトコルを定義するためには最も重要なことであり、プロトコルの出来のよさ、パフォーマンスに大きく影響する。このような記述がないと、プロトコル動作において、未定義の状態に落ち込んでしまい、通信システムを停止させてしまうことにつながる場合もある。これらの時系列的な動作状況を正確に記述するのがステートダイアグラム（状態遷移図）である。プロトコルを正しく実装するためには、停止されている状態遷移図を正しく理解し、実装に反映しなければならない。ここでは、詳しくは述べないが、必要な章においておって述べていくことにしよう。

2. モバイル通信モデルと赤外線通信の特殊性-IrDA規格でのアプローチ-

通信技術において、はじめに考えなくてはいけないことは、「なぜそのよう媒体を使って通信するのか、そして、どのような場面でもっとも価値があり便利なのか」を考えることが大切である。したがって、「使い方」つまりは、ユーセージモデルを実現するためのプロトコル定義であるということを常に意識しておく必要がある。IrDA 規格も基本となるユーセージモデルを想定して規格を採択している。余談ではあるが、IrDA では年に一度ボード会議において次年度のIrDA 活動に関するミッションステートメントを採択し、年内の行動指針としている。ミッションステートメントとはいわばIrDA がどのような方向性で規格を作っていきどのような分野にアプローチしていくかの基本理念を討議している。筆者も98 年度のミッションステートメントの策定に参加した経験がある。

▶2.1 IrDA規格のユーゼージモデル

赤外線通信が使われる場面を考えると、モバイル通信と密接にかかわっている。モバイル通信において、ケーブルの存在は煩雑であることは言うまでもない。小さな携帯端末と通信を行うときにケーブルを使用するとなると、携帯端末に無様なコネクタを設けなければならず小型化に支障がある。また、通信する相手を考えると、パソコン、プリンタ、LAN、モデム、携帯電話、カメラなどまったく素性の異なる通信相手とまったく異なる通信手順、コネクタによって接続しなければならない。

IrDA 規格を制定するにあたって、最初に考えられたのが「赤外線によるケーブルの置き換え」という指針がIrDA 規格の基本的なユーゼージモデルになっている。

▶2.2 IrDA規格に対する要求

これらのユーゼージモデルを各階層において適合していくとIrDA 規格の体系が明らかとなる。では、具体的にどのようにIrDA 規格に反映しているのか概観してみよう。

3. IrDA方式におけるプロトコル階層構造の概要

IrDA の提唱している赤外線通信方式も、OSI 参照モデルに類似したプロトコル層に分けられている。具体的には、物理層(IrPHY)、リンクアクセス層(IrLAP)、マルチプレクサとデータベース層(IrLMP)、トランスポート層(TinyTP)、アプリケーション層(IrAPP)というようにいくつかの通信サービス層に分かれておりそれぞれの固有のサービスを定義している。効率の視点からいえば、多くのサービス層が存在するということは、速度や、処理能力という観点から望ましくはないが、規格がある程度制限なく発展、利用されつづけるためにはどうしても必要なことである。仮に大きな規格を提唱したとしても、そのサブセットとして比較的簡単な実装を定義することで、実装における規格を満足するアプローチも可能である。IrDA 方式では、それらの最小の実装をIrDA Light という規格でまとめている。

ここでは、IrDA 規格を理解する上で必要な格プロトコルの階層について必要になる概念を簡単に説明しておこう。ここで必要なことは、「なぜそのような層が必要なのか」を理解することであり細かい規定を理解する必要はない。前章で述べたようにユーゼージモデルからの要求として理解することが早道である。

▶3.1 物理層 IrPHY

通信プロトコルにおいての、具体的な媒体（ハードウエア）を規定するのが物理層である。どのような物理的な手段を利用して通信を行い、通信に必要なデータ品質、通信速度、変復調方式を規定する。この部分に関しては、装置の改良、高速化が常に行われていて時代とともに変遷、改良されてく。しかしながら、基本的に下位互換性をつねに保ちながら進化していくものであり、常に最新の方式が、特定の応用において意味があるとは限らない。また、次に説明するリンクアクセス層と密接な関係を持っているため、物理層とリンクアクセス層の一部が重複している場合がある。

IrDA 規格の場合は、赤外線受送信モジュールの信号強度、指向性、到達距離、エラーレート、パルス変調方式を規定する。データフレームの構成なども規定ベースとなるデータフレーム規定する個所について、物理層と、その上位にあるデータリンク層で物理的な媒体の違いで層にまたがって記述されている場合もある。IrDA規格ではこの部分をIrPHYとして規格化している。OSI参照モデルの第1 層（物理層）に該当する部分と考えればよい。 IrDA 規格への要求のから、ケーブルの置き換えをという視点で規格を考えると、通信距離は、0ｍから1ｍ程度、指向性は30度内外に妥当性がある。また、応用分野の通信速度は、モデムの範疇で、9600bpsから128000bps程度、LANやカメラなどの比較的データ通信速度を溶融されるものについては1Mbpsから10Mbps程度の高速性が要求される。また、モバイル系の応用を考えると電池駆動が基本となるので、省電力化もポイントとなる。

現在では、IrPHY 規格としてすべての物理層を総合的に呼んでいるが、従来の規格に従えば、IrSIR Ver 1.0 と IrSIR Ver 1.1 そして、 IrSIR Ver 1.2 とバージョンが改定されている。

▶3.1.1 IrSIR Ver 1.0

IrSIR Ver1.0 では、HP SIR 方式(HP100LX で採用した方式)を基本にした、2,400bps から、115,200bps の速度をもつ低速から中速の物理仕様を定義している。HP 方式である IrSIR Ver 1.0 では、PC/AT 互換のシリアル通信ポート(16550/16450)をベースにした規格で、その先に、赤外線信号に変換するモデム変復調回路をどのように構成するかを規定する。ベースバンドのシリアル信号を、信号レベル１は無信号、信号レベル０は、ボーレートに対して3/16 区間の赤外線パルスまたは、

外線発光の時間がベースバンド変調にくらべて、3/16 または、1.6us(115200bps での3/16)に抑えられているために発光時間が短く省エネルギーである。また、変復調回路が簡単であるためにＰＤＡなどの小型端末にのせやすい。

▶3.1.2 IrSIR Ver 1.1

IrSIR Ver 1.1 では、IBM 社が提唱した、ＭＩＲ方式 575,000bps, 1,152,000bpsと、SHARP 社が提唱した ＦＩＲ方式 4.0Mbps を含んでいる。IrSIR Ver 1.1 で採用された、ＩＢＭのＭＩＲ方式は、パルス変調方式については、ＨＰ方式と同等の3/16 方式であるが、データは非同期式ではなく、ＨＤＬＣに見られる同期式の符号を使用している。ＭＩＲ方式では、同期式のシリアル通信ＬＳＩが別途必要となり、ＩＢＭのＴＰ５３０などには、ＨＤＬＣ通信のための汎用シリアルＬＳＩである、Zilog SCC (85Z30) 互換のＬＳＩが搭載されている。このＬＳＩは、アップルのマッキントッシュにも採用されているものだ。ＳＨＡＲＰのＦＩＲ方式は、ＨＰ方式とことなる変調方式である４ＰＰＭ変調を採用したもので、同期式の通信である。これも、専用のシリアルＬＳＩを必要とする。

光学的な物理規格としては、通信可能距離０ｍ－１ｍ、角度３０度以内と規定している。今述べたように、速度と変調方式の異なる３つの規格を同時に満足するためには、受発光素子（赤外線ＬＥＤ、赤外線フォトダイオード）の性能が問題となる。０ｍ－１ｍという規格も赤外線の強度も3 桁以上の開きがあり、受光部のアナログ回路の実現が難しく全ての規格を満足できている素子を作るメーカはすくない。IrDA のすべての物理方式を使用するためには、このＳＩＲ／ＭＩＲ／ＦＩＲの３つの規格を搭載したIrDA 専用のＬＳＩ、または ASIC 用のIP マクロ要となる。また、高速Ｉｒの場合は、ＤＭＡなど高速にデータを受信する追加のハードウエアが必要となる。最近では各半導体メーカからIrDA 専用のＬＳＩや、ASIC 用のIP も発売されてきている。

▶3.1.3 IrSIR Ver 1.2

IrSIR Ver 1.2 規格で追加された部分は、IrSIR Ver 1.0、1.1 の規格をさらに省電力を考えたものである。到達距離を短くすることで消費電力を少なくした規格である。

▶3.2 リンクアクセス層 IrLAP

リンクアクセス層とは、物理層をどのようなルールによって操作するか（メディアアクセスルール）、通信における基本的な「接続」「切断」「データ転送」についてどのような方式にするか、通信においてのエラー復旧をどのような手順により実現するかを規定する。OSI参照モデルの第2層（データリンク層）に該当する部分と考えればよい。リンクアクセス層において、物理層で発生しうるデータエラーを確実に修復する手順を設けることで上位層は、物理的な障害やデータ誤りなどを考えなくてもよくなり、よりアプリケーションよりの概念を規定することに集中できる。

IrDA 赤外線通信のカバーする範囲は、2400bps 程度のポケベルから、ＬＡＮに匹敵する4Mbps とかなりの広い範囲のソリューションをあつかえる能力をもっている。その為に、IrDA のプロトコルをつかさどるＣＰＵの能力、使えるメモリの量についても様々であり、通信のリンクプロトコルの善し悪しで、使い勝手、応用範囲も影響をうける。IrDA が発足した段階での応用範囲は、ＰＣ中心の通信、広くてもプリンタなどの周辺機器までの応用だったと考えられる。現在では、ＰＣだけに限らず、デジタルカメラからデジタルプリンターにＰＣを介さずにIrDA の通信を使用して直接プリントするもの発売されてきている。

IrDA 規格の場合は、通信の目的が不特定の装置間で「そのば限りの通信」を目的としているために、赤外線の通信範囲にある装置を検出する機能や、ほかの通信方式と異なり固定したアドレス（装置番号）などを割り当てることや、通信速度を前もって規定することが出来ないのでそのための固有の手順を必要とする。IrLAP規格の参照している規格はHDLCである。HDLC規格の接続モードにもさまざまな種類があるが、IrLAP規格で準拠しているのはHDLC規格で半二重通信を規定している正規応答モード（NRM Normal Response Mode）であり、この規格を拡張したものになっている。正規応答モードについては、後程詳しく議論する。

IrLAP 規格の第一の特徴は、IrDA 搭載の不特定の周辺装置を「発見する」手順をもっている事だろう。従来の通信方式では、接続する装置は決まっているために接続する相手を「発見する」手順を必要としない。しかし、赤外線通信の場合、周囲にある端末は前もって決まっているわけではなく、「探してはじめてわかる」というのが特徴的である。IrLAP では、装置同士が接続する前に、「装置発見手順」という動作を行い、周囲に存在するIrDA 装置を検索する。発見手順により検索された装置から選択的に必要とする装置と接続する。

第二の特徴は、接続しようとする相手の通信能力（通信速度、データサイズなど）の差を、接続する時点で、お互いの持てる能力を通知しあうことで、もっとも効率の良い通信を取り決める点にある。具体的には、発見手順や通信開始の段階では、通信速度は9600bps、最大データサイズ64 バイトに規定されている。接続時点で通信能力を自動選択する主だったパラメータとして通信速度については、IrSIR V1.0 の範囲では2400bps,9600,19200,38400,57600,115200bps IrSIR V1.1 の範囲ではさらに0.576Mbps,1.152Mbps,4.0Mbps通信データサイズについては、64,128,256,512,1024,2048 バイトの範囲で選択される。

基本的には、物理層とリンクアクセス層を規定すれば、データ通信における基本的なサービスを提供したことになる。また、通信プロトコルの実装においてその信頼性、パフォーマンス、エラー修復能力を規定してしまうのもこの2つの層である。実装においてこの２つの層をまず分離して確実に検証しなれば、上位層の試験等も出来なくなってしまう。この2 つの層について完全な理解が必要なのはいうまでもない。ここで理解しておくことは、物理層とリンクアクセス層によって「データを送受する太い一本のパイプが用意された」ということである。この「太い一本のパイプ」という考え方は上位層について一切の規定をしない無垢な通信経路が確立したということであり、基本的に目的に応じて、この上位にどのようなサービスを規定してもかまわないということである。このような考え方は、最新のネットワーク技術の基本的な概念でありこれなくしてはさまざまな応用を可能にする上位層の構築は不可能である。

▶3.3 マルチプレクサと接続情報データベース IrLMP(IrMUX IAS)

IrLAP 層が、１対１のデータリンクとデータ品質を保証するプロトコルであるのに対して、その上位層であるIrLMP層は、１本のデータリンクを複数の経路に分割して複数のデータリンクを可能にする層である。「ひとつの物理経路」に「ひとつのアプリケーションやプログラム」が関係するようなモデルを考えるなら、物理層とリンクアクセス層を規定するだけで十分といえよう。しかしながら、さまざまなアプリケーションが上位層に存在し「自発的に」通信経路を確保するためには、通信経路をアプリケーションに動的に割り当て、しかもアプリケーションから通信経路を判断できるような、通信アプリケーション間で通信経路に関する情報交換を行う「統一された何がしかの手段」を通信手順内に設ける必要性がある。また、太い通信経路を複数のアプリケーション同士で共有し、アプリケーションごとに排他的にデータ通信路を確保し通信経路を効率的に使用することも必要となる。

具体的には、４Mbps で通信している場合、28.8kbps モデムに換算すれば、１０倍以上の太いパイプが下層のIrLAP 層にあるわけで、この太いパイプを分割して複数のアプリケーションで同時に使用できるようにすれば高速ＩＲ通信をより効率的に使うことができる。例えば、4Mbpsの高速Ｉｒをもつ、携帯PC用のドッキングステーションを考えよう。ドッキングステーションには、モデムや、プリンターポート、そしてフロッピーユニットなど携帯PC に搭載されていない周辺が高速Ｉｒを通して接続される。その場合には、同時にモデムやプリンタ、フロッピーなどが動作しなければならない。しかも、効率よくデータを分配する機能も必要となる。その為には、IrLAP層の上に、複数の論理的なアクセスポイントを設けて、アプリケーションやドライバーから 関係する装置に向けてデータパスを作らなければならない。それを可能にするのがIrLMP 層のLM-MUX（マルチプレサ）であ、IrDA の装置同士の中に複数のデータリンクを論理的に作り出す方法が、論理リンクアクセスポイント（LSAP）の概念である。

さらに、そのリンクアクセスポイントの論理データパス上に、どんな装置、アプリケーションが接続されているかを、問い合わせる機能も必要となる。この機能が、IrLMP 層に内蔵されている情報データベース、IAS（インフォメーションアクセスサービス）である。アプリケーションもしくは上位のプロトコルとセッションを行う際に必要になる情報を、プロトコル内で定義したデータベースに配置しプロトコルで規定したアクセス手順によりアプリケーションや上位プロトコルが使用する手段を提供する。LM-MUX に登録される論理データパス（LSAP）に何が接続されているかを、クラスとアトリビュートの概念で問い合わせできる。

例えば、IrDA 対応のプリンタであれば、"IrLPT"というクラスがIAS に登録され、IrCOMM 対応のISDN 公衆電話であれば、"IrDA:IrCOMM"というクラスと"IrDA:TinyTP:Lsapsel" というアトリビュートがIAS に登録される。IrLMP のIAS を使用すれば、装置同士のそれぞれの機能を持つ複数の上位層つまり、プリンタ、LAN、MODEM、ISDN-TA などの特定の接続先を指定して特定の機能にアクセスできる機能をもっているわけだ。

IrLMP 規格は一度改正されて、IAS サービスが強化された。この強化がIrDA の応用範囲を広げたともいえる。IrDA 規格では、この物理層、データリンク層、マルチプレクサと接続情報データベース層の3 つのプロトコル層を搭載しなければならないと規定している。

▶3.4 トランスポート層(TinyTP)

データ通信において、通信速度を規定するのは単純に物理層の能力だけで規定されるものではない。むしろ各アプリケーションの処理速度や、ユーザインターフェイスの有無やたの通信経路との通信速度（ディスクアクセスなども含む）によって複雑に変化する。また、上位層で規定するデータの単位（パケットサイズやストリーム）もさまざまである。したがって、分割した通信経路を効率よく使用するためには、上位のアプリケーションと、下位のマルチプレクサの間に、データのフロー制御や、データ長の違いを吸収するサービス層が必要となる。これらのサービスを行うのがトランスポート層である。IrDA 規格ではTinyTP プロトコルとして規定している。OSI 参照モデルの第4 層（トランスポート層）に該当する部分と考えればよい。

▶3.5 エミュレーションエンティティとオブジェクト指向

赤外線通信規格の目的のひとつとして、従来のケーブルを使った物理的な接続を赤外線を使用したコードレス通信に単純に置き換えるという考え方があり、プリンタや、モデム、ISDN 機器、LAN アクセスなどがそれに該当する。IrDA 規格では、プリンタとモデム（ISDN を含む）の赤外線への置き換えの規格としてIrCOMM 規格を、LAN の赤外線への置き換えを可能にするIrLAN 規格などがある。これらの規格はすでにある物理的な信号線を赤外線通信においてどのようにエミュレーションするかをこの規格では定義しており赤外線プロトコルを介して従来の物理的な信号がそのままシュミレーションされている。

IrCOMM の応用として、赤外線による画像通信方式としてIrTran-P 規格が制定され、デジタルカメラ同士、PC、ISDN 公衆電話や携帯電話から画像を交換することの出来るアプリケーション寄りの規格も制定されている。また、通信により交換されるデータを「オブジェクト」として抽象化して交換する手順としてIrOBEX(赤外線を使用したオブジェクト交換)という手順も存在する。最近ではこの手順を利用して、携帯電話システムにおける、メール、メッセージ交換、電話帳や名刺交換、スケジュール交換などを行える TELECOM規格なども制定されている。OSI参照モデルの第7層（アプリケーション層）に該当する部分と考えればよい。第5 層（セッション層）、第6 層（プレゼンテーション層）に該当する部分はアプリケーション含まれる。

4. IrDAの規格書を読む

前章までに、プロトコルを理解するうでで必要となるOSI 参照モデルと、IrDA 規格の基本的な概要を学んだ。ここまで読み進んだ読者は、IrDA 規格書の概要を読む準備がそろっているはずである。本書は、IrDA 規格書の内容をそのまま記載して解説をするつもりはないので読者は早速IrDA規格書を手元においてほしい。

▶4.1 IrDA規格書の入手

IrDA 規格書は、IrDA が主催しているサイトにあるホーム・ページにアクセスすれば無償で入手することができる。ここで、ホームページのURL を紹介しておく。URL http://www.irda.orgこのサイトから、規格書(Standards)のページをアクセスしていただけば、本書で解説する規格書がてにはいる。IrDA では、IrDA 総会で決議された規格についてはすべて公開することを原則としている。IrDA で審議中のドラフト規格やプロポーザルを入手するためには、IrDA に入会しなければならない。本書で解説するIrDA 規格は以下のものである。

▶4.1.1 IrPHY規格

Infrared Data Association Serial Infrared Physical Layer Link Specification Version 1.2

▶4.1.2 IrLAP規格

Infrared Data Association Serial Infrared Link Access Protocol (IrLAP)Version 1.1

▶4.1.3 IrLMP規格

Infrared Data Association Link Management Protocol Version 1.1

▶4.1.4 TinyTP規格

Infrared Data Association‘Tiny TP’:A Flow-Control Mechanism for use with IrLMP Version 1.1

5. IrPHYの解説

IrPHY 規格の範囲(Scope)は、「この物理仕様は、自由空間を介した、指向性のある、半二重シリアル赤外線コミュニケーション・リンクを使ってコンピュータと周辺機器の接続を容易にするためのものである。」と定義している。赤外線通信の媒体となる、自由空間上の光学的な仕様、赤外線信号のパルス形状などが中心となる。本書では、電気的なハードウエアをソフトウエア的な側面から考えることを主眼にしているのでシステム・インプリメンテーションの見地から細かな光学的な部分を除いてIrPHYの規格書を読み下していこうと考える。

▶5.1 半二重の赤外線通信経路

赤外線を使用した通信経路は、物理的に対向した赤外線受送信装置により構成される。通信において、自分自身で発光した赤外線は、３０度のコーン状に広がり対向する出装置に到達する。同様に、反射、受発光装置の物理配置が隣接しているなどから自分の信号は自分自身の受光装置にも同時に伝達される。したがって、赤外線通信における通信経路は、LAN で使用されておるイーサネットと同様に半二重通信をベースにした通信方式となる。

▶5.2 パルス変調方式

IrDAの物理層のでは、3種類の変調方式が採用されていることは概要で学んだ。これらについて、より詳しく理解することにしよう。

▶5.2.1 IrSIR 1.0 (HP-SIR)方式

▶5.2.2 HP-SIR 方式の変調波形

HP-SIR方式は、通常のIBM-PC互換機で実現できるシリアルインーフェイスと同じ系列の通信レートを持っている。2400bps、9600bps、19200bps、38400bps,57600bps、115200bps NRZ 115200bps

▶1.63 usecの通信レートに適応する。

基本的な1 バイトのデータ構成は、一般の非同期シリアル通信で使われる1 ビットのスタートビット、8 ビットのデータ、1 ビットのストップビットで構成されるフレームを、変復調回路を使って、赤外線パルスに置き換える。シリアルのデータは、0 または1 で、スタートビットは、必ず0、ストップビットは必ず1となっている。HP-SIR 方式の場合、格ビットタイムの中のデータが0 の場合にはビットレートの3/16区間または、1.63μS 光らせる。3/16 のパルス幅は、通常、非同期シリアルポートの受信回路を駆動する回路が、ビットレートの16倍のクロックでサンプルするので、このサンプルクロックを使って変復調を行うことで変復調回路を簡素化でできるために採用された規格である。最小のパルス幅である、

HP-SIR 方式の場合、非同期シリアル転送であるので、フレーム変換はIrLAP が受け持つ。IrLAP 内部で1 バイト単位に受信しフレームを構成するようにする。

▶5.2.3 IrSIR 1.1 (IBM-MIR)方式

▶5.2.3.1 IBM-MIR 方式の変調波形

STA:開始フラグ 01111110 binary ADDR:8 bit アドレスフィールドDATA:データフィールドFCS:CCITT 16 bit CRC STO:終了フラグ 01111110 binary IBM-MIR 方式のフレームフォーマットIBM-MIR 方式の基本的なアイデアは、既存のHDLC 用同期シリアル通信LSI フロントエンドに、簡単な赤外線パルス変復調回路をつけた形で高速赤外線通信を実現しようというものである。このフレームを使用する転送レートは、0.576Mbpsと 1.152Mbpsの2つの速度を使用する場合であ

1/4 Bit cell NRZ S T A A D D R DATA 16b FCS S T O S T Aる。フレーム構成は2つ以上の開始フラグ、アドレスフィールドとデータ、そしてCCITT勧告の16bit CRC と終了フラグで構成される。連続した5 個以上の1 は、0 ビットインサーション処理が行われるのもHDLC 規格と同一である。赤外線変調回路は、格ビットタイムのデータが0 の場合は、ビットレートの1/4 区間発光させる。IBM-MIR 方式を制御するH/W は一般的に、自動的にフラグシーケンスを見分け、フレーム単位でDMA で自動的にシステムメモリにフレームを取り込み、取り込み中にCRC を計算しCPU に対してステータスとして受信データの有効性を報告する。

▶5.2.4 IrSIR 1.1(SHARP-FIR)方式

ONE COMPLETE SYMBOL chip 1 chip 2 Chip 3 chip 4 Ct Dt Data Bit Pair(DBP)4PPM Data Symbol (DD)00 1000 01 0100 10 0010 11 0001

式を使用する。この変調方式は、4PPM(Pulse Position Modulation)方式という。連続する2 ビットのデータをペアとして、通信ビットレートの2 倍のクロックをベースにして、4 つの枠のなかにどの位置にビットが立っているかを判定して4 値のデータに変換する方式である。この方法により、パルス幅は通信レートの1/2、発光のレートは1/4に押さえることが出来る。この変調方式のデータを受信する場合は、４つの枠の先頭を検出するためのビットパターン(パターンマッチングによるビット位置検出)であるプリアンプルが必要となる。また、HP-SIR 方式、IBM-MIR 方式と異なり、CRC は、32 ビットに拡張されている。

▶5.3 一般的な光学的特性

リンク長（接続可能な範囲）は、標準規格(Standerd)では0ｍから少なくとも1ｍと定義されている。Ver1.2 で追加された省電力規格(Low Power)も含めた組み合わせでのリンク長は次のようになる。Low Power –Low Power Standard -Low Power Standard -Standard最小リンク可能距離(m)0 0 0最大リンク可能距離(m)

また、この場合のビットエラーレート（BER）は、10^-9 以下であると定義している。

▶5.4 メディア・アクティビティ検出

各局はたとえ受信側が設定したものと異なるボーレートで送信したとしてもデータ転送の存在を検出できるものと仮定する。この検出にはフレームエラー、オーバーフロー、キャラクタエラーなどがある。この検出は粗いキャリア検出として使用される。

6. IrLAP規格書

▶6.1 規格書の構成

IrLAP 規格は、IrPHY 物理層によって提供される半二重シリアル赤外線による物理的な通信メディアを用いて、コンピュータとその周辺機器間の相互通信を実現するための規格書である。OSI参照モデルのデータリンク層第２層を)において装置間の相互接続のための機能、特徴、プロトコル、サービスについて規定している。第２章「サービス仕様」サービス・ユーザ層に対してIrLAPが提供するサービスを規定する第３章「環境特性」

IrLAP がIrDA 物理層に対しする仮定を規定する。第４章「フレーム構造」IrLAP フレームの一般符号化規則を規定する第５章「手続き要素」有効なIrLAP フレームの種類を規定する第６章「手続きの詳細」IrLAP フレーム交換を支配する手続きを規定する。IrLAPで規定されるデータリンク層プロトコルは、現存する非同期式シリアル通信、ISOで規定するHDLC またはSDLC（HDLC 規格のベースとなったIBM の通信規格）の半二重通信規格に基づき作成されいる。したがって、IrLAP 規格を理解するためには、はじめにHDLC 規格を学んでおく必要がある。IrLAP が参照しているHDLC に関する規格は次のものである。

ISO 4335ハイレベルデータリンク制御手順(HDLC)手続きの要素1991-09-15 ISO 8885ハイレベルデータリンク制御手順(HDLC)一般利用のSID フレーム情報フィールド内容とフォーマット1991-06-01 ISO 3309ハイレベルデータリンク制御手順(HDLC)フレーム構造1991-06-01 ISO 3309-2ハイレベルデータリンク制御手順(HDLC)フレーム構造1991-06-01 ISO 8886情報技術システム間の電気通信と情報交換開放型システム互換接続(OSI 参照モデル)のためのデータリンクサービス定義1992-06-15これについては後に詳しく検討する。IrLAP でのこれらの標準プロトコルに対する主な修正点は以下の通りである。(語彙等については後述する)移動体等、システムの一時的な所在を考慮したアドレス拡張柔軟ななアドレス衝突解決手続きの導入_移動体等のシステムの一時的な所在を考慮して拡張した回復メカニズム柔軟な局発見／識別手続きの導入コネクション設定手続きを拡張し、両局がサポートする最適なコネクション特性が選択できるようにすること。

_いずれの局も一次局になりうること。メディアアクセスルールを拡張して、隠れノードにデータ転送をさせないようにメディア制御に対する局間の競合状態を解決できるようにすること。HDLC では、固定した通信経路を前提とした規格であるが、赤外線通信規格であるIrDA きかくでは周辺にある装置の検索などの手続きが必要である。そのため、IrLAP では、移動体通信システムにおいて必要となる機能について、HDLC 規格の修正、拡張をおこなっている。

▶6.2 IrLAPのサービス規定

IrLAP のサービス規定は、IrLAP 層の上位層にあるサービス・ユーザからみえるサービス・プリミティブを定義する。各サービスはプリミティブとパラメタによって規定される。IrLAP によって提供されるサービスには次の二つのタイプがある。コネクションレス型サービス（CO 型）コネクション型サービス（CL 型）

▶6.3 IrLAPサービス定義

IrLAP のサービス・プリミティブにはOSI 参照モデルに基づき、次の四つのタイプがある。要求（Request）サービスを起動するために上位層が呼び出すためにある。指示(Indication)イベントや、開始した動作を通知するために、IrLAP から上位層に送られる。応答(Response)指示プリミティブによって何らかの手続きが起動されたこと二対する確認のめに上位層が発行する。確認(Confirm)以前受けたサービス要求の結果を知らせるためにIrLAP から上位層に送られる。

IrLAP は、装置間リンク上の通信プロセスを管理するために、上位層との通信においてこれらのプリミティブを使用する。

▶6.4 IrLAPのサービス・プリミティブ

▶6.4.1 コネクションレス型サービス

▶6.4.1.1 Discovery Services 発見サービス

IrLAP-DISCOVERY.要求()IrLAP-DISCOVERY.指示(Discovery-Log)IrLAP-DISCOVERY.応答(List-of-Discovery-Logs)要求プリミティブは、通信可能な領域内にどのような装置があり、接続可能かどうかを発見（検索）するために使用されるサービスである。接続可能な装置のリスト（つまり、発見ログ）が応答プリミティブにより返される。他の装置の要求プリミティブによって発見された装置は、要求プリミティブ受信終了時に、発見要求を発行した装置についての情報を、指示プリミティブによって自発的上位層に通知する。

パラメタ:Discovery-Log solicited + sniff + 装置アドレス + IrLAP Version+ discovery info List-of-Discovery-Logs｛Discovery Log ｝Solicited[true | false]他の装置についての情報は、強制的(Solicited)および自発的(Unsolicited)という二つの方法によって通知される。強制的発見とは、発見プロセス要求した結果として応答プリミティブによりサービス・プロバイダであるIrLAP 層から通知されることをいう。自発的発見とは、発見要求を開始した装置自身が情報を提供したためにIrLAP 層から通知されることである。つまり、発見要求のプロセスの結果、相手側のサービス・プロバイダに発見要求側の情報が伝達されることを意味する。このフラグはどちらの方法で装置情報が得られたかを示す。この発見サービスで得られた発見ログ（Discovery-Log）の装置アドレスを使用して、コネクションの確立を行う。

発見ログの構成：Sniff[true|false]発見された装置がスニフィング装置か否かを示す。スニフィング（省電力動作については、後述する）装置アドレス32 ビットで構成される装置アドレスである。IrLAP-version 7 ビットで構成される応答側のIrLAP 層のバージョンを示す。Discovery-Info 32 バイトまでのフィールドで、内部の情報はサービス・ユーザ層によって規定される。この発見サービスで得られた発見ログ（Discovery-Log）の装置アドレスを使用して、コネクションの確立、データ転送、を行う。装置アドレスとは、装置ごとにユニークにふられた論理的な番号であり自由に選ぶことが出来る。自由に選択できるということは、同じ装置アドレスをもつ別の装置が同時に発見される場合も想定できる。その場合、接続アドレスの一意性がなくなるので、次に説明するアドレス衝突解決サービスを使用して衝突の回避を行う。Discovery-Info は、通常、装置の名称であるとか、上位層のサービスの情報を配置するが、IrLAP 層では、何も規定せず上位層に透過的に通知する。

▶6.4.1.2 Address Conflict Services アドレス衝突解決サービス

IrLAP NEW ADDRESS.要求(装置アドレス)IrLAP NEW ADDRESS.確認(List-of-Discovery-Logs)アドレス衝突解決サービスは装置アドレスの衝突（同じ装置アドレスが複数の装置に割り振られていること）を解決するためのサービスである。発見プロセスの結果、発見ログに同じ装置アドレスを持つ二つ以上のエントリがある場合、このサービス・プリミティブを呼び出し、装置アドレスが衝突している装置に新たに衝突しない装置アドレスに選択しなおすようにする。

パラメタ:装置アドレスIrLAP の32 ビット装置アドレスList-of-Discovery-Logs発見サービスを参照

▶6.4.1.3 Unit Data Services 単位データサービス

IrLAP UNITDATA.要求(User-Data)IrLAP UNITDATA.指示(User-Data)このサービス・プリミティブは、コネクションを確立せずにデータを送信する方法を提供する。このデータ転送は信頼性がない。なぜなら、送信したデータが相手に確実に届いたかどうかの検証の手順がないからである。すべてのデータは「ブロードキャスト（同報）」で送信され、特定の装置アドレスに対しては送信できない。つまり、受信可能な周囲に存在する装置すべてに「同報」される。

パラメタ:User-Data 384 バイトまでのデータ注意：IrDAで規定される最小のユーザデータ（SDU）は64バイトであるので、UNITDATAで送られる情報のすべてを相手側で受信できるようにするためには64 バイト以下にしなくてはならない。

▶6.4.2 コネクションサービス

▶6.4.2.1 Connect Servicesコネクションサービス

IrLAP-CONNECT.要求(Target-Device-Adr, 要求-QOS, Sniff)IrLAP-CONNECT.指示(Source-Device-Adr, Connection-Handle, 通知-QOS)IrLAP-CONNECT.応答(Source-Device-Adr, Connection-Handle, 要求-QOS, accept)IrLAP-CONNECT.確認(Connection-Handle, 返送-QOS, accept)CONNECT 要求は、Target-Device-Adr で示される装置 要求-QOS で示される通信品質でIrLAP コネクションの確立を要求するために使用される。スニフィングパラメタがtrue に設定されれば、IrLAP リンクは「スニフィング」と呼ばれる低消費電力モードを使った装置へコネクション設定を試みる。Target-Device-Adr とスニフィングに対する要求の２つの情報が発見サービスによって返されるログから決定される。

接続相手となる装置の上位層に発行される指示プリミティブは、送信側の装置アドレスとコネクションハンドルを提供する。応答プリミティブは、コネクションの確立を要求する局の装置アドレスSource-Device-Adr、コネクションハンドル、サービスパラメタ品質を通知し、肯定的（コネクション許可）応答プリミティブを発呼することによって、局がそのコネクションを許可する場合、これらのパラメタが有効になる。確認プリミティブはコネクションの確立の合否を通知する。コネクションが確立した後に発行されるすべてのプリミティブは、Connection Handle を使用して実行される。

パラメタ:Target-Device-Adr接続先（Responder）の32 ビット装置アドレスSource-Device-Adr接続元（Initiator）の32 ビット装置アドレスConnection-Handle IrLAP の7 ビットコネクションハンドルSniff[true | false]要求-QOS Baud Rate + Max Turn Around Time + Disconnect Threshold+Data Size通知-QOS Baud Rate + Data Size + Disconnect Threshold Accept[true |false] (false の場合はコネクションが確立されていない。)Max-Turn-Around-Time 最大ターンアラウンド時間 （後述する）

Disconnect-Threshold最小ターンアラウンド時間 （後述する）Baud-Rate (bps)[9600 | 19200 | 38400 | 57600 | 115200 | 576000 | 1152000 |4000000 ]Data-Size (bytes)[64 | 128 | 256 | 512 | 1024 | 2048]

▶6.4.2.2 Sniffing Services スニフィングサービス

IrLAP-SNIFF.要求(Cancel)SNIFF 要求プリミティブは低消費電力接続手順(スニフィング)を開始するのに使用する。スニフィング動作とは、物理層が、常に受信可能状態でなく、定期的に目覚めて周囲にある装置に対して接続動作を反復する特殊な動作である。動作については後述する。スニフィング要求はCancel フラグをtrue に設定した要求プリミティブを発行することによってキャンセルできる。コネクション設定に成功すると、IrLAP CONNECT 確認プリミティブがIrLAP によって返される。

パラメタ:Cancel[true | false]

▶6.4.3 データサービス

IrLAP-DATA.要求(Connection-Handle, User-Data, Expedited-Unreliable-Flag)IrLAP-DATA.指示(Connection-Handle, User-Data, Expedited-Unreliable-Flag)このサービスは、リンクが確立した局間でデータを転送するために使用するサービス・プリミティブである。このサービスは、信頼性があり転送データの時系列順序を保証するデータ転送と、信頼性がなく優先順序を保証しないデータ転送の2 種類を用意している。この２つの転送方式は、Expedited-Unreliable-Flag を用いるて選択する。信頼できるデータ転送であっても、確認プリミティブは送信側に通知されない点には注意が必要である。IrLAP 層は信頼できるデータをエラーなしに正しい順序で転送する仕組みをもっている。要求プリミティブは、上位層が提供するユーザデータ（SDU）をIrLAPに送信要求する場合に使用される。IrLAPは、受信したユーザデータを上位層に確認プリミティブを使用して通知する。

パラメタ:Connection-Handle IrLAP の7 ビットコネクションハンドルUser-Dataユーザデータのバイト数はこのコネクションハドルに対して設定されたサービスパラメタ(QOS)のData-Size サービス品質を超えることは出来ない。Expedited-Unreliable-Flag[true | false]true はデータ転送の信頼性が不要であることを示す

▶6.4.4 状態サービス

IrLAP-STATUS.要求(Connection-Handle)IrLAP-STATUS.指示(Connection-Handle, Quality-of-Link)IrLAP-STATUS.確認(Connection-Handle, Unacked-Data-Flag)IrLAP は、STATUS 指示を用いて、上位層にリンクの品質がどのような状態にあるかを通知する。物理層で、高レベルのノイズを受けている場合や、コネクションに関連するの動作が終了した場合、また、光路の遮断などによる、リンク品質の改善がなされない場合などの IrLAP 層の動作状態を通知する。IrLAP は、要求および指示プリミティブを用いて、未確認（確実に転送されていないデータ）

の送信データについての情報を上位層に通知する。転送において受信側からのデータ転送完了通知のない未確認のデータがあれば、Unacked-Data-Flagがtrueに設定される。これはデータの転送には影響を及ぼさない。このサービスは、上位層に提供される簡単な「覗き見」のメカニズムである。パラメタ:Connection-Handle IrLAP 7 ビットコネクションハンドルQuality-of-Link[no activity | noisy]Unacked-Data-Flag[true | false]true はIrLAP 層が送るべき未確認データを持っていることを示す。

▶6.4.5 リセットサービス

IrLAP-RESET.要求(Connection-Handle)IrLAP-RESET.指示(Connection-Handle)IrLAP-RESET.応答(Connection-Handle, accept)IrLAP-RESET.確認(Connection-Handle, accept)リセットサービスは、現在確立しているコネクション間の状態をリセットするサービスである。リセットによりすべての未確認のサービス・データ単位（SDU）は廃棄される。また、IrLAP 内部状態もコネクションが確立した直後の状態に戻される。リセットはそのコネクションの両者が合意した時のみ実行される。応答プリミティブがリセットを受理しない場合、リセット要求は確立されているコネクションには何ら影響を及ぼさない。

パラメタ:Connection-Handle IrLAP 7 ビットコネクションハンドルaccept[true | false](false なら、リセットを実行しない)

▶6.4.6 切断サービス

IrLAP-DISCONNECT.要求(Connection-Handle)IrLAP-DISCONNECT.指示(Connection-Handle)切断は論理的な接続を終了し、全ての未確認のサービス・データ単位(SDU)は破棄される。切断は常に成功するため、確認プリミティブは不要である。指示プリミティブ内のUnacked-Data パラメタは切断時に未確認であったデータについての情報を含む。パラメタ:Connection-Handle IrLAP 7 ビットコネクションハンドルUnacked-Data未送信データに関する実装依存情報以上が、IrLAP層のサービスである。引き続いて、このサービスを赤外線通信で実現するための環境条件と、動作特性について調べることにしよう。

▶6.5 環境条件と動作特性

構成条件と動作特性については、IrPHY に規定している物理層の特性、ユーセージモデルによって制約をうける。したがって、IrPHY に規定される物理層のメディア特性、携帯端末などの移動体通信の応用によって、アクセスするための必要なルールの特性が定義される。物理的な特性：半二重データ通信非同期式(歩調式)、同期式通信に適合すること空間上のデータ衝突の検出もしくは回避方法隠れノード狭い赤外線コーン(円錐形：半角15 度)データ転送に関する特性：通信が出来る装置の発見ポイントポイント、ポイントマルチポイントデータ転送効率上記の用件を満たすために、IrLAP では、HDLC をベースとしてIrDA 独自の規格の拡張を行っている。そこで、IrDA 規格を横に置きながら、IrLAP の詳細を検討する前にHDLC について学習しておくことにしよう。

▶6.7 IrLAPとHDLC ハイレベルデータリンク制御手順

▶6.7.1 データリンク層の役割

データを確実に転送するためには、単にデータそのものを送受信するだけでなく、物理的な接続、接続相手の確認、データ転送の誤り検出と修復などを規定しておく必要がある。これらの通信に必要な基本的な仕組み、手続きを転送制御という。送信側、受信側の間に論理的なリンクを確立し、あらかじめ決められた手順（プロトコル）にしたがってデータの転送を実行する。これを転送制御手順と呼ぶ。HDLC（High level Data Link Control procedure）ハイレベルデータリンク制御手順は、高速データ転送のための転送制御手順としてISO で標準化された。HDLC は、信頼性が高く、高速転送が可能でコンピュータ間など装置やCPU を持つようなインテリジェト化された装置間の通信で多く採用されている。現在の一般的な電気通信におけるデータリンク層は、IrDA 規格を含め、ほとんどHDLC 方式を基本に拡張されている。HDLC の特徴は次のような点である。

▶6.7.1.1 コードに対する独立性：任意のビットパターンが転送可能

ベーシック手順や、パソコン通信などの無手順方式は、転送の単位が文字コード単位であるため、特定の制御コードを利用してデータを転送する。HDLCでは、ビット単位のデータ転送が可能なため、任意のバイナリ－データを転送することができる。ただしIrLAP の場合は、バイナリの８ビットデータを転送することを原則としている。

▶6.7.1.2 転送効率の向上：データの連続転送が可能

ベーシック手順などの一般的な方式では、相互監視式転送手順と呼ばれる、ひとつのデータブロックを送信するごとに、転送の合否を判定するための「確認応答」が必要となるが、HDLC の場合は、データブロックの先頭に確認に必要なPCI（制御ヘッダー）を付加して、確認応答なしに先行して連続送信することが可能である。応答については、折り返されるデータのヘッダ部分に確認応答のためのPCI を付加して転送データとともに一括して確認応答をするため、転送効率が高くなる。この方式を同時監視式転送制御という。IrLAP の場合、IrPHY の特性から、半二重転送の制約があるため連続転送ができる手順はきわめて有効である。

▶6.7.1.3 信頼性の向上：厳密な誤り制御

HDLC の誤り検出方式は、16 ビットまたは拡張で32 ビットのFCS(Frame check Sequence)にを採用しており、生成多項式（CRC）による厳密な誤り検出を行う。この方式は、連続したデータ化けであるバーストエラーに対しても有効である。HDLC では、ITU-T勧告V.41のCRC符号の生成多項式である X^16+X^12+X^5+1を採用している。

▶6.7.2 通信の主体（局の概念）

HDLC では、データの送受信をする主体を「局」と呼び、一次局、二次局、および複合局の3 つに区分される。

▶6.7.2.1 一次局(Primary)

データリンクの制御を行う局である。データ転送の開始制御、データの流れの制御、誤り回復手順の制御の責任を持つ。

▶6.7.2.2 二次局(Secondary)

一次局の支持にしたがってデータリンクの制御機能を実行する。

▶6.7.2.2 複合局

一次局、二次局の両者の機能を併せ持つ局である。IrLAP の場合、半二重通信の制約のため、複合局は存在しない。

▶6.7.3 コマンドとレスポンス

HDLC て転送される情報は、コマンド（指令）Command とレスポンス（応答）応答の２つの種類がある。一次局から二次局に送られる情報をコマンド、二次局から一次局に送られる情報をレスポンスと呼ぶ。この呼び方からもわかるとおり、一次局が主導権を持ち、二次局は一次局の指示にしたがって情報を転送する方式であることがわかるだろう。

▶6.7.4 情報の媒体 フレームの構成 HDLCとIrLAPのPDUの構成

フレームは、HDLC で転送される情報の基本単位である。情報メッセージも、手順を管理する監視制御情報もすべてこのフレームの形で送受信される。HDLC では、フレーム同期方式を採用しているため、フレームの先頭を検出するビットパターンとして、フラグシーケンスとよばれる8 ビットのビットパターン（具体的には01111110）によりフレームの先頭と、終了を検出する。フレーム最後のフラグシーケンスの手前16 ビットには誤り検出に使用するFCS（Field Check Sequence）がつく。IrDAのフレームの場合は、IBM-MIR 方式の場合は、HDLC とまったく同様のフラグシーケンスを用いるが、HP-SIR の場合は、非同期方式のバイトデータのストリーム上でフレームを論理的に構成するため、のフラグシーケンスと、バイナリ－データを分離するための特殊な方法を使用する。

SHARP-FIR 方式の場合は、フラグシーケンスに変えてプリアンプルによるフレームの先頭を検出する。しかし、いずれの場合でも、フラグシーケンスを除くと、HDLC形式と同じ形式になる。この図は、HDLC のフレームからIrDA フレームと共通の部分を抜き出して表記している。HDLC の場合は、先頭にフラグシーケンス、終わりにFCS とフラグシーケンスが追加されるがこの部分は本質的ではない。IrDA規格の場合、フレームの先頭に付加されるフレーム開始部分をBOF（Begin of Frame）、誤り照合部をFCS(Field Check Sequence)、フレーム終了部をEOF(End of Frame)と呼ぶ。したがって、IrDA 規格のフレームフォーマットは次の要素から構成される。

（BOF）フレームの開始を示す開始フラグ(A)二次局コネクションアドレスを識別するアドレスフィールド(C)特定のフレームの機能を規定する制御フィールド（I）情報データを含むオプションの情報フィールド（可変長でありない場合もある）（FCS）受信局がフレーム伝送の正当性を検査するためのフレームチェックシーケンス（EOF）フレームの終了を示す終了フラグIrDA 規格の場合、これらのフィールドは各々8 ビットまたは8 ビットの倍数で構成されるが、HDLC の場合、アドレスフィールド、制御フィールドは8 ビットであるが、情報フィールドに関しては任意のビットであるとしている。また、情報フィールドの長さは可変長であることに注意しよう。

8 bits 8 bits 8 * M bitsアドレス部A制御部C情報部I先頭のバイト位置は、物理層によって供給される

▶6.7.4.1 アドレスフィールド（A）

HDLC の場合は、通信系路上に降られた装置のアドレスを使用して通信の相手局、もしくは時局のアドレスを指定するしたがって、HDLCの場合は通信相手に固有の固定したアドレスとして使用する。IrLAP の場合は、事前にアドレスを決定することが出来ないので、接続手続きにより二次局のコネクションアドレス決定する。接続前や、発見手順などコネクションが成立する前のやり取りの場合は、｢ブロードキャスト｣を意味するアドレスフィールドとして、1111111B を使用する。コネクションが確立すると、二次局のコネクションアドレスを含む。一次局がフレームを送信する場合、アドレスはそのフレームの宛先となる二次局を示す。二次局がフレームを伝送する場合、アドレスはフレームを生成した二次局を示す。

▶6.7.4.1.1 アドレスフィールド表現

アドレスフィールドは7 ビットの実際のアドレス(A ビット)そしてコマンド／レスポンス識別ビット(C/R ビット)で構成される。C/R ビットが0 の場合は、フレームがコマンドフレームであることを示す。C/Rビットが1の場合、フレームがレスポンスフレームであることを示す。HDLC の場合はフレームのあて先のアドレスを指定するだけであるが、IrDA の場合、接続時に二次局コネクションアドレスだけを決定しその値を使用するため、フレームが一次局から送られるコマンドなのか、二次局から送られるレスポンスなのか判定できないそこでアドレスフィールドの下位１ビットを使用してコマンド/レスポンスを判定できるようにしている。

アドレス0000000XB はNULL コネクションアドレスとして予約される。このアドレスが付与される二次局はない。HDLC の定義に従えば、回線の試験に使用するために予約されている。アドレス1111111XB は、簡単に述べたとおり、グローバルまたはブロードキャスト(同報)アドレスとして予約さているため、このアドレスが付与される二次局はない。一次局、またはコネクションが確立していない局がブロードキャスト用に使用する（発見手順など）。

▶6.7.4.2 制御フィールド(C)

制御フィールド(C)は、アドレスフィールドの直後に置かれ、フレームの機能を規定する。この制御フィールドによって、フレーム全体の機能を規定するので、制御フィールドの理解がHDLC、IrLAP A A A A A A A C/R!"#$部7 0の理解のかぎになる。細かなことはともかくとして、どのような形式があるかを今のうちに理解しておこう。制御フィールドは、複雑な形式をとるが基本的には、おもだった三つの形式に区分されている。詳細は、後述する。

▶6.7.4.2.1 情報（I）フレーム

情報転送形式と呼ばれ、情報部「（I）フィールド」を持ち情報メッセージの転送に用いる。

▶6.7.4.2.2 監視（S）フレーム

監視形式と呼ばれ、データリンクの監視に使われる。してがって、情報部を持たない。

▶6.7.4.2.3 非番号制（U）フレーム

非番号制形式と呼ばれ、通信におけるモードの設定、異常状態の報告などを行う。機能によっては、パラメータのための（I）フィールドを持つ場合もある。

▶6.7.4.3 情報フィールド（I）

通常は、上位層から提供される、情報（I）フレームのサービスデータ単位SDU を乗せるために使用する。HDLC では任意の長さのビットデータを転送できるのに対して、IrLAP の場合、情報フィールドは長さを規定しないが、8 ビットの倍数である。

▶6.7.4.4 フレーム検査シーケンスフィールド（FCS）

I フィールド(あるいはI フィールドが存在しない場合はC フィールド)の直後にはフレームチェックシーケンスフィールド(FCS)がある。このフィールドの目的は、フレーム転送中に生成する可能性のあるエラーに対して、受信フレームを検査することである。このフィールドは、HP-SIR 形式、IBM-MIR形式の場合は16 ビットの、SHARP-FIR 形式尚場合は、32 ビットのCRC-CCITT 巡回剰余検査で構成される。CRC はA フィールド、C フィールド、I フィールドを計算対象とする。

BOF A C I FCS EOF 8 bits 8 bits 8 bits 2 * 8 bits 8 bits M * 8 bits FCS

▶6.7.5 動作モード、非動作モード

一次局、二次局、（HDLC の場合複合局を含む）がコマンドレスポンスを送受信する場合におい手の基本的な「振る舞い」を決定する。「動作モード」とは、データリンクが確立した後の動作を規定し、「非動作モード」とは、データリンクが確立していない状態の動作を規定する。一次局が二次局に対してコマンドによってモード設定を行い二次局の動作を変更する。一次局が発行するコマンドによって、動作モード間を遷移するが、動作モードが異なると送受信するコマンド・レスポンスの送出手順がことなってくる。HDLC では、次の動作／非動作モードが規定されており次のモードがある。

▶6.7.5.1 HDLCの基本動作モード（応答モード）

▶6.7.5.1.1 NRM（正規応答モード）

一次局と二次局が定義され（不平衡型）、二次局は、一次局から送信許可コマンドを受けないと、一次局にレスポンスを送信できない。したがって動作は半二重動作になる。

▶6.7.5.1.2 ARM(非同期応答モード)

一次局と二次局が定義され（不平衡型）、NRM ことなり、二次局は、一次局の送信許可がなくても、レスポンスを送信することが出来る。したがって動作は全二重動作になる。

▶6.7.5.1.3 ABM(非同期平衡モード)

複合局と複合局（平衡型）間で動作し、複合局は、栄手の複合局の許可がなくてもコマンドやレスポンスを送信できる（複合局は、一次局の機能と二次局機能をもつので複合局と呼ばれる。

▶6.7.5.1.4 HDLCの非動作モード（切断モード）

二次局、複合局がデータリンクから論理的に切り離されている状態を切断モードといい、NDM（正規切断モード）ADM（非同期切断モード）がある。

▶6.7.5.1.5 IM（初期モード）

また、IM（初期モード）はデータリンクを初期化するモードで、一次局、あるいは複合局からの操作により初期モードに遷移する。

▶6.7.5.1.6 IrLAPのモード

IrLAP の場合、物理層の環境条件により、HDLC の半二重モードである、NRM（正規応答モード）とNDM(正規切断モード)のみを使用する。NRM とNDM は、HDLC の基本になるモードである。

▶6.7.6 IrLAPにおける制御フィールド（C）の種類とフォーマット詳細

情報フィールドは、HDLC、IrLAP ともフレームの性格を決定する重要な要素である。この1 バイトにHDLC のすべてが詰まっているといってもよい。情報フィールドには、非番号制フォーマット（U）、情報フォーマット（I）、監視フォーマット（S）の３種類あとことはすでに学んだ。HDLC を基本にして、IrLAP の拡張も含めて詳しく調べてみよう。

▶6.7.6.1 非番号制フォーマット(U)のコマンド／レスポンス

7 6 5 4 3 2 1 0 HDLC、IrLAP 共通のコマンド／レスポンス1 0 0 P 0 0 1 1 SNRM コマンド (正規応答モード要求)0 1 0 P 0 0 1 1 DISC コマンド（切断要求）0 0 0 P 0 0 1 1 UI コマンド（非番号制データ送信）0 0 1 P 1 1 1 1 XID コマンド（局識別相互交換要求）1 1 1 P 0 0 1 1 TEST コマンド（テスト要求）1 0 0 F 0 0 1 1 RNRM レスポンス（正規応答モード応答）0 1 1 F 0 0 1 1 UA レスポンス（非番号制受信応答）

1 0 0 F 0 1 1 1 FRMR レスポンス（回復不能誤り検出）0 0 0 F 1 1 1 1 DM レスポンス（切断状態通知）0 1 0 F 0 0 1 1 RD レスポンス（DISC コマンド要求）0 0 0 F 0 0 1 1 UI レスポンス（非番号制データ送信）1 0 1 F 1 1 1 1 XID レスポンス（局識別相互交換応答）1 1 1 F 0 0 1 1 TEST レスポンス（テスト応答）以降は、IrLAP 独自のものである0 1 0 P 1 1 1 1 XCHG コマンド (一次局/二次局交換通知)1 1 0 P 1 1 1 1 DXCHG コマンド (一次局/二次局交換不能)1 1 0 F 1 1 1 1 RXCHG レスポンス(一次局/二次局交換要求)非番号制フレームは以下のような機能のために使用される。

データリンクの確立および解放手続きエラーの報告データ転送(信頼性のないデータ転送)U フォーマットのコマンド／レスポンスは、データリンク管理のために使用される。データリンク管理は、XID を使用した発見、SNRM/UA-DM による二次局のレスポンスモードの制御、そしてFRMR X X X X P/F X 1 1 7 6 5 4 3 2 1 0による(再送によって回復できない)手続きエラーの報告などを実行する。また、UI によってNDM,NRM の両モードにおいて、データを送信することができる。IrLAP の場合、非番号制フォーマットフレームは、標準のHDLC とは異なり、情報フィールドに拡張属性フィールドを含む場合がある。拡張属性フィールドには、送出元および宛先装置アドレス、オプションの制御パラメタなどがある。

これらの拡張属性フィールドについては、後ほど議論する。コマンド／レスポンスのうち、IrLAP で定義されているものについて列挙しておく。

▶6.7.6.1.1 SNRMコマンド／RNRMレスポンス

(正規応答モード設定/要求)SNRM コマンドは正規切断モード（NDM）の状態で使用すると、正規応答モードNRM への移行を要求すること、つまりコネクションを要求する。また、NRM 状態で使用されると現在の状態をリセット（内部状態の初期化）を要求する。SNRMコマンドに対して、UAレスポンスを受信すれば、コネクション設定(またはリセット)される。２つの局の状態は、SNRMコマンドを送信した局が一次局にとして、UAレスポンスで応答した局が二次局として正規応答モードNRMになる。IrLAPの場合、接続のためのSNRMコマンド、UAレスポンスともに、情報（I）フィールドを持ち、接続に必要なパラメータを持つ。

RNRM レスポンスは、NRM 状態において、二次局が使用し、アドレスフィールド（A）で識別される一次局によるコネクションのリセットを要求するために使用される。このレスポンス受信した一次局は、SNRM コマンドを発行し、リセットを行う。

▶6.7.6.1.2 DISCコマンド／RDレスポンス(切断通知／切断コマンド要求)

DISCコマンドは、NRM（コネクション状態）を終了しNDMに移行する、DISCを受信したNRMモードの二次局はNRMモードに移行する。二次局はUA レスポンスを送信することによって切断を確認する。DISC コマンドは、HDLC と同様にI フィールドを含まない。RD レスポンスは、正規応答モードにある二次局が、切断モード(NDM)に移行することを一次局に催促する。一次局は、DISC コマンドを発行し、NDM に移行する。

▶6.7.6.1.3 UI(非番号制データ送信)

非番号情報フレームは、コネクション（NRM）中または非コネクション（NDM）中の両方において使用できる。IrLAP において、NDM 状態でのUI フレームは、アドレス（A）をブロードキャストアドレス(X`7F')とし、C/Rビットを0に設定(コマンド)しなければならない。Iフィールドは上位層のサービス・ユーザによって使用される。

▶6.7.6.1.4 XID(局識別相互交換要求)

XID フレームは、装置発見、アドレス衝突解決、スニフィングにおいて、コマンドおよびレスポンスとして使用される。また、IrLAPおよび上位層に対して、相手局の上位層にXID情報フィールドを転送するというサービスも提供する。詳細は、装置発見手順の解説で詳しく説明する。

▶6.7.6.1.5 TEST（テスト要求／応答）

TEST フレームは、コマンドとして切断モード(NDM)の局に送られるか、TEST レスポンスを要求するためにコネクション状態の二次局に送信される。コマンドに情報フィールド（I）が含まれると、その内容（情報フィールドの内容）そのままレスポンスで返送される。二次局に情報フィールド（I）を受信するだけのバッファがなければ、情報フィールド（I）を含まないTESTレスポンスを返す。IrLAPの場合は、アドレスフィールド（A）にブロードキャストを使用する場合、情報フィールド（I）には、送信元装置アドレスと宛先装置アドレスを含む8 バイトフィールドが付与される。

▶6.7.6.1.6 UA(非番号確認)

これはSRNM コマンドおよびDISC コマンドに対する肯定的なレスポンスである。IrLAP の場合、SNRM コマンドに対するUA レスポンスは折衝パラメタを含む。

▶6.7.6.1.7 FRMR(回復不能誤り検出)

FRMR レスポンスは、エラーのないフレームの受信の結果、同じフレームを再送したとしても修復できない状況であることを報告する。1）定義されていない、あるいは実装されていないコマンドの受信。2）サポートしている最大値を超える、あるいはコネクション中ならば折衝した値を超える情報フィールドを持つI/UI, TEST, XID コマンドの受信。この機能はオプションであり、このようなフレームは無視しても良い。

3）無効なNr カウントの受信。連続送信などの場合の順序番号がおかしい場合。4） 情報フィールド（I）の必要ないフレームに情報フィールド（I）が含まれていた場合。

二次局は、ポールビットを含むフレームを受信すると即座にFRMR レスポンスを送信する。条件

FRMR レスポンスを受信すると、一次局は適切な正しい動作を起動する責任を持つ。例えば、条件(3)の場合には、SNRM あるいはDISC を用いて転送のための内部変数を初期化する。FRMRのI フィールドは次のようになる。Rejected frame control field : FRMR 状態の原因となったフレームの制御フィールド。N(S) : FRMR レスポンスを送る二次局のNs の現在値。

C/R :1 の場合、レスポンスフレーム、0 の場合コマンドフレームであることを示す。N(R) : FRMR レスポンスを送信する二次局のNr の現在値。w : 1 の場合、拒否した制御フィールドが未定義か実装していないことを表す。x : 1 の場合、拒否した制御フィールドに無効な情報フィールド（I）を含むことを表す。y : 1 の場合、受信したI フィールドの長さが最大値を超えたことを表す。z : 1 の場合、制御フィールドが無効なNr カウントを含むことを表す。

FRMR レスポンスのw,x,y,z ビットは、上記の条件に規定されない拒否を表すためにすべてを0に設定してもよい。Nr,Ns は後に詳しく述べる。

▶6.7.6.1.8 DM(切断状態通知)

自局が正規切断モード(NDM)にあることを示すために使用する。SNRM コマンドなどに対する否定レスポンスに使用する。

▶6.7.6.1.9 XCHG、DXCHG、RXCHG（一次局二時局交換）

一次局／二次局交換手順は、IrLAP 独自のオプション規格である。NRM 状態で二次局がRXCHG レスポンス（一次局二時局交換要求）を発行すると、一次局は、二次局に移行できればXCHGによって交換が成功したことを通知し、受け付けられない場合はDXCHGを発行して不成功を通知する。Rejected frame Control field C/R N(S)z 4 5-7 0 1 Byte N(R)1 - 3 0 y x w 0000 3 2 1 0 4-7 1 Byte 1 Byte Bits 0 - 7

▶6.7.6.2 監視フォーマット(S)

7 6 5 4 3 2 1 0 HDLC、IrLAP 共通のコマンド／レスポンスNr P/F 0 0 0 1 RR (受信可能通知)Nr P/F 0 1 0 1 RNR（受信不能通知）Nr P/F 1 0 0 1 REJ（指定フレーム以降のフレーム再送要求）Nr P/F 1 1 0 1 SREJ(指定フレームのみのフレーム再送要求)監視フレームは、情報を転送するフレームではなく、情報の転送を支援するものである。受信フレームの確認、レディ（RR）およびビジー（RNR）条件の転送、手続きエラー（REJ）の報告などに使用される。Nr は、受信情報フレームが受理(エラーなしで正しく受信)されたことを確認するために使用する。詳細は後述する。

▶6.7.6.2.1 RR(受信可能通知)

一次局あるいは二次局が送信する。Nr-1 までの番号フレームを確認し、情報フレーム（I）を引き続き受信可能であることを表す。

▶6.7.6.2.2 RNR(受信不能通知)

一次局あるいは二次局が送信する。バッファが使用できなかったり、他の制約によって一次的なビジー状態にあることを示す。コマンドおよびレスポンスとして、RNR はNr-1 までの番号フレームを受理し、次にNr の番号をもつ情報フレーム（I）が受信されることを期待していることを示す。二次局は、一次局からの(P ビットを1 にした)RR に対してF ビットを1 にしたRR あるいはREJフレームを送信することによって、RNR 状態が解消されたことを示す。

一次局はP ビットを1 または0 にしたRR およびREJ フレームを送信することによって、RNR 状態が解消されたことを示す。

▶6.7.6.2.3 REJ(指定フレーム以降のフレーム再送要求REJECT FRAME)

このコマンド／レスポンスは番号付きI フレームの再送を要求するために送信される。REJ はNr-1 までのフレームを受理し、REJ フレームに含まれるNr カウントを先頭とする番号付き情報フレーム（I）の再送を要求する。拒否状態は要求されたフレームもしくはモード設定コマンド（リセット）が受信された時に解消される。

▶6.7.6.2.4 SREJ(指定フレームのみのフレーム再送要求 SELECTABLE REJECT)

このコマンド／レスポンスはSREJフレームに含まれるNrカウントで示される特定の番号付きIフNr X P/F X 0 1 7 6 5 4 3 2 1 0レームの再送を要求するために送信される。拒否状態は要求されたフレームもしくはモード設定コマンドが正しく受信された時に解消される。

▶6.7.6.3 情報転送フォーマット(I)

情報フレームは情報を転送するためのフレームである。フレームには情報フィールドがあり上位層からのサービス・データユニット（SDU）を搬送する。この制御フォーマットには、送信および受信のカウント(各々Ns, Nr)を表現するフィールドがある。フレームが正しい順序で受信されたことを保証するために、Ns カウントを使用する。Nr カウントは、受信情報フレームが受理(エラーなしで正しく受信)されたことを確認するために使用する。

Ns カウントは、転送された情報シーケンス内の情報フレーム数を表す。フレームで送信されるNrカウントは、次に受信するべき情報フレームの番号(Ns)である。詳細については後述する。I フィールド長は、HDLC の場合任意のビット長、IrLAP の場合は8 ビットの倍数である。フレームを転送するこれらの情報は、番号つきの(つまりNr あるいはNs カウントのカウントを持つ)もののみである。

▶6.7.6.4 ポール／ファイナルビット(P/F)

P/F（Poll/Final）ビットは、Nr、Ns などの順序番号の確認や、送信権の交換の機会を与えるビットである。コマンドフレームの場合をポール（勧誘）ビット、レスポンスの場合はファイナル（最終）ビットとして使用する。コマンド／レスポンスともに、正規応答モード（NRM）の場合、連続して送信する最後のフレームの場合に１にする。NRM におけるP/F ビットの使い方について説明しておく。

▶6.7.6.4.1 Pビットの使い方

一次局は、Pビットによって、二次局からのレスポンスを勧誘（催促）する。一次局は、Pビットが1 であるコマンドを送信した後は、F ビットが１になっているレスポンスを受信するか、タイムアウトに達するまではなにも送信することは出来ない。

▶6.7.6.4.2 Fビットの使い方

P ビットが1 であるコマンドに対する応答に使用する。F ビットを1 にしたレスポンスを送信した場合、P ビットが１になっているコマンドを受信するまで、なにも送信することは出来ない。P ビットが1 のフレームは、二次局は、応答の最終フレームを伝送するときにも使用される。これは一次局に送信権を返すことを意味する。一次局、二次局とも、送信するデータが複数あるばあいは、最後のフレームを除いてP/F ビットをNr P/F 0 7 6 5 4 3 2 1 0 Ns 0 にした連続フレームを送信することが許されている。受信フレームの番号を管理するフィールドであるNr/Ns は3 ビットであるため、正しいシーケンスを保証できる連続フレームは最大で7 までとなる。

連続フレームを送信することが出来るのは、このP/Fビットと、Nr/Nsを制御、監視することで可能となる。

▶6.7.6.5 フレームシーケンス Nr、Ns、Vr、Vsについて

フレームが正しく交換されていることを保証するためには、２つの要素を考えなくてはならない。ひとつは、フレームと単位の転送エラーの検査を行うためのもので、フレームに付加されるFCSによりフレームの正当性を検証するこれは、HDLC の場合や、IrDA におけるMIR、FIR の場合はIrPHY層のFCS 計算ハードウエアで受け持ち、SIR の場合は、バイトデータストリームをフレームに変換する下位のシーケンサによって照査される。もうひとつは、その上位レベルとして、フレームの重複や欠如に対して検査するものである。

一次局、二次局ともに、連続して送信されるフレームを正しく処理するためには、二つの状態変数としてVs およびVr を持たなくてはならない。Vs,Vr についての概念は次のとおりである。Vs は次に送信するべき番号付きフレームのシーケンス番号を表わす。Vr は次に受信を期待する番号付きフレームのシーケンス番号を表わす。Vsカウンタは、フレームが送信される前の、連続する各フレームのNsフィールドに設定する。Vsは、Iフレームをひとつひとつ送信した後インクリメントする。Vrカウンタは、正しいシーケンスでかつエラーない情報フレーム（I）を受信した場合にのみインクリメントする。

Vrは、次に期待するフレームカウントを行い、次に受信したフレームのNsカウンタとの整合性を確認する。Vrは、送信するフレームのNrフィールドに設定される。もし、受信したフレームのNs がVr に一致しなかったならば、そのフレームはシーケンスから除外、破棄され、Vr はインクリメントしない。Nr およびNs のカウンタは、3 ビットで構成されるため、0 から7までの8 つ番号のを使用する。7 の次は0 になる。したがって、7 フレームを限度として、受信側がNr カウンタを送信側に報告する前に連続して転送することができる。相手の受信を確認していない未確認フレームは、エラーが発生した場合など、その一部あるいは全部を再送する場合があるため、確認が出来るまで送信側ですべて保持する必要がある。

Nr カウンタは、受信側が次に受信の期待するフレームのシーケンス番号を報告する。チェックポイント（送信権が入れ替わるタイミング）で、送信側の次に送信するシーケンス番号と同一でないならば、送信側は既に送信済みのフレームを繰り返し送信しなければならない。両局のVr とVs のカウンタはコネクション設定時およびリセット期間中に一次局によって0 に初期化される。その後、カウンタはシーケンスフレームが送信および受信されるに従って進められる。

以上が、HDLC の正規応答モード（NRM）とIrLAP の制御フィールド（C）についての種類とフォーマット詳細を説明した。IrLAP においては、これらのコマンド／レスポンスに付随する拡張情報があるがこれについては、あらためて説明する。

▶6.7.7 簡単な接続手順の例

ここまでの学習で、HDLC およびIrLAP についての基本的な要素について学びと取れたと思う。そこで、接続切断などの基本的な動作についての具体的な例を示すことにする。せっかくなので、IrDA の規格書で使用している表記を使ってシーケンス図をいくつか紹介しよう。紹介する前に、一次局、二次局で交換するフレームの記述の仕方について説明しておく。

▶6.7.7.1 フレームシーケンスチャートの見方と例題

IrDA 規格書における、フレームシーケンスの説明図に解説をつけたものが次の図である。

▶6.7.7.1.1 フレームの表記

情報（I）フレームは、シングルラインのバーであらわし、それ以外の監視（S）、非番号制（U）フレームはダブルラインのバーであらわす。

▶6.7.7.1.2 エラーフレームの表記

フレームの表記に波印は、そのフレームにエラーがあることを表す。

▶6.7.7.1.3 情報（I）フレームの表記

I は、情報フレームをあらわし、N(S),N(R)は、フレームにある送信、受信のシーケンス番号を表す。ポールビットが1 のときは、P、ファイナルビットが1 のときは、F を付加する。たとえば、I 0,１F という表記は、I フレームで、N(S)＝0、N(R)＝1 で、ファイナルビットが1 であるフレームをあらわす。

▶6.7.7.1.4 監視（S）フレームの表記

XXX は、監視フレームに属するコマンド／レスポンスのどれかであり、N(R)は、受信シーケンス番号をあらわす。ポールビットが1 のときは、P、ファイナルビットが1 のときは、Fを付加する。たとえば、 RR 0,P という表記は、RR コマンドで、N(R)が0 でポー津ビットが1 である受信通知フレームをあらわす。

▶6.7.7.1.5 非番号制（U）フレームの表記

X は、論理アドレスを表し、r/c はコマンド（C）レスポンス（R）をあらわす。続く、XXX は、非番号制フレームに属するコマンド/レスポンスのどれかであり、ポールビットが1のときは、P、ファイナルビットが1 のときは、F を付加する。拡張データは、その次の括弧の中に表記する。たとえば、5 c SNRM,P(A,B) という表記は、論理アドレスが5 で、SNRM コマンド（C）、ポールビットは1 で拡張パラメータがA,B であることを表記している。

▶6.7.7.2 接続手順の例

この例は、一次局A が、二次局B に対して接続要求し、二次局B からデータをもらうシーケンスをあらわしている。一次局Aは、論理アドレス5を使って、SNRMつまり、正規応答モード設定要求を発行している。二次局（B）が応答できるようにポールビットを立てる。二次局となるB は、論理アドレス5 に対して、SNRM に対する肯定応答として、ファイナルビットを立てて、UA で応答する。この段階で、A B 間に正規応答モードでデータリンクが確立する。

一次局A は、送信するデータがないので、情報フレーム受信可能通知であるRR をポールビットを立てて送信する。SNRM が発行されると、内部変数 Vs,Vr が初期化されるので、RR フレーム上のNr は0 になるこため、RR0,P と表記されている。二次局B は、3 つの連則したI フレームを送信する。フレームを送信する後とに、内部変数Vs がインクリメントされるので、I0,0 I1,0 I2,0 と表現されるように、I フレームのNs がフレームごとに増加する。二次局B は、データを受信していないので、内部変数Vr は、0 のままなので、各フレームのNr はすべて0 担っていることに注意しよう。最後のフレームにファイナルビットを立てて、一次局からの応答を待つ。

一次局A は、この３つI フレームを正しく受信したので、Vr 変数は、I フレーム受信ごとにインクリメントされ、次に受信すべき順序数3 になり、二次局に対して RR フレームにNr を3 にして、正しく3 つのフレームが受信できたことを通知している。5c,SNRM,P(A,B)5r,UA,F(B)A (Pri):B(sec):RR0,P I0,0 I1,0 I2,0F RR3,Pこの例は、一次局A がSNRM を使って接続を要求するが、二次局B に拒絶された例である。

一次局A は、論理番号５を使用して、SNRM を発行する。二次局B は、自局終結通知 DM を使って、接続が出来ないむねを通知する。この場合は、リンクが確立しない。次の例は、一次局A がSNRM を発行するが、フレームに伝送経路上で誤りが発生し、タイムアウトとなり、もう一度SNRM発行を試みる。二度目のSNRMが二次局Bに到達し、接続肯定応答UAを返すことで、データリンクが確立する場合の例である。次の例は、一次局AがSNRMを発行し、二次局Bに到達し二次局がRR発行したが、フレームに伝送経路上で誤りが発生したため、タイムアウトとなり、一次局A は、もう一度SNRM 発行を試みる。

二度目のSNRMが二次局Bに到達し、接続肯定応答UAを返すことで、データリンクが確立する場合の例である。5c,SNRM,P(A,B)5r,DM,F(B)A (Pri):B(sec):5c,SNRM,P(A,B)5r,UA,F(B)A (Pri):B(sec):RR0,P time out 5c,SNRM,P(A,B)Time out 5c,SNRM,P(A,B)5c,SNRM,P(A,B)RR0,P 5r,UA,F(B)5r,UA,F(B)A(Pri):B(Sec):

▶6.7.7.3 データ転送手順の例

この例は、接続後の、相互のデータ転送の例である。一次局A はの内部変数Vr,Vs はともに0 である。一次局は、連続して３つのフレームをなげる。それぞれのI フレームのNs,Nr は、I0,0 I1,0 I2,0 となり、Ns だけが増加する。この段階での一次局の内部変数Vs は3 となる。ただし、送信した3 つのフレームの内容は、再送する可能性があるので保存している。二次局B は、この３つのフレームを正しく受信したので、内部変数Vr は3 になる。二次局B は、データをまだ送信していないのでVs は0 のままである。次に二次局B は、２つのI フレームを送信する。内部変数値はVs=0、Vr=3であるので、送信するフレームのNs,Nrは、I0,3 I1,3となる。同じく、送信フレームは保存している。

一次局は、まず相手から通知されたNr と内部変数Vs を比較する。ともに３なので、先ほど送信したフレームは相手に正しく転送できたことが確認できたので保存していた3 つのフレームのバッファ領域を開放する。次に一次局Aは、２つのIフレームを送信する。内部変数値はVs=3、Vr=2 であるので、送信するフレームのNs,Nr は、I3,2 I4,2 となる。同じく、送信フレームは保存している。 以降は、同様の手順なので、読者で考えてみよ。

次の例は、データ転送中に誤りが発生した例である。一次局が２つの連続したフレームを送信する。最終的にVs=2,Vr=0 となる。二次局は、一次局の送信した最初のI フレームは受信できたが、P ビットが立っていないので、送信権はないのでそのまま待機している。この時点での二次局の内部変数は、Vr=1、Vs=0 となる。一次局は、二次局から応答がないので、RR を使用して応答を催促する。A (Pri):B(sec):I0,0 I1,0 I2,0P I3,2 I4,2P I0,3 I1,3F I2,5 I3,5 I4,5F A (Pri):B(sec):I0,0 I1,0P I0,1 I1,1F time out RR0,P I1,2 I2,2P Retransmitted Frame二次局は、ポールビットつきのRR を受信したので、送信権を得る。そこで、２つのI フレームを送信するが、Vr=1、Vs=0 なので、I0,1 I1,1 の２つのフレームを送信する。

一次局は、このI フレームを受信すると、内部変数Vs と受信したNr が一致しないので、受信したNr＝１から、先ほど送信した2番目のIフレームを送信しなおす。しかし、その前に、2つのデータを正しく受信しているので、内部変数Vr はこの時点で2 になっているので再送するNr は2に変更して送信する。したがって再送するIフレームは I1,2となる。さらにデータがあるので、I2,2フレームを送信する。データ転送のいくつかの例を見てきたが、一次局、二次局とも内部変数Vr,Vs と、フレームにあるNr,Ns を巧みに使って、I フレームによって転送されるデータの抜けと、順序を監視しながら交互にデータ交換が行われる。このように、データを転送しながら同時にデータの異常を監視しているのできわめて転送効率がよい。これが、同時監視式転送制御の真髄である。

この例でわかるように。プロトコルは、上位層から提供されるサービスデータ単位SDU には関心がなく、関心があるのはSDU が正しい順序で抜けがなく相手に伝達されることが主眼であり、データそのものではなく、自分のプロトコルデータ単位に付随しているプロトコル制御情報PCI(Protocol Control Information)だけに関心があることに注意しよう。

▶6.7.7.4 切断手順の例

この例は、一次局がDISC コマンドを発行し、それに対して二次局はUA を発行しリンクを切断する例である。

さて、フレームシーケンスチャートの例をもちいて、HDLC とIrLAP に共通する、接続手順、データ転送手順、切断手順を詳しく説明した。このように、フレームシーケンスチャートによって手順を表記することで、時系列的に配置されたコマンド／レスポンスがどのように実際に使用されるのかより見通しのいいものになったことが理解できよう。しかしながら、このチャートに現れるのは、実際のプロトコル動作のごくごく一般的な例に過ぎない。

5c,DISC,P 5r,UA,F A (Pri):B(sec):つまり、プロトコルが実際に動作どうさする上での必要十分な動作を記述しなければならない。その目的で使用されるのが、プロトコルの状態を記述する、プロトコル状態の定義と、状態遷移表である。では、プロトコルの状態を記述することを引き続き学んでいこう。

▶6.7.8 プロトコル状態の記述

現在のサービス・プロバイダの内部状態（接続中／切断中、現在のVr,Vsの値など）と、外部もしくは、サービス・プロバイダ内部で発生するイベント（上位層からのサービス要求や下位層からの通知、内部で発生するタイムアウトなど）の２つの組み合わせによって次の内部状態が決まると同時に、上位層もしくは、下位層に通知もしくは要求を発生させるのが抽象的な意味でのプロトコルの動作である。これらの機構を、整理すると、現在のステート（状態）が、何らかのイベント（事象の発生）によって、何らかのアクション（行動）を行い、次のステート（状態）に遷移するということがわかる。どんな状況でもこの繰り返しであると考えることが出来る。これを正しく記述するために使用されるのが「状態マシン(State Machine)」であり、情報数学的な表現を使うと、有限オートマトンを記述するということになる。有限の状態と、有限の事象を組み合わせることでプロトコルのとりうる動作を完全に記述することが出来る。

状態には、必ず開始状態と、最後に行き着く複数の終了状態で停止する。それ以外は、中間状態であり、いくつかの中間状態を推移した後、必ず終了状態に行き着く。有限オートマトンの表現を使うと「停止条件」への遷移である。

▶6.7.8.1 プロトコル表記における状態マシンの一般的なルール

HDLC 規格や、プロトコル規格書では、通常、状態マシンを使用した詳細な記述が規定されている。これから述べる事柄は、プロトコルを記述するすべての状態マシンに適用されるので覚えておいてほしい。1） 動作の詳細記述に含まれている状態マシンは、プロトコルの行動を明確に規定するために与えられる。設計者や実装者は、規定された状態マシンの外部の挙動と同一である範囲で彼らが望む設計／実装技術を選択してもよいことになっている。つまり、数学的に一意性のある状態記述ではなく、次の状態に取りうる状態と動作は、複数の選択の余地があるということである。選択できる状態と動作は、効率を優先するか、実装を簡単にするかによって設計者や実装者は選択の余地があるということである。

2） 状態記述として、フラグまたは状態変数という、特別な条件の状態を維持する変数を持つことがある。フラグまたは状態変数は、次の多くの状態かを制限し、とりうる特定の状態への遷移を規定するために使用される。特定のフラグは含まれるべき状態マシンの記述で規定される。3） 状態マシンイベントにおいて、「気にしないでよい条件」を簡略に表記することがある。逆ないい方をすると「特に関係のない」条件を意味する。これらのイベントは、状態に規定されていないコマンドや、応答フレームの受信が状態にとって特に明記されない（つまり、状態は遷移しない）ことを示す場合がある。

4） 状態とイベントのいくつかの組合せにおいて、状態テーブルは代替動作を提供する。これらの代替動作は、横線によって分けられる。代替動作どうしは互いに排他的で、その選択は、(i)ローカル状態、(ii)層管理動作、(iii)実装上の決定のいずれかに基づいてなされる。イベント間、代替動作の順序間の関係はない。また、同一の代替動作どうしは、イベントが起きるごとに選択をする必要はない。5） 状態表は多くのタイマを使用する。いずれのタイマは、たとえタイマがすでにスタートしていたとしても、タイマ開始要求があれば、タイマは0 から再スタートする。動作しているタイマが規定の制限時間に達すると、適切なタイマ終了のイベントがプロトコル内部で発行され、タイマは停止する。タイマ終了要求は、タイマが動作している場合には、それを停止する。

6） 特定の状態において記述されていないイベントは、そのイベントを保留するいずれかのフラグが変更されるまで、あるいは状態の遷移が識別される状態になされるまで保留され、イベント発生を維持するとみなされる。状態マシンの記述例次にあげる例は、HDLC の正規応答モード設定（接続）における状態と状態マシンの記述例である。表を簡素化するために単純化している。この例を詳しく分析して、ステートマシンの動きを完全に理解しよう。

▶6.7.8.2 状態遷移表（状態チャート）

Current State現在の状態Event発生事象Action(s)行動Next State次の状態NDM(entry state)Connect-要求send ca:snrm:cmd:P start-F-timer retryCount := 0 SETUP Recv ca:snrm:cmd:P:Connect-指示CONN recv x:x:cmd:P send u:dm:rsp:F NDM recv x:x:x:x Empty NDM CONN Connect-応答Initialize-Connection-State Send u:ua:rsp:F NRM(S)Disconnect-要求send ca:dm:rsp:F NDM recv x:x:x:x Empty CONN SETUP F-timer-expiredÙ retryCount < N3 Send ca:snrm:cmd:P start-F-timer retryCount := retryCount + 1 SETUP F-timer-expiredÙ retryCount ³ N3 Disconnect-指示NDM recv u:ua:rsp:F stop-F-timer Initialize-Connection-State Connect-確認send s:rr:cmd:P start-F-timer NRM(P)recv u:dm:rsp:x stop-F-timer Disconnect-指示NDM recv u:disc:cmd:x Stop-F-timer Disconnect-指示NDM recv x:x:x:x Empty SETUPまず、この遷移表に現れる、遷移状態、状態変数とタイマー、イベント(発生した事象)、アクション（行わなければいけない行動）について、整理すると次のようになる。

▶6.7.8.2.1 遷移状態：

ステートマシンの取りうる状態を記述するNDM正規切断モード(NDM)の状態。つまり、リンクが確立していない状態であり、最初にとりうる状態である。(開始状態)SETUP正規応答モード(NRM)にいたるまでの、セットアップを行っている状態。CONN正規応答モード(NRM)にいたるまでの、コネクト動作をしている状況。NRM(P)一次局として、正規応答モードになった状態（終了状態）NRM(S)二次局として、正規応答モードになった状態（終了状態）

▶6.7.8.2.2 状態変数とタイマ：

状態を記録する補助変数とタイマを記述するretryCountエラー発生時に再送した回数を記録するF-timerファイナルビット送信済みタイマ。ファイナルビットを立てて、応答待ちになった場合、相手が無応答もしくは、下位の物理層でエラーになった結果のタイムアウトを通知するためのタイマ。タイマーがタイムアウトすると、F-timer-expired イベントが発生する。

▶6.7.8.2.3 イベント（発生する事象）：

起こりうる自称を記述するConnect-要求上位サービス・ユーザが、接続.要求サービス・プリミティブを発行した。Connect-応答上位サービス・ユーザが、接続.確認サービス・プリミティブを発行した。Recv a:b:c:d a:b:c:d で表現されるHDLC のプロトコルデータ単位(PDU)を、下位層から受け取った。x:x:x:x は、その状態で定義していない、そのほかの任意の（PDU）を受け取ったことを表現する。

F-Timer-expired F-timer がタイムアウトを起こしたイベントである

▶6.7.8.2.4 アクション（とるべき行動）：

状態の遷移の結果プロトコルが起こさなければならない行動を記述するEmpty何もしないことをあらわす。Disconnect-指示上位サービス・ユーザに、切断.指示サービス・プリミティブを発行する。Connect-指示上位サービス・ユーザに、接続.指示サービス・プリミティブを発行する。Connect-確認上位サービス・ユーザに、接続.確認サービス・プリミティブを発行する。Start-F-timer F-timer を開始させるStop-F-timer F-timer を終了させるSend a:b:c:d a:b:c:d で指定するPDU を下位層に送信する

▶6.7.8.2.5 NDM状態からの状態遷移の解説

NDM(entry state)Connect-要求send ca:snrm:cmd:P start-F-timer retryCount := 0 SETUP Recv ca:snrm:cmd:P:Connect-指示CONN recv x:x:cmd:P send u:dm:rsp:F NDM recv x:x:x:x Empty NDM NDM つまり、切断状態においての状態遷移を定義している。言葉で表現すると次のようになるであろう。

もし、上位層から、接続要求サービス・プリミティブを受けたならば、SNRM コマンドを下位層に発行し、F-timer を起動する。またretryCount を0 に初期化して、SETUP 状態に遷移する。もし、下位層から、正規応答モード要求（SNRM）コマンドが通知されたら、上位層に、接続指示サービス・プリミティブを発行して、CONN 状態に遷移する。もし、下位層から、SNRM 以外のコマンドが通知されたら、下位層に、現在切断状態であるむねの通知を行うために、切断状態応答である、DM レスポンスを返す。状態は遷移せず、NDM 状態のままである。

それ以外のレスポンス等が下位層から通知されても、何もしないで、無視する。

▶6.7.8.2.6 CONN状態からの状態遷移の解説

CONN Connect-応答Initialize-Connection-State Send u:ua:rsp:F NRM(S)Disconnect-要求send ca:dm:rsp:F NDM recv x:x:x:x Empty CONN NDM 時に、SNRM を受信した後の状態を定義している。同様に言葉で表現するともし、上位層から、接続確認サービス・プリミティブを受けたならば、接続に関する状態変数（Vr,Vs など）を初期化して、二次局の正規応答モード（SNRM(S)に遷移する。

もし、上位層から、切断要求サービス・プリミティブを受けたならば、DM レスポンスを発行して、接続要求を拒否する。それ以外のレスポンス等が下位層から通知されても、何もしないで、無視する。

▶6.7.8.2.7 SETUP状態からの状態遷移の解説

SETUP F-timer-expiredÙ retryCount < N3 Send ca:snrm:cmd:P start-F-timer retryCount := retryCount + 1 SETUP F-timer-expiredÙ retryCount ³ N3 Disconnect-指示NDM recv u:ua:rsp:F stop-F-timer Initialize-Connection-State Connect-確認send s:rr:cmd:P start-F-timer NRM(P)recv u:dm:rsp:x stop-F-timer Disconnect-指示NDM recv u:disc:cmd:x Stop-F-timer Disconnect-指示NDM recv x:x:x:x Empty SETUP SETUP 状態は、自局が、SNRM コマンドを発行し、相手局からその応答がくるのを待っている状態である。

もし、F-timerがタイムアウトし、リトライ回数がN3よりも少なかったら、もう一度、SNRMコマンドを発行しなおし、リトライ回数のカウンタを1 増加させる。状態は遷移せずに、SETUP 状態を保つ。もし、F-timer がタイムアウトし、リトライ回数がN3 より大きいか等しいならば、上位のサービス・ユーザに切断指示サービス・プリミティブを発行し接続できなかったことを報告する。状態は、初期状態のNDM に遷移する。

もし、下位層から、UA レスポンスを受けたならば、F-timer を終了させ、接続に関する状態変数を初期化する。上位に接続確認サービス・プリミティブを発行した後、RR コマンドを下位層に送信し、F-timer を開始する。その後、一次局の正規応答モードSNRM(P)に遷移する。もし、下位層から、接続拒絶の意味するDMレスポンスまたは、切断を意味するDISCコマンドを受けたならば、F-timer を停止し、切断通知を上位サービス・ユーザに通知すして、初期状態であるNDM 状態に遷移する。

それ以外の下位層からの通知は、無視する。状態遷移表を整理することで、サービス・プロバイダの機能である、サービスプリミティブと、プロト・コルデータ・単位（PDU）の関係がより鮮明になり、なおかつ確実な動作を記述することができる。この記述に基づいてサービス・プリミティブを装置に実装することが出来るようになる。

▶6.8 IrLAPとHDLCのまとめ

HDLC や、IrLAP のような複雑なプロトコルを理解するためには、さまざまな手段を使って、サービス・プロバイダのもつ機能を規格書では記述していることに気づくだろう。まとめると、次のようになる。プロトコルをサービス・プロバイダとしての定義を理解するには、サービス・プリミティブの種類と構造の理解をすることプロトコル・データ・単位（PDU）の構成を理解することPDU 上のプロトコル制御情報(PCI)の定義を理解することにほかならない。これらは、静的な情報の理解である。プロトコルの動的な動きを理解するためには、フレーム・シーケンスチャートを使うことにより、時系列的なプロトコルの動作を視覚的に理解すること状態マシーンを理解し規格書に定義されたプロトコルの動きを完全に押さえること状態遷移表を理解することで、サービス・プリミティブと、プロトコル制御情報（PCI）の関係や、内部状態の種類、内部変数の動作を理解することなどである。

OSI参照モデルの解説に始まり、HDLCとIrLAPの基本的な要素そして、プロトコル定義の基本である遷移状態まで、多くのページを割いて学んできた。ここまでの内容を理解できれば、IrDA規格を問わず、他のプロトコルについても理解できるようになっていると思う。わからない部分があれば読み返していただいて、しっかり理解するように心がけてもらいたい。つぎの章では、IrLAP 規格固有のサービスと機能について解説する。

▶6.7 IrLAP固有の機能

前章では、HDLC における正規応答モード（NRM）とIrLAP に共通する基本的なプロトコルの動作原理について学んだ。IrLAP が正規応答モードとして接続状態になった場合の振る舞いはHDLC と基本的には同一であると考えてよい。しかし、赤外線通信独自の動作を可能にするためには、HDLC 規格に定められた手順だけではだめで、接続前に行われる発見動作（XID 局情報交換）や、接続動作（SNRM/UA）においてIrLAP 固有の拡張パラメータが必要になる。

正規切断モード（未接続）状態において、IrLAP がHDLC 規格と根本的に異なることは次のように整理できる。

▶6.7.1 一次局が固定されていない

通常のHDLC の場合、回線上にある一次局はNRM やABM において一次局は通信に参加する局の中でひとつの局が行う。しかし、IrLAP の場合は、各局が一次局になれるようにするため、正規切断モード（NDM）状態は競合状態になる。つまり通信に参加する局同士がお互いに一次局になろうと試みる可能性がある。この競合を避けるために、メディアアクセスルールという切断状態における規定が必要となる。

▶6.7.2 接続する相手が決まっていないこと

通常のHDLCの場合、事前に局固有の情報としてアドレスが一意に決まられているが、IrLAP の場合は、アドレスが一意に決定できない。したがって、IrLAP の固有の何がしかの方法で接続相手を見つけ出して接続のための論理アドレス等を決める手順が必要となる。

▶6.7.3 接続する通信品質が決まっていないこと

通常のHDLC の場合、事前に通信速度や、タイムアウトを決定するが、IrLAP の場合は、接続相手の種類がさまざまであるため、接続時に動的にこれらの通信品質を決められる機構が必要となる。これらのIrDA 固有の問題を解決するため手順について学んでいこう。

▶6.7.4 メディアアクセス制御(MAC)手続き

MAC ルールとは、赤外線物理層のアクセス方法を規定するルールである。物理層に対する全ての通信はこのルールに従わなければならない。次のルールは、赤外線物理層へのアクセス権（送信権）を獲得するために守るべき手続きである。つまり、この手続きに従がわないでいきなり赤外線物理層に対してデータを送信してはならない。

▶6.7.4.1 ルール1

局が通信に参加する場合、すでに赤外線物理層で通信が行われいる最中かもしれない。つまり赤外線通信の場合、つねに競合が存在する。そのための原則として、IrPHY層における通信の検出「キャリア検出」が出来ることが必要である。HP-SIR の場合、通信速度がことなる歩調同期式のデータを受信すると、フレームエラー、ランダムな文字、不正なフレーム、正しいフレームを含むような任意の赤外線パルスが検出される場合は、すでに赤外線物理層が使われていること解釈できる。重要なことは、異なるボーレートでのコネクションが存在し得るため、局は全てのタイプの赤外線トラヒックを監視する必要があるということである。

▶6.7.4.2 ルール2

リンクのボーレートは、次のものに限定される。2400 bps 9600 bps 19200 bps 38400 bps 57600 bps 115200 bps 576000 bps 1152000 bps 4000000 bps

▶6.7.4.3 ルール3

競合状態でのトラヒックは9600bps で発生する。つまり、自局がNDM 状態の場合の初期値としての通信速度は、9600bps になっていなければならない。ただし、9600bpsで通信できない装置のため、2400bps での競合状態でのトラヒックの送受信能力を持つというオプションもある。2400bps でしか機能しない装置については、IrLAP 規格書を確認してもらいたい。

▶6.7.4.4 ルール4

接続（コネクション）状態でのトラヒック（通信の存在）は、競合状態でのトラヒックよりも高い優先度を持つ。つまり、通信に参加する局は、現在の通信を優先し、割り込んで通信を行うことは出来ない。接続状態の場合、そのリンクは500ｍS(1/2 秒)毎、あるいはそれ以内にパケットの往復がなければならない。つまり、接続中は500ｍS 以上物理層が空くことがないと解釈される。これを実現するためには、一次局は二次局を500 ミリ秒ごと（以内に）に呼び出す必要がある。二次局は(ファイナルビットを設定した)制御を500 ミリ秒以内に返す必要があることを意味する。場合によっては、連続して送信するフレームの個数（ウィンドウサイズ）と最大フレームサイズが500ミリ秒よりも長く連続するような送信を行なう装置を認めるかもしれない。「500 ミリ秒以内のパケット交換ルール」はどんなパラメータよりも優先度が高く、違反してはならないルールである。

▶6.7.4.5 ルール５

自局が、NDM 状態の競合状態にある時、送信を最初に試みる(たいていそれは発見フレームのXID だが)装置は、500 ミリ秒より長い時間(500+1 ミリ秒以上)赤外線物理層をモニタしなければならない。何もトラヒックが検出されなければ、その装置はそのリンクに送信することができる。もし、トラヒックを検出するならば、それはいずれかの局同士のコネクション状態でのトラヒックであるとみなされ、その装置は送信することができない。

省電力動作としてのスニフ動作については、IrLAPの規格書で別にルールを規定しているが、煩雑になるので、本書では触れないことにする。詳しく知りたい読者は、IrLAP 規格書の該当する記述を参考にされたい。

▶6.7.4.6 ルール6

競合状態にある装置は、500 ミリ秒以上の時間待機するという手続きを一度しか実行しないかもしれない。競合状態の手続きには、発見手順、アドレス競合解決手順、コネクション確立手順の三つがある。つまり、それぞれの固有のプロトコル動作において、競合状態を初期状態とする状態遷移において、次の状態遷移で定義する固有のタイムスロット（時間間隔）で動作るすように規定しているものがあるということである。

▶6.7.4.7 ルール7

HP-SIR においてフレーム送信中には、送信局は、文字間のタイミングが(ボーレートに関係なく)10 ミリ秒以下となるように調整する必要がある。文字間のギャップが10 ミリ秒以上であるような文字の組を含むフレームは、不正なフレームであるとみなされる。これらのルールは、IrLAP 手順においてすべてに優先される。理解しておくべきことは、通信のトラフィックが発生している場合は、500ｍS以上の間隔で物理層が空くことがないという枠をIrLAPのすべての通信条件において科すことで、NDM にある競合状態にある局は、単純に「500ms 以上の物理層の空きを検出するでけ」で通信に参加する機会を与えられるようにしたということである。これはルールであって物理的にはこのルールを破ることが出来ることに注意すべきである。実装に際しては、まず最初にこのルールに適合しているかどうかを検証しなければならない。

▶6.7.4.8 低水準のメディアビジーフラグ設定アルゴリズム（IrLAP 6.13.3参照）

以下の記述は、IrLAP 規格書に記載されているメディアビジー（トラフィックの検出）についてのアルゴリズムである。MediaBusyという変数は、状態マシンの中で、メディアの状態を示し、NDMにおける競合状態で、送信が正当か否かを指定するために用いられる。この変数の使用は、上のMACルールのルール5 に対応する。以下のアルゴリズムは、mediaBusy フラグを正しく設定するために用いられる。Boolean inFrame initially false-- フレーム受信中であることを示すboolean mediaBusy initially false-- メディアビジーフラグ

Begin

case 赤外線受信イベントis when 受信オーバーランまたはフレームエラーmediaBusy := true start mediaBusy timer when SOP 文字を受信if inFrame and 事前の文字がSOP 文字でないthen mediaBusy := true start mediaBusy timer else inFrame := true when EOP 文字を受信if inFrame then n フレームを受信完了したinFrame := false if CRC 照査エラーもしくは、自局宛てアドレスでないthen mediaBusy := true start mediaBusy timer endif else mediaBusy := true start mediaBusy timer when 文字を受信(SOP やEOP 以外)if not inFrame then mediaBusy := true start mediaBusy timer when mediaBusy timer expires mediaBusy := false end case

end.

▶6.7.4.9 高水準のメディアビジーフラグ設定ルール（IrLAP 6.13.4参照）

前のアルゴリズムは、mediaBusy が低レベルでのセットにどのように記述した。MediaBusy が操作の間のセットに方法のためのルールを述べておく。1) 発見／アドレス競合解決手順が成功した後、イニシエータ側の手続きは、mediaBusy を false にのセットする。これは、、500ms まつことなく接続手順に入る機会を装置に与える。2) 発見／アドレス競合解決手順のプロシージャへのレスポンダのmediaBusy フラグはfalse へのセットされる可能性がある。しかし、その手続きから、つぎの手続き実行するイニシエータを許容することは、競合解決手続きもしくはコネクション確立のアドレス指定を行う前に、レスポンダは（70-100 ms）を待つことは強く推奨される。

3) そのレスポンダのWD タイマーが発見/アドレス競合解決の間、タイムアウトなるならば、プロシージャmediaBusy はTrue へのセットする。4) 装置が接続状態（NRM）から切断状態（NDM）への移行する場合、mediaBusyはTrue にセットする。簡単に言えば、１）、２）は、発見手順、アドレス競合回避手順を行った後は、引き続きメディアビジーを検出することなく継続して接続手順を実行できることを意味する。また、3）は、WD（ウォッチドッグ）タイマを使用して、イニシエータがおこなう発見手続き、アドレス競合回避手続きが終了しないでプロトコルがロックしてしまうのを避けることができることを意味する。4）は、切断後、再接続する場合は500ms 待たなくてはならないことを意味する。つまり現在の通信が切断するのを待つ装置と平等の競合状態になることを意味する。

▶6.7.5 ステートマシン・パラメータに対する制約（IrLAP 6.13.5参照）

メディア・アクセスルールに応ずるために、そのステートマシンの中で定義されたいくつかのパラメータは、とりうる範囲に制限がある。これらの範囲は、下で指定される：

▶6.7.5.1 P-タイマー・タイムアウト：

P タイマー・タイムアウトは、500 ms を決して上回ってはならない。

▶6.7.5.2 F-タイマー・タイムアウト：

F タイマー・タイムアウトは、500 ms を決して上回ってはならない。

▶6.7.5.3 スロット-タイマー・タイムアウト。

発見手順、アドレス競合解決手順にで使用するスロット・タイマー・タイムアウトは、85 ms を決して上回ってはならないし、そして、常に少くとも25 ms 以上でなくてはならない。P タイマとは、一次局がポールビットつきのコマンドを送信した場合（つまり相手に送信権を譲渡する）の相手からのレスポンスを待てる最大の時間を定義する。Fタイマは、二次局がファイナルビットつきのレスポンスを送信した場合（つまり相手に送信権を譲渡する）の相手からのレスポンスを待てる最大の時間を定義する。スロットタイマについては、発見手順において説明する。

▶6.7.6 アドレス指定

IrLAP は、アドレス指定情報の2 つのクラスを利用する：

▶6.7.6.1 ハンドル：

IrLAP によって割り当てられ、上位層に通知される。上位層は、サービスリクエストを使用する場合のいろいろなIrLAP資源（例えば接続）を指定するためにハンドルを用いる。

▶6.7.6.2 アドレス：

通信の両端にあるIrLAP 層で割りあてられ使用される。対向するIrLAP同士のレイヤーは、それらの通信の中でアドレス情報として、装置アドレスとコネクションアドレスの2 つのタイプを使用する。このアドレスとハンドルは上位層のサービスにおいて関連付けられ使用される。

▶6.7.6.3 装置アドレス：

IrLAP レイヤーを識別するためにユニークに用いられる３２ビット値。その装置アドレスは、IrLAP 層で生成され、内部で使用維持される。IrLAP レイヤーが初期化されるとき、３２ビットの一様乱数を生成してその装置アドレスとして使用される。アドレス衝突がもう一つの装置によって検出されるならば、IrLAP 層はその装置アドレスを変えるための要求を出すことがある。IrLAP が接続していない（NDM）状態にあるならば、IrLAP 層はそのような要求を受けることがある。NRMにおいては装置アドレスは固定される。装置アドレスは、リトル・エンディアンのバイトオーダーで定義される。

▶6.7.6.4 接続アドレス：

7 ビットの値であり、すべてのIrLAP フレームにおいて、ユニークに二次局を識別するアドレスである。（B'0000000）は使用されず、ブロードキャスト（同報）で使用する場合は（B'1111111）に設定される。接続が確立されるときはいつでも、一次局は任意の7-bit値を割り当てる、そして、接続アドレスとしてそれを割り当てる。

▶6.7.6.5 装置・ハンドル：

IrLAP によって生成される。そして、IrLAP 層の装置アドレスを上位層が参照するために使用される。

▶6.7.6.6 接続ハンドル：

IrLAP によって生成される。そして、IrLAP 層は上位層に接続している2つの装置の現存する接続を識別するため使用する。接続ハンドルは、接続が維持されている間のみ有効である。NDM 状態において、局は同報接続アドレスにおいては、同報装置アドレスを含むU-frames によって自分のの装置アドレスを処理することを要求される。つまり、処理が必要のないIフレーム、Sフレームについては、DM 応答が必要でないことを意味する。したがって黙って無視されなければならない。

NRM 状態でで、局は、参加している接続の接続アドレスを含むフレームを処理することをだけを要求される。同報接続アドレス（たとえそのフレームがブロードキャスト・装置アドレスかそれらの装置アドレスを含むとしても）そのフレームを無視する。

▶6.7.7 装置発見手順／アドレス衝突解決手順

発見(discovery)手順の目的は、赤外線の到達する空間上に、通信参加できる局を検索し、接続するに必要な情報を得るために使用され、通信するたびごと(IrLAP の層が動作している間)のみ有効な装置アドレスやその他のキーとなる属性の決定を行なうことにある。装置アドレスは発見手順において重複する可能性があるので、装置アドレスを一意にするためのアドレス衝突解決手順が規定されている。

▶6.7.7.1 装置発見手順の概要

発見手続きを行なう局を起動局（イニシエータ）と呼び、答える局を応答局（レスポンダ）と呼ぶ。発見手続きが終了して、ユーザレベルへのサービスとして提供される発見ログには、4 種類の情報が含まれている。1）solicit/unsolicitedこの情報は、どの起動局に装置が見つけられたか、または、どの応答局からのなのかを示す。(応答局は、発見手続きの最後に送る情報（フレーム）を基に、起動局の情報を取ることができる。)2）sniffer/non snifferスニフィングを行なう局かどうかを示す。

3）装置アドレス32 ビットの装置を示すアドレス。4）発見情報装置の属性となるキーに関する情報。上位層から設定されそのままログ内に登録される。

▶6.7.7.2 装置発見手順の動作

発見手続きでは次の様なことが行なわれる。

1. 起動局は、発見手続きにn個のスロットがあることを示す発見XIDコマンドフレームを

ブロードキャスト(同報)する。

2. 発見XID コマンドを受信した全ての局は、応答局となり、0 からn-1 まで(0, n-1 を含

む)の乱数を発生させる。もし、乱数が0 ならば、応答局は、即座に発見XID 応答を返す。その他の場合は、発生させた乱数とスロット番号が同じ発見XID コマンドを受信したら、XID レスポンスを返す。

3. 起動局は各スロット時間に合わせ、各スロットの先頭で、スロット番号(1 からn-1）を含

んだ発見XID コマンドを送信する。スロットタイマに基づいた間隔で、発見XID フレームを送信する。

4. 発見手続きが終了すると、起動局は、受けとった発見XID レスポンスを全て含んだdiscovery-log を上位のサービス・ユーザに通知する。応答局は、テーブルの中身か

ら、重複した装置アドレスや起動局と同じアドレスがあるかどうかをチェックする。重複したアドレスを検知した場合は、これを解決するために、アドレス衝突解決手続きを用いることができる。

▶6.7.7.3 装置発見手順の解説

一次局となって通信を行いたい装置は、まず最初にこの発見手順を行って周囲に存在する装置を検索しなければならない。IrLAP サービス・プリミティブのDISCOVERY 要求／指示／確認の動作手順である。ここで使われる32 ビット装置アドレスは、装置の割り当てられるアドレスであって、IrLAPフレームのアドレス部のアドレスではないことに注意しよう。HDLCで定義しているXIDコマンド／レスポンスは、局識別のための情報交換のために使用されることを想定しているので発見手順ではこのXID フレームを使用して、装置の情報を交換する。

▶6.7.7.3.1 発見手順／アドレス衝突解決手順で使用するXIDフレーム

コマンド XID frameレスポンス XID frame発見手順／アドレス衝突解決手順は、NDM 状態で行われるため、IrLAP のアドレスはブロードキャストを示すFE を使用する。情報（I）フィールドの先頭の1 バイトは、XID がどの目的によって使用されるかを識別するバイトであり継続するI フレームのフォーマットを規定する。IrLAP において、XID は発見手順、アドレス衝突解決、スニフ動作のみに使用されるため、現在1 のみが使用されている。ほかの値は今後の拡張のために予約されている。

下記に示されるように、発見、そして、アドレス競合解決フレームは同じフォーマットを利用する。唯一の違いは、「新規の装置アドレスを生成する」発見フラグ(DiscoveryFlags)の中のビットである。C/R = 1 Addr = X’FE’XID Command Format Identifier Format Specific 1 byte 1 byte 1 byte C/R = 0 Addr = X’FE’XID Response Format Identifier Format Specific 1 byte 1 byte 1 byte

▶6.7.7.3.2 発見手順／アドレス衝突解決 XIDコマンドで使用する情報（I）フィールドの内容

発見手順／アドレス衝突解決XID レスポンスで使用する情報（I）フィールドの内容発信元装置アドレス発信元装置アドレスは、フレームの送信側の32 ビットアドレスである。0 または(X`FFFFFFFF')を使用してはならない。

▶6.7.7.3.2.1 宛先装置アドレス

宛先装置アドレスは、フレームの受信側の32 ビットアドレスである。X`FFFFFFFF'の宛先アドレスは、すべての装置を表す装置アドレスである。すべての装置はX`FFFFFFFF'アドレスに対する応答が必要である。XID 自体のアドレス部（A）はブロードキャストであるが、特定の宛先装置アドレスが与えられた場合は、その装置に対してのみのXIDコマンドが有効である。XIDレスポンスはイニシエータのアドレスに設定した宛先装置アドレスを設定しなければならない。例外はスニフィングである。

▶6.7.7.3.2.2 発見フラグ

発見手続きを制御したり、アドレス衝突を回避するために使用される。コマンドフレームのフォーマット識別子をX`01'に設定して、発見フラグを使用する。レスポンスフレームは、応答するコマンドフレームのパラメタと状態を示すために、フラグを使用する。各ビットは以下の意味をもっている。ビット0,1 はスロット数を示すために使用される。Bit 1 Bit 0 meaning 0 0 1 slot 0 1 6 slots 1 0 8 slots 1 1 16 slotsビット2は、「新装置アドレス生成」を指示するために使用される。コマンドフレームに設定された場合、このフレームで指示された宛先装置アドレスをもつ全装置は、新装置アドレFI X’01’Source Device Address Destination Device Address Discovery Info(final slot only)1 byte 4 bytes 4 bytes Discovery Flags 1 byte Slot Number Version Number 1 byte 1 byte 32 bytes FI X’01’Source Device Address Destination Device Address Discovery Info 1 byte 4 bytes 4 bytes Discovery Flags 1 byte Slot Number Version Number 1 byte 1 byte 32 bytesスを生成しなければならないことを意味する(これはアドレス衝突回避のために使用されるメカニズムである)。レスポンスフレームに使用された場合、装置は新アドレスを生成したことを意味する。

ビット3-7 は将来のために予約される。これらは0 に設定される。

▶6.7.7.3.2.3 スロット番号

スロット番号は、現在の発見スロットの数を示すために、発見手順のためのXID コマンド内で使用される。最初の発見XID フレームには、スロット番号0 が含まれる。このフレームは発見プロセスを開始し、スロット0の始まりを示すものである。その後のスロットには対応するスロット番号が設定される。発見コマンドフレームは「スロットの開始 Begin Of Slot」(BOS)フレームと呼ばれる。スロット番号値X`FF'は発見プロセスの終了を示す。スロット番号フィールドは発見XID レスポンスフレームにおいては定義されない。

▶6.7.7.3.2.4 IrLAP バージョン番号

このフィールドにはIrLAPのバージョン番号が設定される。IrLAP1.0およびIrLAP1.1ではX`00'に設定する。

▶6.7.7.3.2.5 Discovery Info(発見情報)

discovery info はその中身がサービス・ユーザによって規定される最大32 バイト長のフィールドである。IrLAP 層は単にこの情報を発見手続きの間にある局から別のある局へ転送する。上位層はこの情報を使ってより抽象的な発見情報を得ることが出来る。

▶6.7.7.4.1 装置発見手順の例

この図は、NDM にある4 つの装置間の発見手順の例を示している。装置A は、メディアビジーでないことを確認し、発見手順に使用する情報（I）フィールドをもつ最初のスロット0 を送信する。すると、装置B,C,D はそれぞれ0 から7 までの乱数を発生させ、装置B は2、装置C は6、装置D は5 のXID(A,0)XID [1]XID [2]XID [3]XID [4]XID [5]XID [6]XID [7]XID [FF]A B C D XID resp.XID resp.XID resp.select slot 2 select slot 6 select slot 4乱数を生成したとしよう。

イニシエータとなった装置A は、スロットタイマーで規定した間隔でスロット番号をインクリメントさせながら発見XIDコマンドを発行する。スロット2で装置B、スロット4で装置Dが、スロット6で装置CがXID レスポンスを使用して応答する。装置A は7 スロットの発見スロットを送信した後、Discovery Info をもつ終了スロットを送信する。この時点で、装置A のサービス・ユーザ層には、Discovery.確認サービス・プリミティブによって発見ログが通知される。一方、装置A の送信した最後のスロットの情報を使って、装置B,C,D は、それぞれのサービス・ユーザ層にDiscovery.指示サービス・プリミティブを使って発見情報を通知する。

▶6.7.8 アドレス衝突解決手順の概要

アドレス衝突を解決する手続きは、同一のIrLAPリンク層で、同じ通信範囲に二つ以上の局が同一の装置アドレスを通知したとき使用される。アドレス衝突を解決する手続きは、アドレス衝突を起こしている局に衝突を通知し、衝突しないような新しいアドレスを生成するための手順である。アドレスの衝突は、装置発見手順を行う場合に、同じ装置アドレスを持った複数の装置が同一の環境にある時に発生する。

▶6.7.8.1 アドレス衝突解決手順の動作

衝突解決を行う局は、衝突している装置アドレスに対して、アドレス衝突フラグを設定したXID コマンドフレームを送信する。このコマンドは、その衝突している装置アドレスを持つ装置に対して新しいアドレスを生成させる。S個の衝突した装置があった場合を仮定すると、受信局は、XIDコマンドに対して、発見手順とS 個のタイムスロット内でレスポンスを行う。XID コマンドを受信した各局は、新しい装置アドレスを設定しなおし、0 からs-1 までの乱数によりタイムスロットを選択する。アドレス衝突解決手順は、発見手順同じ状態マシンを用いる。異なる点は、発見コマンドのXID フレームにおいて宛先装置アドレスが指定されることにより、特定の衝突を起こした装置アドレスだけにに送られ、これが全ての衝突を起こした局へマルチキャスト（選択同報）される点である。発見コマンドのXIDは、「アドレス衝突」フラグが設定されており、それを受信した局が新しいアドレスを選択し、その新しいアドレスを発見XID レスポンスフレームの発信元装置アドレスに設定し通知する。

▶6.7.8.2 アドレス衝突解決手順の例

この例は、アドレス衝突を解決を行おうとしている局Aと同じ装置アドレスを持つ２つの局Bに対しての手順の例である。局A は、発信元装置アドレスA、宛先装置アドレスB として「アドレス衝突」フラグが設定されているXID コマンドを送信する。宛先装置アドレスがB になっているので、装置アドレスB を持つ2 つの装置にマルチキャストされ、２つの局は装置アドレスを振りなおし、同様にレスポンスのスロットを乱数によって決定する。以降の手順は発見手順と同様である。

XID (A,B)XID [1]XID [2]XID [3]XID [4]XID [FF]A B B XID resp.XID resp.select slot 2 select slot 4

▶6.7.9 接続手順

アドレス発見手続きを用いて装置アドレスを決定した局との間でIrLAP のコネクションを確立するために用いられる。装置発見手順で、装置が手に入れることが出来るのは、装置アドレスと、上位のサービス・ユーザ層に通知する装置情報の２つである。IrLAP では、この二つの情報のうち装置アドレスだけを使用しHDLC と異なる接続手順によりデータリンクを確立する。IrLAP の要となる接続手順について学ぶことにしよう。

▶6.7.9.1 接続手順の概要

二つの局でコネクションを設定するためにこの手順を行う。片方もしくは両方の局がSNRM フレームを送信することにより、能動的にコネクションを確立しようとする場合もある。SNRM フレームは送信側がサポートできるコネクションパラメタ(ボーレートなど)を示すための拡張フィールドを含んでいる。SNRM フレームを受信すると、その局はそのコネクション要求を受け入れるか否かを決定する。受け入れるのであれば、相互に受け入れられるパラメタを折衝するための手続きを用い、コネクションを受け入れ、これらのパラメタを示すためのUA フレームを送信する。受け入れない場合には、DM フレームを返してその旨を通知する。

▶6.7.9.2 接続手順の解説

HDLCの場合は、SNRMコマンドやそれに対するUAレスポンスには原則として情報部をもたないが、IrLAP の場合には柔軟な接続が出来るように多くのパラメータが必要となる。そのために、接続時に交換されるSNRM コマンドとUA レスポンスに情報部を追加することでパラメータを交換し、後に議論する決められた折衝ルールの基づいて接続をおこなう。

▶9.7.9.2.1 接続要求で使用するSNRMコマンドの情報（I）フィールド

Negotiation Parameters 4 bytes 4 bytes 1 byte N bytes Destination Device Address Source Device Address Connect Address 7 6 5 4 3 2 1 0 C/R=0 New connection address

▶6.7.9.2.2 接続応答で使用するUAレスポンスの情報（I）フィールド

上記の情報（I）フィールドは接続手順で使用されるSNRM コマンドおよびUA レスポンスに含む情報（I）フィールドのフォーマットである。接続手順以外において、リセット要求コマンドで使用するSNRM や、切断レスポンスで使用するUA には情報（I）フィールドが使用されないことに注意しよう。コネクト要求で使用されるSNRM コマンドのアドレス（I）フィールドは、H”FF”である。なぜなら、コネクションが確立していない状態（NDM）HDLC の装置番号に該当するアドレスは決定されておらず、このSNRM によって初めてアドレスが決定されるためである。プロトコル動作を原理的に説明すると、SNRM コマンドを同報により周辺の装置に通知し、情報（I）フィールドにある宛先（Destination）装置アドレスをもつ装置とコネクションを確立しようと試みていることを表明している。

接続が受理されれば、情報（I）フィールドにある接続アドレス（Connect Address）をコネクション確立後のフレームのアドレスフィールドに使用する。SNRM コマンド、UA レスポンスの情報フィールド（I）に共通する折衝(Negotiation)パラメータは、IrLAP 固有の折衝手順を用いてサービスの品質（QOS）を決定する。交換された折衝パラメータはUA レスポンスが交換された以降に有効になる。

▶6.7.9.2.3 接続シーケンスにおける折衝パラメータが有効になるタイミング

サービスの品質（QOS）を決定する折衝パラメータには、通信速度、フレームサイズ、ウインドウサイズ、追加のBOF、最小ターンアラウンドタイム、最大ターンアラウンドタイム、リンク解放/スレシホールドタイムなどの多くのパラメータがある。折衝パラメータについてより詳しく見ていくことにしよう。

▶6.7.10 IrLAPにおける折衝手続き

折衝は、接続する二つの局がボーレート、最大ターンアラウンドタイム、データサイズ、ウインドウサイズ、BOF の数、最小ターンアラウンドタイム、リンク解放/スレシホールドタイムという7 つのコネクショSource Device Address Destination Device Address Negotiation Parameters 4 bytes 4 bytes SNRM UA RR新規パラメータ新規パラメータA(dis):B(dis):ンパラメタに合意するプロセスである。これらのパラメタは接続に使用されるSNRM コマンド／UA レスポンスと、コネクション中のパラメタを変更するのに使用されるXID フレームの交換により折衝される。

▶6.7.10.1 IrDAパラメータ表現の基本

IrLAP 規格に限らず、IrLMP、TinyTP、IrCOMM などで使用されるパラメータ表現のほとんどのはここで述べるパラメータ形式によって表現される。パラメタの骨格は、パラメタ識別子(PI)、パラメタ長(PL)、パラメタ値(PV)の組として定義される。PIとPL の組は各々1 バイトで表す。PV の長さはPL バイトである。このパラメータ表現の優れている点は、新しいパラメータが追加されたり、特定のパラメータの長さが拡張された場合でも、正しいアルゴリズムで処理されているならば、変更による影響を受けにくいという点にある。このパラメータを走査しているプログラムが未定義のパラメータ識別子（PI）を検出した場合は、パラメタ長(PL)分だけスキップしてそのパラメータを無視することができる。またパラメタ値(PV)の長さが変更になった場合でも、パラメータ内部でのバイトオーダーを正しく処理していればパラメータの誤確認は避けられる。実装においては、今後のプロトコル拡張などによる他のパラメータを追加などを想定して対処できるようにしておく必要がある。

!"#$%列PI PL PV PI PL第一!"#$%(if present)第二!"#$%(if present)..........PV

▶6.7.10.2 折衝パラメータの詳細

折衝パラメータは、２つのタイプに区分される。ひとつは、両局が合意し同一のパラメータを選択するもの（タイプ0）と、それぞれの能力を通知し合うもの（タイプ１）がある。タイプ1 のパラメータは、相手に対するプロトコル動作や時間的要素を決定する。

▶6.7.10.2.1 ボーレート

ボーレートパラメタは、そのデータリンクチャネル上で両局が転送する速度を指示する。両局は同じボーレートに合意しなければならない。ボーレートパラメタ (PI=X`01',タイプ0)ビット0 = 2400 bpsビット1 = 9600 bpsビット2 = 19200 bpsビット3 = 38400 bpsビット4 = 57600 bpsビット5 = 115200 bpsビット6 = 576000bpsビット7 = 1152000bps 4000000bps をサポートする場合は、2 バイトで表現されるビット8 = 4000000bpsビット9 からビット15 は将来のために予約され0 にセットする。

例えば、すべてのボーレートをサポートする局はボーレートパラメタをB‘0000000111111111’ (X‘01FF’)に設定する。9600bps と115200bps だけをサポートする局はボーレートパラメタをB`00100010'(X`22')に設定する。

▶6.7.10.2.2 最大ターンアラウンドタイム

最大ターンアラウンドは、局がP/F ビットを保持できる時間（送信権を保持できる時間）の最大値である。このパラメタは、ボーレートパラメタとともに、P/F ビットを設定したフレームを送信することによって他の局に物理層の利用権を与えるまで、局が送信を行なうことのできる最大バイト数を決める。最大ターンアラウンドタイムは、最大データサイズパラメタやウインドウサイズパラメタよりも優先度が高い。このパラメタは、ある局によってもう一方の局に送信の順番を与える前に送信可能な最大時間を指示するために使用される。このパラメータは、局毎に独立に折衝され、50msはボーレートが115200のときのみ有効である。

最大ターンアラウンドタイム (PI=X`82',タイプ1)ビット0 = 500msビット1 = 250msビット2 = 100msビット3 = 50msビット4 から7 は予約。0 に設定しなければならない。(1-3 ビットは115200bps 以上の場合のみ有効である)最大ターンアラウンドタイムは、大きくすれば、長いデータフレームを送信できるため、プロトコルヘッダーや折り返しのオーバーヘッドが小さくなるが、データレスポンスが悪くなる。逆に小さくすると、プロトコルオーバーヘッドは大きくなるが交互のデータ交換の回数が増えるのでデータレスポンスはよくなる。したがってアプリケーションの動作によるトレードオフが必要となる項目である。

▶6.7.10.2.3 データサイズ

データサイズは、そのコネクションの期間中に受信するフレームに許容されるデータバイトの最大数である。つまり、自局の「最大受信可能な情報（I）フィールドのサイズ」を通知する。コネクションに対する実際の最大フレームサイズはボーレートと最大ターンアラウンドタイムに合うように調整しなければならない。このパラメタは両局で独立に折衝される。データサイズ(PI=X`83',タイプ1)ビット0 = 64 バイトビット1 = 128 バイトビット2 = 256 バイトビット3 = 512 バイトビット4 = 1024 バイトビット5 = 2048 バイトビット6、ビット7 は予約。0 に設定しなければならない。

例えば、任意のサイズのフレームを送受信できる局はデータサイズパラメタをX`3F'となる。128 バイト(あるいはそれ以下)のフレームだけを送受信できる局はX`03'となる。

▶6.7.10.2.4 ウインドウサイズ

ウインドウサイズは、その局が確認を送らずに受信できる未確認のI フレームの最大数である。つまり、一回の送信でI フレームを何回まで連続送信できるかを通知する。このパラメタはウインドウに対する最大許容値であるが、必ずしも実際に使うウインドウサイズである必要はない。実際のウインドウサイズはボーレートと最大ターンアラウンドタイムに合うように調整しなければならない。また、実際の最大フレームサイズを考慮しなければならない。このパラメタは両局で独立に折衝される。

ウインドウサイズ (PI=X`84',タイプ1)ビット0 1 フレームウインドウビット1 2 フレームウインドウビット2 3 フレームウインドウビット3 4 フレームウインドウビット4 5 フレームウインドウビット5 6 フレームウインドウビット6 7 フレームウインドウビット7予約。0 に設定しなければならない。例えば、7フレームまで受けることのできる局はウインドウサイズパラメタをX`7F'となる。交互にフレームを交換する必要がある場合は（ストップアンドウエイト）X`01 に設定する。

▶6.7.10.2.5 BOF数

BOF 数パラメタはすべてのフレームの最初に必要な追加フラグの数を表す。このパラメタの主な目的は、割込み中断期間(interrupt latency)が長い装置に対して個々のフレームの先頭において遅延を与えることである。HP-SIR 方式の場合の計算この遅延は115200bps においての一文字送信に要する時間(約87 us)に基づく。このパラメタ値は115200bpsでフレームを送る時にも必須の一つのBOFに追加が必要なBOFの数である。他のボーレートで追加となるBOFの数は、選択パラメーター値を115200/ボーレートと等しい要因で割ることによって計算される。

IBM-MIR 方式の場合の計算必須のBOF（2つのフラグシーケンス）を使用するか、4つのフラグシーケンスを使用するかを表し、パラメータが0 の場合は、2 つのフラグシーケンスを使い、それ以外は、4 つの触れ具シーケンスを使用する。（ただし、IrPHY物理層で追加のフラグシーケンスを生成することができる場合に反映させる）。SHARP-FIR 方式この場合は、このパラメータは無視される。追加BOF 数(PI=X`85',タイプ1)ビット0 115200 で48 個の追加BOFビット1 115200 で24 個の追加BOFビット2 115200 で12 個の追加BOFビット3 115200 で5 個の追加BOFビット4 115200 で3 個の追加BOFビット5 115200 で2 個の追加BOFビット6 115200 で1 個の追加BOFビット7 115200 で0 個の追加BOFこのパラメタは両局で独立に折衝される。

次の式は、「BOF数」パラメタとして折衝した数に対して他のボーレートで必要となる追加BOF数を計算するために使用される。2400bps = BOF 数パラメタ値/48 9600bps = BOF 数パラメタ値/ 12 19200bps = BOF 数パラメタ値/6 38400bps = BOF 数パラメタ値/ 3 57600bps = BOF 数パラメタ値/2 115200bps = BOF 数パラメタ値/ 1各種ボーレートと追加BOF の関係Baud Rate 48 BOF 24 BOF 12 BOF 6 BOF 3 BOF 2 BOF 1 BOF 0 BOF 2400 1 0 0 0 0 0 0 0 9600 4 2 1 0 0 0 0 0 19200 8 4 2 1 0 0 0 0 38400 16 8 4 2 1 0 0 0 57600 24 12 6 3 1 1 0 0 115200 48 24 12 6 3 2 1 0

▶6.7.10.2.6 最小ターンアラウンドタイム

最小ターンアラウンドタイムパラメタは、IrPHY 層の受信回路が、同じ装置からの転送（物理的な発光）によって生じる受信回路の飽和状態からの回復するまでに必要な時間(ターンアラウンド潜伏期)に対する遅延時間を扱う。このパラメタは局から最終フレームの最後尾のバイト送信された時点から、他局からのフレーム先頭バイトが受信可能になるまでの必要な時間に対応する。このパラメタは、リンクがターンアラウンドしたとき（つまりSNRM とUA が交換された後）から有効になり、局毎に独立に折衝される。

最小ターンアラウンドタイム (PI=X`86',タイプ1)ビット0 = 10msビット1 = 5msビット2 = 1msビット3 = 0.5msビット4 = 0.1msビット5 = 0.05msビット6 = 0.01msビット7 = 0msターンアラウンドの遅延を作るには二つの方法がある。最初の方法は最初のフレームを送る前に何も送信せずに特定の時間を待つ方法である。二番めの方法は要求されるターンアラウンドタイムを占めるように最初のフレームの前にいくつかのBOF を送信する方法である。

追加BOF と最小ターンアラウンドタイムの関係追加のBOF も、最小ターンアラウンドタイムもともに、物理層に対する送信の交換の際の待ち時間を規定しているともいえる。追加BOF の場合は、フレームの先頭にあるBOF はフラグシーケンスなどが受信回路で検出しそこなうのを防止する目的であり、遅延時間は、受信AGC（Auto Gain Control）回路のサチレーション（飽和）復帰時間の確保である。これらのパラメータは物理層（選択した赤外線素子）で決まってしまう。当然のことながら、追加BOF＝0、最小ターンアラウンドタイム＝0が望ましいのはいうまでもない。HP-SIR レベルではそれほどパフォーマンスに影響しないが、4000000bps 程度になると、実際に送信している時間よりも待ち時間が長くなって極端にパフォーマンスを落としてしまう可能性がある。

▶6.7.10.2.7 リンク解放/スレシホールドタイム

リンク解放/スレシホールドタイムは、物理層においての光学的な遮断や、実際に相手局移動してリンクが取れなくなった場合などの不測の事態の場合に、リンク解放をするまでの、無応答許容期間（有効なフレームを受信できずに待機する時間）を制御するために使用される。この状態と関連して、状態指示プリミティブをサービス・ユーザ層に送る(この通知はは、上位層でユーザに警告メッセージを表示するために使用できる)。以下に示す値はリンク解放までの秒数である。これらの値の各々は同時に示されるスレシホールドタイムを含む。このパラメタは一次局と二次局の両局で合意されなければならない。

リンク解放/スレシホールドタイム (PI=X`08',タイプ0)ビット0 3 秒 (スレシホールドタイム= 0)ビット1 8 秒 (スレシホールドタイム= 3 秒)ビット2 12 秒 (スレシホールドタイム= 3 秒)ビット3 16 秒 (スレシホールドタイム= 3 秒)ビット4 20 秒 (スレシホールドタイム= 3 秒)ビット5 25 秒 (スレシホールドタイム= 3 秒)ビット6 30 秒 (スレシホールドタイム= 3 秒)ビット7 40 秒 (スレシホールドタイム= 3 秒)

▶6.7.10.2.8 デフォルトの折衝パラメータ

装置が正規切断モード（NDM）である競合状態にある場合、通信速度など折衝に必要な情報は何一つ交換されていない。したがって、NDM 状態の装置は、デフォルトの状態で待機または、通信を開始しなければならない。接続シーケンスにおいて、SNRM コマンドと/UA レスポンスが交換されるまでの、XID による発見手順アドレス衝突解決手順、SNRM/UA 交換による接続シーケンスを行っている場合はすべてデフォルトの折衝パラメータを使用する。このことで、能力の異なる装置同士が柔軟に接続を行うことを可能に強いるのである。

デフォルト折衝パラメータ表通信速度9600bpsウインドウサイズ1最大データサイズ64 バイト最大ターンアラウンドタイム500ms BOF 数10

▶6.7.10.3 折衝手続き

先に述べたように、折衝パラメタは、PI, PL, PV の三つ組によって構成されるパラメタの列からなる。折衝パラメタには、タイプ0 とタイプ1 の二つのタイプがある。タイプ0 パラメタを設定する時には、装置がサポートできるパラメタ値の相当するすべてのビットを1 にしなければならない。タイプ1 パラメタを設定するときには、選択する値に対するビットを設定するだけでよい。それ以外のビットに対しても、実行可能な代替値があるならば、設定することを推奨している。

▶6.7.10.3.1 タイプ0パラメタ折衝の手続き

ステップ1一次局は、サポートできるPV のすべてのビットを1 にして、SNRM フレームを送信する。ステップ2二次局は、SNRM フレームを受信すると、SRNM 折衝値と自分のサポートできる同じパラメタフィールドの論理的なAND をとって、自分の能力と一次局の能力の共通部分を作り出す。ステップ3この操作の結果は、SNRM-UAフレームに含まれ、コネクション中に使われるパラメタを決める。ステップ4折衝パラメータ値ので 1 に設定されビットのうち最上位ビットが選択される。PVフィールドが複数バイトあるならば、選択されているもののうち最上位バイト(最初に受信したもの)とする。その時点で定義されているバイトは常に最下位バイトとなる。

▶6.7.10.3.2 タイプ1パラメタ折衝の手続き

タイプ1 パラメタは個別に折衝されるので、PV フィールドは単に1 に設定された最上位ビットをスキャンするだけである。そのビットは(タイプ0 パラメタのステップ4 のように)選択された値とみなされる。定義されていないビットは、設定された最上位ビットを探す際には無視される。上記の手続きに続いて、ボーレート、最大ターンアラウンドタイム、データサイズ、ウインドウサイズの折衝値が一貫性のためにチェックされる。

「要求ライン能力」＜ 最大ライン能力「通信速度、最大ターンアラウンドタイム」をチェックすることによって行なわれる。この関係が満たされていない場合は、これが満たされるようにウインドウサイズかデータサイズパラメタを減らさなければならない。「要求ライン能力」は次のように計算される。要求ライン能力 ：＝ ウインドウサイズ×（データサイズ+6+BOF 数）＋バイト数換算の最小ターンアラウンドタイムBOF 数、ウインドウサイズ、データサイズはそれぞれ折衝により決定される値である。

▶6.7.10.3.3 バイト数換算の最小ターンアラウンドタイム表（単位バイト）

Baud Rate 10ms 5ms 1ms

9600 10 5 1 0 0 0 0 19200 20 10 2 1 0 0 0 38400 40 20 4 2 0 0 0 57600 58 29 6 3 1 0 0 115200 115 58 12 6 1 1 0 576000 720 360 72 36 7 4 2 1152000 1440 720 144 72 14 7 1 4000000 5000 2500 500 250 50 25 5

▶6.7.10.3.4 バイト数換算の最大ライン能力表（単位バイト）

Baud Rate 500ms 250ms 100ms 50ms 9600 400 n/a N/a n/a 19200 800 n/a N/a n/a 38400 1600 n/a N/a n/a 57600 2360 n/a N/a n/a 115200 4800 2400 960 480 576000 28800 11520 5760 2880 1152000 57600 28800 11520 5760 4000000 200000 100000 40000 20000この計算式を使用して、実際のデータサイズ、ウインドウサイズが計算される。

▶6.7.11 省電力待機モードスニフィング

スニフ手順は、装置が電力の浪費をせずに、局がコネクションの設定を望んでいることを周辺に存在する装置にブロードキャストを使用して通知するためのものである。

▶6.7.11.1 スニフィングの動作

基本的手続きを以下に示す。ステップ１スニフィングを行なう装置は、休止状態が終了すると短期間の目覚め、受信を行なう。他局が通信中であれば休止状態に戻る。ステップ２他にトラヒックがなければ、宛先装置アドレスをFFFFFFFF に設定したXID レスポンスフレームを送信する。このフレームは、二次局としてコネクションを設定したいことを示すもとしてIrLAP で定義されているものである。他の発見XID 応答とは装置アドレスが異なることで、他局はスニフィングを行なっている局があることを検出することができる。

ステップ３この局は、XID コマンドフレームか自局の装置アドレスが相手局として指定されたSNRMフレーム、および宛先装置アドレスにFFFFFFFFが指定されたXID などの自局宛のメッセージを短期間待つ。XID 発見フレームの場合は、スニフィングを行なう局は発見手続きに入るが、発見レスポンスフレームではなく、スニフィングフレームで応答する。ステップ４いかなるフレームも送信されなければ、スニフィングを行なう装置は休止状態に入り(通常2，3 秒)、もう一度最初から始める。

簡単に言えば、通常の接続手順は、物理層がつねにアクティブであることを要求しているのに対して、スニフィングの場合は、間欠的に物理層を活性化し少しの間の活性化中に近くに存在する通信相手に対して、接続もしくは発見手順を勧告する手順であると解釈すればよい。これ以上の詳細は規格書を読んでもらいたい（IrLAP 6.9 Sniff-Open Procedure を参照のこと）

▶6.8 IrLAP規格のまとめと今後の方向性

以上で、IrLAPに関係する説明を終わりにするが、ここまで読み進めれば、IrLAP規格書だけでなく、HDLCや、IrDAの上位層の規格書、その他、類似する規格書について抵抗なく読むことができる知識が備わったはずである。断っておくが、本書は、IrDA 規格書を単純に抜書きしているのではない。IrDA の規格書において、理解しにくい個所については、技術的な背景を解説し、標準的でないIrDA 固有の問題についてIrDA 規格がどのような背景と技術を使用して解決しているのかを丁寧にしらべることで、規格書そのものを読みこなせるようにすることを目的にしている。必要があれば、規格書の本文に基づいて必要個所を参照し解説しているが、原文に対して忠実ではないことに注意していただきたい。それは、原文に忠実であるよりも、著者なりの解釈、理解に基づく、IrDA 規格書の行間に感じ取れたプロトコルの思想や背景を追いつつ、読みこなすためのヒントを多く与えたいという意図があるためである。もし、プロトコルを実装することを目的にするならば、本書の記述にたよることなく、IrDA 発行の規格書の原文に基づいて行っていただきたい。

IrLAP 規格の章では、XID を交換することによる 装置発見とアドレス衝突解決手順。SNRM/UA と拡張パラメータ（折衝パラメータと手順）による柔軟な接続手順。省電力動作を想定したスニフィング手順。HDLC の同時監視式転送手順を使用した高速なデータ転送手順。赤外線の物理的特性を加味した、メディアアクセス（MAC）ルール。について詳しく学習した。またIrLAP プロトコルを理解するために必要となる、サービス・プロバイダとしてのIrLAP サービスプリミティブの理解。

フレーム構造（S）フレーム、（U）フレーム、（I）フレームの詳細。折衝パラメータの基本記述形式と、実際の折衝パラメータと折衝手順。プロトコルの動作を視覚化するフレームシーケンスチャートの見方。完全なプロトコル記述のための状態マシンと状態遷移表の考え方と見方。など、基本となるHDLC 規格やプロトコル記述に必須な七つ道具について議論した。IrLAP 規格書と本書を通じて、プロトコルがどのように定義されるのか、また、規格書というものがどのような性格を帯びていて、何を記述することで必要十分であるのかご理解いただければ著者の意図する目的を果たしたことになる。では、最後にIrLAP の最近の動向にスポットを当てつつIrLAP の章を閉じることにしよう。

▶6.9 IrLAP層の高速化、効率化をもとめて

IrPHY層について、SHARP-FIRの4倍の速度であるVFIR規格(16Mbps)が検討されている。それに伴うより高速なプロトコルの変更が必要になる。現在のIrLAP 規格では、最大のウインドウサイズ、最大のフレームサイズを使用しても、高々一回の送信シーケンスで、2048×7 つまり14336 バイトしか転送できない。16Mbpsで単純換算すると7.168msの転送時間に過ぎない。したがって折り返しのプロトコルオーバーヘッドがばかにならなくなる。そこで現在IrDA で検討しているのは、つぎの事項である。

ウインドウサイズの上限を最大127 に拡張することで大量のデータを一気に送れるようにすること。それに伴う追加機能についての折衝パラメータを拡張することウインドウサイズを拡張する方法についてはすでに拡張HDLC 規格で規定されている。それは、情報転送手順に関係する情報（I）フォーマット、監視（S）フォーマットの制御フィールド（C）を2 バイトに拡張して、標準のHDLC のNr,Ns のビット数を3 ビットから7 ビットに拡大する方式をIrDA のテクニカル・コミッティで検討している。

HDLC の拡張形式を掲載しておくことにする。手順については、標準のHDLC と同じアルゴリズムを使用し異なるのはVr,Vs,Nr,Ns が0 から7 までと制限されていたのが0 から127 に拡張されるだけである。

▶6.9.1 拡張されたIフォーマット

▶6.9.2 拡張されたSフォーマット

N(R)1-7 0 2nd octet N(S)0 P/F 0 1-7 1st octet N(R)4-7 0 2nd octet 0 1 P/F 0 1-7 1st octet 0 S S 1 2 3

7. IrLMP規格書 (IrMUX/IAS) 多重化とデータベース

IrLMP は、（リンク管理 Link Management）を行う。リンク管理とは、物理的な通信経路に代えて論理的な通信経路を上位層に提供することである。IrLAP 層では、単独では信頼性を保証できない物理層に対して、FCS(Field Check Sequence)を付加し、検出した誤りを訂正するための手順を用意することで、信頼性のあるデータリンクを得ることができることを学んだ。また、赤外線通信手順としてIrDA 固有の発見手順と、柔軟な接続手順、そして同時監視式転送手順による高速転送についても深く学び取った。純粋に通信の媒体としてIrDA 規格を考えれば、IrLAP のもつ機能だけで十分であるといえる。

「IrDA 方式におけるプロトコル階層構造の概要」の章では、IrLMP 層についての簡単な概要について説明した、その中で、IrLAP が「いっぽんの太い本管」だとするとIrLMP はそれを小分けにする「分配する枝管」であるとも説明した。ここでは、IrLMP 層の基本的なモデルについてもう一度、考察しておこう。

▶7.1 経路多重化の意義「アプリケーション指向の多重化」

通常、多重化は、「高速である下位層を効率的に使用するために、ひとつの高速なサービス・アクセス・ポイントを分割して複数の論理的なアクセス・ポイントを構築する」と説明する場合が多い。しかし、IrDA 規格での多重化は少し異なっている。それは、「アプリケーション指向の多重化」であると一言で説明できる。「アプリケーション指向の多重化」とは、通常、あるアプリケーションから見た通信経路は、接続の相手先（これをエンド・ポイントと呼ぶ）がおなじアプリケーションであるとか、モデムを想定しているとか、LAN であるとか、実際的な接続相手を想定するようなモデルを考えているということである。たとえば、サーバー・アプリケーションを考える場合、そのサーバーは、下位層である通信経路に対して、サーバーに接続しようとしている相手から「検索可な能論理的経路」を用意していることを望むであろう。この機構がないと、サーバーシステムとしてのシステム構築がきわめて難しくなるし、アプリケーションが固有の機構としてこの機能を与えたとしたら、機器ごとに異なった方式になってしまい互換性の問題がでてくる。したがって、このような機構は、標準化し共通なアクセスルールにしたがって行われることが必要になる。

このような要請に基づき、IrLMP 層は、「経路の多重化」と「多重化に関するデータベース」をひとつの規格として扱っている。純粋なプロトコル層として考えるならば、「多重化に関するデータベース」は、経路多重化層の上に乗るひとるのアプリケーションであると考えられるが、IrLMP では切り離すことの出来ない規格として考える。

▶7.2 多重化モデル

▶7.3 IrLMPのサービスエンティティの構成

IrLMP は、複数の論理的なサービス・アクセス・ポイント（LSAP）を用意し、複数のサービス・ユーザに同時にデータリンクを与えるこの部分をIrMUX と呼ぶ。さらに、上位のサービス・ユーザを識別することを主な目的とする情報アクセスサービス（IAS）と呼ばれるデータベースを提供することも述べた。IrDA の場合、アプリケーションのためのフロー制御やサービスデータ単位の変換などの層は、その上位層のTinyTP（トランスポート層）で行い、純粋な多重化とデータベースの提供にとどめている。

上のアプリケーション（サービスユーザ層）からIrLMP を見ると、複数のアプリケーションがLSAPを取得するためのIAS と、アプリケーション自信に割り当てられたアクセスポイントにたいするサービス・プリミティブを使用して、IrLMP 層と情報を交換する。IrLMP は、アプリケーションごとにユニークなLSAPや、データベースエントリ（データベースに登録する情報）などのインスタンスを生成したり破棄したりする。

LM-IAS Services IrDA IrLAP Link Mgt. Multiplexer (LM-MUX)Applications Transport Entities Link Mgt.Information Access Service(LM-IAS)Transport Services LM-MUX Services IrLAP Services

▶7.4 IrMUXのサービスモデル

IrMUX（マルチプレクサ）は、複数のアプリケーションからアクセスできる、コネクション型（CO 型）の複数のエンドポイントとしてのLSAP と、コネクションレス型（CL 型）のLSAP、発見手順を起動するためのアクセスポイントを用意する。IrLAP 層で提供されるひとつのエンドポイントを、複数のコネクション型（CO 型）エンドポイント、コネクションレス型（CL 型）サービス・アクセス・ポイント、そして発見サービス・アクセス・ポイントの３つの論理的なサービス・アクセス・ポイントに分解する。コネクション型（CO 型）のアクセスポイントは複数生成され、互いに独立なサービス・アクセス・ポイントを提供する。

▶7.5 IrLMPのアクセスモード

IrLMP は、複数のアプリケーションにアクセスポイントを提供するが、それと同時にアクセスモードも提供する。IrLMP は、アクセスモードとして、2 つのモードを用意している。ひとつは排他的アクセスモードと多重アクセスモードである。

▶7.5.1 排他的アクセスモード(Exclusive Access Mode)

IrLMP 上で1 つのアプリケーションしか動作出来ない場合や、IrLMP で複数のアプリケーションのうち1 つのアプリケーションが活性状態でほかのアプリケーションが非活性（IDLE 状態）の場合など、IrLAPエンティティを特定のアプリケーションだけが独占することができるモードを用意している。プリンタなど複数のリンクを必要としないアプリケーションで使用される。IrLAP Service Boundary LM-MUX Service Boundary XID_Discovery Service Access Point Connectionless LSAP LSAP-Connection Endpoints LSAP IrLAP-Connection Endpoints ISAP LSAP-Connection Endpoints LSAP Station

▶7.5.2 多重アクセスモード (Multiplexed Access Mode)

IrLMP の本来のモードである。IrLMP の複数のサービス・ユーザから送られてくるデータを公平にIrLAP に割り振る。したがって、特定のアプリケーションがIrLAP 層を独占することはない。

▶7.6 IrMUXの内部構造

ここでIrMUX の内部構造について説明する。IrLMP の規格書において、LM_のプリフィックスをもつサービスの記述はIrMUX 層が上位層に提供するサービス・プリミティブを表す。また、LS_のプリフィックスを持つサービスの記述は、IrMUX内部で必要となる局制御（Station Control ）メカニズムについての内部的なサービス・プリミティブである。IrLAP_のプリフィックスを持つサービス記述は、IrMUX 層の下位層にあるIrLAP が提供するサービス・プリミティブであることはいうまでもない。

IrMUX 層を外部から見ると、上位層に提供するLM_のプリフィックスを持つサービス・プリミティブと、IrMUX 層がサービス・ユーザとなってIrLAP 層の提供するIrLAP_のプリミティブを利用するように見える。LS_のプリフィックスを持つ内部・サービス・プリミティブはまったく外から見えない。このことの意味は、実際の実装においてLS_プリミティブを明確に実装する必要はなく、IrLMP 規格書においての内部記述をわかりやすく説明するためのものであることに注意する必要がある。プロトコルサービスエンティティの実装は、外部に提供されるサービスが一致していればどのような実装を用いてもかまわないということになる。

この図は、様々なサービス・プリミティブ（イベント）がLM-MUX によりどのように受信され、生成されるか、そしてLM-MUX エンティティ内でどのようにルーティング（経路選択）されるかについて、示したものである。LM-MUX サービス境界における外部インタフェース間のイベントのトップ・レベルのルーティング、各LSAP-接続エンド・ポイントに関連づけられるLSAP-接続制御FSM（LSAP Connection Control FSM: Finite State Machine[有限状態マシン]）、局ごとにある受信デマルチプレクサと局制御(Station Control)エンティティの関係を示している。ここで、各内部機構のもつ内部エンティティについて整理しておこう。

LSAP-Connection Endpoint LSAP-Conn Control FSM IrLAP Service Boundary IrLAP-Connection Endpoint Rx Demultiplexer Station Control LM-MUX Service Boundary XID_Discovery Service Access Point Connectionless LSAP A B C D E F G B to C Events

LM_Connect.indication
LM_Connect.confirm
LM_Disconnect.indication
LM_Idle.confirm
LM_Data.indication
LM_UData.indication
LM_Status.indication
LM_Status.confirm

B to E Events LS_Connect.request LS_Disconnect.request LS_LockOut.confirm LS_Status.request LS_Idle.request C to B Events

LM_Connect.request
LM_Connect.response
LM_Disconnect.request
LM_Idle.request
LM_Data.request
LM_UData.request
LM_Status.request

A to D Events

IrLAP_Data.indication
IrLAP_UnitData.indication

B to A Events

IrLAP_Data.request

D to B Events

IrLAP_Data.indication

E to A Events

IrLAP_Connect.request
IrLAP_Connect.response
IrLAP_Disconnect.request
IrLAP_Data.request
IrLAP_UnitData.request
IrLAP_Status.request
IrLAP_Sniff.request
IrLAP_Discover.request
IrLAP_Primary.request
IrLAP_Primary.response
IrLAP_NewAddress.request

E to B Events LS_Connect.confirm LS_Disconnect.indication LS_LockOut.request LS_Status.indication LS_Status.confirm A to E Events

IrLAP_Connect.indication
IrLAP_Connect.confirm
IrLAP_Disconnect.indication
IrLAP_Status.confirm
IrLAP_Status.indication
IrLAP_Reset.indication
IrLAP_Reset.confirm
IrLAP_Discover.indication
IrLAP_Discover.confirm
IrLAP_Primary.indication
IrLAP_Primary.confirm
IrLAP_NewAddress.confirm

D to F Events

LM_ConnectionlessData
.indication

E to G Events

LM_Sniff.confirm
LM_DiscoverDevices.indication
LM_DiscoverDevices.confirm

F to E Events

LM_ConnectionlessData
.request

G to E Events

LM_DiscoverDevices.request
LM_Sniff.request

C to E Events

LM_AccessMode.request

D to E Events

IrLAP_Data.indication

(AccessMode LM-PDU)E to C Events

LM_AccessMode.indication
LM_AccessMode.confirm

E to F Events

LM_ConnectionlessData

.confirm

▶7.6.1 局制御(Station Control)エンティティとLSサービス・プリミティブ

局制御エンティティは、IrMUX 層全体の切断、接続、発見、アクセスモードなどを受け持つ。局制御エンティティは次のようなサービスを受け持つ。1）発見手順、アドレス衝突の排他的アクセスの提供2）コネクションレス型（CL 型）データの転送3）IrLAP 層への接続／切断4）排他アクセスモード、多重化アクセスモード間の遷移局制御が提供するサービス・プリミティブは次のようになる。上位層提供サービス・プリミティブ

LM_DiscoverDevice

.要求/指示/確認発見プリミティブ

LM_Sniff.要求/確認

スニフプリミティブ

LM_AccessMode.要求

アクセスモードプリミティブ

LM_ConnectionlessData.

要求/確認コネクションレス型データ転送プリミティブ内部提供サービス・プリミティブLS_Connect.要求/確認内部接続プリミティブLS_Disconnect.要求/指示内部切断プリミティブLS_LockOut.要求/確認内部排他制御プリミティブLS_Idle.要求内部アイドルプリミティブLS_Status.要求/指示/確認内部状態プリミティブ

▶7.6.2 LSAP接続制御FSM(LSAP-Connection Control FSM)

LSAP-接続制御FSM は、各LSAP-接続エンドポイントに関連付けられ、一つ一つのLSAP 接続ごとに有限状態マシンが生成されて接続と切断を管理する。LSAP-接続制御FSM が提供するサービス・プリミティブは次のようになる

LM_Connect.要求/指示/res/確認

接続プリミティブ

LM_Disconnect.要求/指示

切断プリミティブ

LM_Idle.要求/確認

アイドルプリミティブ

LM_Data.要求/指示

コネクション型データ転送プリミティブ

LM_Udata.要求/指示

コネクション型単位データ転送プリミティブ

LM_Status.要求/指示/確認

ステータスプリミティブLSAP 接続制御FSM の接続／データ転送/切断の動きは次のようになる。アクティブなLSAP-接続が確立されている間は、FSM は、LS_Connect.要求内部サービス・プリミティブを発行することにより、局制御エンティティからの適切なIrLAP-接続の使用を要求する。適切なIrLAP-接続が使用できるときは、局制御エンティティは、LS_Connect.確認で応答し、LSAP-接続のためにどのIrLAP-接続エンドポイントを使用すべきかを指示する。

局制御が適切なIrLAP-接続を提供できない場合、LS_Disconnect.指示プリミティブで応答する。IrLAP 接続が確立すると、起動（イニシエータ）側のLSAP-接続制御FSM は、接続LM-PDU を相手側の同FSMに送信する。このときの接続LM-PDUには、LM_Connect.要求で提供されたユーザ・データが伝達される。応答（レスポンダ）側の同FSM に接続LM-PDU が到着すると、そのFSM はLM_Connect.指示プリミティブを生成し、上位層に通知する。LM_MUX 上にあるサービスユーザ（LM-MUX クライアント）がこの接続指示を拒絶する場合は、LM_Disconnect.要求を使用する。その結果、切断LM-PDUが生成され、起動（イニシエータ）側のLM-MUXクライアントにはLM_Disconnect.指示が通知されることになる。

一方、LM-MUX クライアントが接続を受け入れる場合は、応答（レスポンダ）側のエンドポイントにあるLM-MUX クライアントは、LM_Connect.res を発行する。その結果、応答（レスポンダ）側のFSM は接続LM-PDU が生成し起動（イニシエータ）側のFSM に送信する。そして、起動（イニシエータ）側のFSM に接続LM-PDU が届くと、FSM は、LM-MUX クライアントにLM_Connect.確認プリミティブを発行しする。これによって、IrMUX のエンドポイントに接続が確立する。

エンドポイントにあるLM-MUXクライアント間でのデータ交換は、この接続が確立しないと行うことが出来ない。エンドポイントにあるLM_MUX クライアント同士は、LM_Data,LM_Udata サービス・プリミティブを使用してデータの交換を行う。最後にいずれかのLM_MUXクライアントがLM_Disconnect.要求を発行することで、FSMは、切断LM-PDU を生成し、相手のFSM に通知した後、をその局の局制御エンティティにLS_Disconnect.要求が発行する。

▶7.6.3 受信デマルチプレクサ

受信デマルチプレクサは、IrLAPのデータサービス、単位データサービスからの指示（指示）をすべて受け持っていて、ルーティングをおこなう。後述するLM-PDU にある行き先LSAP-SEL（DLSAP-SEL）を解釈してLM-MUX クライアントごとに生成されたLSAP 接続制御FSM にIrLAP からのデータ、単位データを分配、配信する。同様に、アクセスモードに関するPDU は局制御エンティティに通知する。

▶7.7 LSAPとLSAP-ID

特定の装置上にある特定のアプリケーションを識別するために、LSAP-ID と、特定のアプリケーションの所有するLSAP-SEL という2 つの概念を導入する。LSAP ID LSAP ID は特別な装置での特別なLSAP を示し、＜装置・アドレス＞と＜LSAP SEL＞の連結として定義する。装置・アドレスによって特定の装置を指定し、LSAP SEL によって装置に存在するアプリケーション（IrLMP の上位層）を指定する。

LSAP SEL LSAP Selector（LSAP 選択子） の略。装置内の特定のLSAP 示すセレクタ。LSAP SEL の論理値は0x00～0x7F の範囲にある。IrLMP ではLSAP－SEL のいくつかは特定の目的のために使用する

0x00

(LM-IAS)IAS（IrLMP の造りつけのデータベース）

0x70

(コネクションレス型用)

0x71～0x7E

(IrLMP おける将来の拡張のために予約されている)

0x7F

(ブロードキャスト「同報」として使用する)装置・アドレスを自分自身のアドレスとした場合は、自分の装置内でのアプリケーション同士の通信経路を確保することも出来るという点に注意しておこう。また、ひとつのアプリケーションが複数のLSAP-SEL を持つことも可能である。

▶7.8 サービス・ヒント

IrLAP 層の発見手順において得られるログは、装置・アドレスと上位層に通知する発見情報(Discovery Information)で構成され、上位層が利用できる発見情報に関しては未定義であった。IrLMP 層では、この発見情報を使用して、アプリケーションにとって利用価値のあるくつかの情報を提供する。サービスヒントは、発見情報の先頭にビットマップをを用意して装置の種類や上位層にどのようなアプリケーション層が存在するかを通知する。IrLMP を使用するアプリケーションは、IrLMP の発見手順を使用することで、装置・アドレスと、装置の種類、実装されているIrDA アプリケーション層を知ることが出来る。

上記のフォーマットは、IrLMP で定義されているサービス・ヒントである。上位の7 ビット目は後続のデータもサービス・ヒントであることを示している。つまり、サービス・ヒントは必要に応じて拡張される。

サービ・スヒントは、IrDAが厳格に管理しており、IrDAにおいて、新たなアプリケーションが定義されるごとにサービスヒントビットが割り当てられる。複数の機能を持つ装置の場合は、同時にいくつものサービス・ヒント・ビットがたつこともある。IrLMP に発見サービスがあるのは、IrLAP のサービスに加えてこのような機能を有しているためであるということに注意しよう。

▶7.9 装置ニックネーム

サービスヒントに続く発見情報の内容は、簡単な装置の名称などを示す装置・ニックネームのエリアとして用意されている。記述する内容については規定はないが、情報として数十バイト程度であるので通常装置が簡単に見分けられるような短縮名（ニックネーム）を使用する。単に装置の型番であったり装置のシリーズ名だったりする。IAS にも同様のエントリがあり、さらに長い装置名を登録することができる。このために装置・ニックネームのことを装置・ショートネーム、IAS に登録する装置名を装置・ロングネームと呼ぶこともある。

▶7.10 IrMUXのサービス・プリミティブ

IrLMP サービス・プリミティブには3 つのグループに分かれている。発見サービス、リンク制御サービス、およびデータ転送サービスである。では、これらのプリミティブについて概説することにしよう。

▶7.10.1 リンク管理発見サービス

リンク管理発見手順は、IrLAP が提供するメカニズムを使用し、赤外線物理層の到達範囲において、どのようなIrDA 装置が存在しが相互に情報伝達可能かを、アプリケーションからわかるようにする。IrDA リンク管理プロトコルは、交信を管理する各装置の基本情報を提供する。IrLMP では、発見情報においてサービス・ヒントを提供する。アプリケーション作成者は、この発見プロセスが本質的に不完全であることに注意しなければならない。つまり、発見プロセスで検索できた装置が接続プロセスにおいても存在する保証はないことを意味する。動的赤外線環境では、ある装置が、そのアドレスに向けた要求に応答できないこともあるし、アドレス衝突のために装置アドレスの変更が必要になることがある。

▶7.10.1.1 発見サービス・プリミティブ

▶7.10.1.1.1 LM_DiscoverDevices

LM_DiscoverDevices サービスは、いずれの局も接続されておらず、リンクがコンテンション状態

（NDM）のときは、発見プロセスを起動する。また、リンク確立中(NRM)の場合、この装置が関係する最後の発見オペレーションの結果が返される。この装置の関係する最後の発見プロセスにおいて、発見プロセスをイニシエータとして起動したのでなければ、現在リンクしている装置の情報が含まれるだけのことがある。アドレス衝突が検出されれば、IrLMP は、一回の衝突アドレス解決プロセスを起動して、衝突アドレスを解決しようとする。それでも衝突が回避できない場合は衝突しているアドレスのすべてのエントリは削除されて上位層に通知する。

LM_DiscoverDevices.要求(nrSlots)
LM_DiscoverDevices.確認(Status, List of(装置アドレス, 装置情報, method ))
LM_DiscoverDevices.指示(装置アドレス, 装置情報, method)

パラメタ:NrSlots IrLAP 発見手順におけるスロット数Status発見手順によるか、過去のデータによるものかを表す。装置アドレス32 ビットのIrLAP 装置アドレスを表す。装置情報サービスヒントを含む装置情報method発見方法を示すスニフィング、能動発見、受動発見このサービス・プリミティブは、必須である。

▶7.10.1.1.2 LM_Sniff

LM_Sniff サービスは、IrLAP から提供されるスニフィング・サービスモードの移行制御行う。この

モードが設定された後は、解除されるまでほかのIrLMP のサービスは使用できない。この要求は、

LM_ConnectionlessData.要求、LM_Connect.要求、またはLM_DiscoverDevices.要求の呼び

出しにより、暗黙のうちに解除される。LM_Sniff.確認では、スニフ要求が暗黙のうちに解除されたときに、'cancelled'という値のstatus か生成される。

LM_Sniff.要求(option)
LM_Sniff.確認(status, 装置アドレス)

パラメタ:Optionスニフモード設定／解除Status接続が確立されたか、スニフが以下の理由で拒絶されたa) IrLAP connection がすでに存在する。b) スニフがすでにアクティブである。装置アドレス接続される装置のIrLAP 装置アドレス

▶7.10.2 リンク管理リンク制御

▶7.10.2.1 リンク制御サービス・プリミティブリンク／制御サービス・プリミティブ

▶7.10.2.1.1 LM_Connect

リモート装置上でトランスポート層エンティティ（IrLMP の上位層）のためのLSAP が識別されると、データ送信のために、ローカル・トランスポート・エンティティとリモート・エンティティに対応するLSAPを接続する必要がある。LSAP 同士は、対として接続しなくてはならない。任意の対のLSAP 同士の間では、1 つだけのLSAP-接続しかできない。

LM_Connect.要求(Called LSAP, requested Qos, Client Data)
LM_Connect.指示(Calling LSAP, Resultant Qos, Client Data)
LM_Connect.応答(Calling LSAP, confirmation, Client Data)
LM_Connect.確認(Called LSAP, Resultant Qos, Client Data)

パラメタ:LSAP 1 つのLSAP を識別するID QoSサービス品質パラメータ。変更できるパラメータは、どのパラメータが実際に変更できるかは、インプリメンテーションに依存する。Client Dataサービス・ユーザが接続パケットに入れて送信する最大60 バイトのデータ。標準では署名フィールドとして使用され、接続を受け入れるかどうかを決めるための補助をする。また、トランスポート層の初期化データや、単に少量のデータを転送するために使用する場合もある。

confirmation接続を受け入れるか拒絶するかを示す。QoSサービス品質パラメータ（IrLAP 規格参照）：ボーレート最大・アラウンド・ターンタイム［入力のみ］データサイズ切断スレッショルドLSAP サービス・ユーザは、IrLAP リンクのためのサービス品質（QoS: Quality of Service）を要求することができる。ほかのLSAP 接続がない場合か、IrLAP リンクがまだ存在していない場合、IrLMP 層は、要求されたQoS を提供しようとする。QoS を満たすことができない場合でも接続は行われる。接続に成功すれば、実際のQoSパラメータが返される。実際のQoSが十分でない場合、切断するのはLSAP サービス・ユーザの責任である。このサービス・プリミティブは、必須である。

▶7.10.2.1.2 LM_Disconnect

LSAP 接続を切断するように要求する。LSAP サービス・ユーザは、これを拒否することはできない。

LM_Disconnect.要求(Reason, Client Data)
LM_Disconnect.指示(Reason, Client Data)

パラメタ:Reason接続をクローズする（した）理由Client Data最大60 バイトのサービス・ユーザ・データクライアント・データが引き渡されるという保証はない。Reason切断理由コードの符号化については、別途説明する。このサービス・プリミティブは、必須である。

▶7.10.2.1.3 LM_Status

要求／確認は、IrLAP 待ち行列にまだ肯定応答されていないデータ（IrLMP はデータを受理しているが相手の確認応答がなく保留されているデータ）があるかどうかについての情報を提供する。IrLAP は、おだやかにクローズをしないので、切断してもよいタイミングを調べるために、この情報は有用である。様々な一般ステータス表示が、発生するにつれて引き渡されるが、これらをどのようにしてサービス・ユーザが入手できるかは、インプリメンテーションに依存する。LSAP-connection endpoint は、ほかのLSAP-connection のために排他モードへの遷移が発生したとき、すなわちLockStatus=Locked となり、その後はすべてのデータ転送要求は拒絶されるときに、通知を受ける。

同様に、データ転送が再開できるとき、すなわちLockStatus=Unlocked のときも、このエンドポイントが通知を受ける。LinkStatus パラメータは、IrLAP から生じたステータス表示を伝達する。

LM_Status.要求()
LM_Status.指示(LinkStatus, LockStatus)
LM_Status.確認(UnAcked Data Flag)

パラメタ:LinkStatus Ok、No progress（進行なし）、noisy（ノイズあり）LockStatus NoChange（変化なし）、Locked（ロックされている）、UnLocked（ロックされていない）UnAcked Data Flag True/False（真／偽）肯定応答されていないデータがIrLAP 待ち行列にあるかどうかを示す。このサービス・プリミティブは、必須である。

▶7.10.2.1.4 LM_Idle LM_Idle サービス・プリミティブは、LSAP connection endpoint で呼び出される。このプリミティ

ブは、LSAP connection に、アイドル／アクティブのマークを付けるために使用される。接続が始めに確立されると、アクティブ状態にあるとみなされる。サービス・ユーザが、リンクをアクティブに使用せずに長時間、接続をオープンにしていたい場合、リンク管理にそのことを通知することができる。こうすれば、ほかのLSAP サービス・ユーザが、station を排他モードにすることができる。ほかのサービス・ユーザは、排他モードにしたサービス・ユーザがstation を多重化モードに戻すまで、アクティブになることはできない。アイドル・モードのLSAP エンドポイントからトラフィックを送信することはできない。そのLSAPが接続を使用するためには、アイドル・モードから抜け出すように要求し、要求を認めさせなければならない。

LM_Idle.要求(要求 mode)
LM_Idle.確認(status, Actual mode)

パラメタ:mode Active/Idle（アクティブ／アイドル）status Success/Failure（成功／失敗）このサービス・プリミティブは、オプションである。

▶7.10.2.1.5 LM_AccessMode

排他モードと多重化モードとを切り換える。

LM_AccessMode.要求(要求ed Mode)
LM_AccessMode.指示(Resultant Mode)
LM_AccessMode.確認ation(status, Actual Mode)

パラメタ:Mode要求されたモード／現在のモード（Exclusive/Multiplexed（排他／多重化））Status要求の成功／失敗このサービス・プリミティブは、オプションである。

▶7.10.3 リンク管理データ転送

▶7.10.3.1 データ転送サービス・プリミティブ

▶7.10.3.1.1 LM_Data

リモートLSAPにIフレームを送信する。このIフレームは、リンク・レベル接続の失敗がなければ、信頼性のある送信が行われる。但し、データの送信側は、データが届いたかどうかの通知を受けない。ベースになっているIrLAPリンク・レベル接続が切れた場合、データが消失することがあるが、消失データについての情報は、送信側で入手できない。ただし、両方のLSAP クライアントは、各々が

LM_Disconnect.指示を受信したときに、消失した可能性があるかどうかを知ることができる。ユー

ザ・データのサイズは、1 つのIrLAP I フレーム内に収まるように制限を受ける。

LM_Data.要求(Data)
LM_Data.指示(Data)

パラメタ:Dataユーザ・データこのサービス・プリミティブは、必須である。

▶7.10.3.1.2 LM_Udata

リモートにUI フレームを送信する。UI フレームは、同じ宛先LSAPに対するいかなる未処理のIフレームよりも先に送信され、引き渡される。UI フレームの送信は、信頼性のあるものではない。ユーザ・データのサイズは、1 つのIrLAP UI フレーム内に収まるように制限を受ける。

LM_UData.要求(Data)
LM_UData.指示(Data)

パラメタ:Dataユーザ・データこのサービス・プリミティブは、必須である。

▶7.10.3.1.3 LM_ConnectionlessData

コネクション外でUI フレームを送信する。これらの送信は、信頼性のあるものではない。このようなUI フレームの引き渡しのために、引き渡しポイントが1 つある。このドキュメントでは、そのフレームに対応する装置内の正しい宛先ソフトウェア・エンティティを調べるメカニズムを明記しない。このようなフレームは、通信範囲内のすべての装置に対して同報通信され、一次／二次役割については考慮しない。ユーザ・データのサイズは、1 つのIrLAP UI フレーム内に収まるように制限を受ける。

LM_ConnectionlessData.要求(Data)
LM_ConnectionlessData.指示(Data)
LM_ConnectionlessData.確認(status, [要求son])

パラメタ:Dataユーザ・データStatus要求の成功／失敗（success/fail）Reason失敗理由（オプション）.確認プリミティブは、対応する.要求がIrLAP に渡され、成功したか、LM-MUX によって放棄された（失敗）かを示すために使用される。今のところ、LM-MUX が要求を放棄する唯一の理由は、LM-MUX が排他モードにあることである。.確認は、データ送信の責任がIrLAP に引き渡されたことを示すだけであることに注意する。UIフレームの送信が成功したことを示すものではない。

このサービス・プリミティブは、オプションである。

▶7.10.4 情報の媒体 IrLMPにおけるPDUの構成

上記のフレームは、IrLAP の基本構成である。IrLMP では、IrLAP の情報部（情報フィールド（I））によってで提供されるSDU について言及する。

▶7.10.4.1 装置情報フィールド・フォーマット

発見手順／アドレス衝突解決XID レスポンスで使用する情報（I）フィールドの内容

▶7.10.4.2 発見手順／アドレス衝突解決XIDコマンドで使用する情報（I）フィールドの内容

上記のフォーマットは、IrLAP の発見手順／アドレス衝突解決で使用されるXID コマンド/レスポンスのフレームを示している。このフィールドでDiscovery Info部はIrLAPの上位層によって使用されると述べた。IrLMP ではこのフィールドを装置情報として定義し使用する。装置情報フィールドには、サービス・ヒント・マスク（ビット）と装置ニックネームが入っている。サービス・ヒントは、異なるサービスをサポートする装置が同じ赤外線物理空間にあるとき（たとえば、ラップトップ、プリンタ、モデム）、その中で接続を試みたい装置の機能や種類を知るために使用する。装置ニックネームは、同じタイプの装置が複数、同じ赤外線物理空間にあるとき（たとえばいくつかのPDA など）、特定の装置を指定するために使用する。装置情報フィールドのフォーマットを以下に示す。

Service Hints Device Nickname n octets 0 to 23 - n octetsアドレス部A制御部C情報部I FI X’01’Source Device Address Destination Device Address Discovery Info(final slot only)1 byte 4 bytes 4 bytes Discovery Flags 1 byte Slot Number Version Number 1 byte 1 byte 32 bytes FI X’01’Source Device Address Destination Device Address Discovery Info 1 byte 4 bytes 4 bytes Discovery Flags 1 byte Slot Number Version Number 1 byte 1 byte 32 bytes最大2 オクテット(8 ビット単位)のサービス・ヒントは、以下のように定義されている。

Byte 1 Byte 2 Bit Function Bit Function 0 PnP Compatible 8 Telephony 1 PDA/Palmtop 9 File Server 2 Computer 10 rsvd 3 Printer 11 rsvd 4 Modem 12 rsvd 5 Fax 13 rsvd 6 LAN Access 14 rsvd 7 Extension 15 Extension

▶7.10.4.3 サービス・ヒント

装置情報フィールドの最初の2 オクテットには、IrLMP ヒント・マスクが入っている。未定義のすべてのヒントは、ゼロにセットされる(10 ビットから、14 ビットまでは、IrCOMM,IrLAN、OBEX などで使用される)。各ヒント・バイトの第8 ビット（ビット7、15、23...）は、拡張ビットで、装置情報フィールドにさらに追加のヒント・バイトがあるかどうかを示している。拡張ビットがクリアされていればそこでサービスヒントが終わることを意味する。

ヒントのビット0は、[IRPNP規格]で説明されるプラグ・アンド・プレイObject Class"PnP"のインスタンスの有無を示す。このインスタンスがセットされると、PnP object class は、存在するものとみなされる。これについては、後述する。サービス・ヒントは、IrLMPよって管理されるが、リンク管理は情報の正確さを保証しない。あくまでもここで定義しているビットは装置の「大筋の類型」を表す程度である。ただし、PnP Compatibleビットや、10 ビットから14 ビットで定義されるIrDA 規格で定義する上位層の実装を規定しているサービスヒントは上位層の存在を明示的に示している。

▶7.10.4.4 装置ニックネーム

装置情報フィールドにある装置ニックネームは、IAS で説明する、"Device"オブジェクトのDeviceName attribute の値として返される名前を縮めたと形式とすることができる。キャラクタ・セットの符号化は、次のルールに従う。

0xFF = 255

UNICODE IrLMP 文字コード表IrLAP の仕様書では最大32 バイトまでを許容しているが、装置情報フィールドの合計バイト数が、23 バイトを超えてはならない。これは、IrLAP がNDM 状態の場合のフレーム長の制限による。したがって、追加のヒント・バイトが伝送される場合、装置ニックネームは、対応するバイト数だけ短くしなければならない。たとえば、2 バイトではなく3 ヒント・バイトを伝送する場合は、装置ニックネームは、最大長19 バイトと制限される。

▶7.10.5 LM-PDUフォーマット

すべてのLM-PDU フレームは、IrLAP データ・フレームとして送信される。IrLAP の立場で考えれば、単なるデータ転送にすぎないことに注意しよう。

▶7.10.5.1 LM-PDU ヘッダ

IrLMP は、符号化されたIrLAP データ・フレーム内で以下のように2 オクテット（２バイト）のPCI（プロトコル制御情報）を使用する。7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 C DLSAP-SEL r SLSAP-SELフィールドの定義：C ビット制御ビット。制御ビットが1 にセットされると、そのフレームがIrLMPにおけるコマンド・フレームであることを示す。制御ビットが0にセットされると、LM_PDU はデータとして扱われる。

DLSAP-SEL宛先LSAP。このPDU を受け取る先のサービス・アクセス・ポイントのセレクタを示している。r ビット将来の使用のために予約されており、0 にセットしなければならない。SLSAP-SEL発信元LSAP。このPDU を発行したサービス・アクセス・ポイントのセレクタを示している。

▶7.10.5.2 IrLMPデータ転送PDUフォーマット

データ転送フレームは、以下のように符号化されている。7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 0 DLSAP-SEL 0 SLSAP-SEL Data ….DLSAP-SEL は、宛先のLSAP、SLSAP-SEL は発信もとのLSAP である。C ビットが0 であるのでDATA 部は上位サービス・ユーザで直接使用される。

▶7.10.5.3 IrLMPリンク制御PDUフォーマット

リンク制御フレームは、IrLMP 層での論理的な接続、切断等の情報をエンドポイントにあるIrLMP同士交換するのに使用する。7 6-0 7 6-0 7 6-0 1 DLSAP-SEL 0 SLSAP-SEL A opcode parameters A ビット0 にセットされたとき、IrLMP における発信側でのコマンド要求（要求）を意味し、宛先側ではコマンド指示(指示)として解釈されなければならない。A ビットが1 にセットされたとき、発信側ではコマンド応答(応答)で、宛先側ではコマンド確認(確認)である。

すべてのフレームは、IrLAP によって信頼性のあるデータとして送信される。

▶7.10.5.3.1 IrLMPリンク制御のオペコード（命令コード）

A opcode Frame Command parameters 0 1 I Connect Rsvd = 0x00 (Optional) or rsvd = 0x00, LMS-UserData(Optional)1 1 I Connect (確認)rsvd = 0x00 (Optional) or rsvd = 0x00, LMS-UserData(Optional)0 2 I Disconnect reason,LMS-UserData(Unspecified)0 3 I AccessMode rsvd=0x00, mode 1 3 I AccessMode (確認)status, modeリンク制御のオペコードIrLMP は、各LSAP のコネクションごとに状態遷移表を使用してLSAP ごとの接続状態を管理する。そして、このリンク制御PDU のオペコードを利用して接続切断およびアクセスモードの制御を行う。

Connect.要求/指示:A ビットを0 とし、オペコードを0 とする。パラメータの先頭は予約されていて0にセットする、続くデータは上位層により使用される。このコマンドは、IrLMP の接続要求に使用されるConnect.rsp/確認A ビットを1 とし、オペコードを0 とする。パラメータは、同様である。このレスポンスは、IrLMP の接続応答に使用される。Disconnect.要求/指示A ビットを0 とし、オペコードを2 とする。パラメータの先頭1バイト目は切断の理由を示すコードである。続くデータは上位層により使用される。このコマンドはIrLMPの切断要求に使用される。

AccessMode.要求A ビットを0 とし、オペコードを3 とする。パラメータの先頭は予約され0 にセットする。つづく1 バイトは、IrLMP の接続モードを表す。接続モードは多重化モードか、排他的モードのどちらかである。AccessMode.確認A ビットを1 とし、オペコード3 とする。パラメータは、要求が成功したか失敗したかを表すStatus と、現在のモードを示すMode は2 バイトから構成される。

切断理由コード(Reason コード)Reason Code User 要求

0x01

0xff

切断理由コード切断理由コードは、なぜIrLMP の接続が終了したかについての助言を与える。アクセスモード設定パラメータMode Value Multiplexed

0x00

Exclusive

0x01

Table 1. IrLMP Mode Valuesアクセスモード要求結果通知コードStatus Value success

0x00

failure

0x01

Unsupported

0xff

/* Access Mode 確認 Only */Table 2. IrLMP Control LM-PDU Status Values.

▶7.10.6 IrMUX接続手順の例

この図は、下位層を無視して、IrLMP層の各エンドポイントから見た接続動作を上から下に時系列で表現した例である。ここでは、IrLMP の多重化層（LM-MUX）サービス層を切り口にしている。イニシエータ側のエンドポイントで、接続要求であるLM-CONNECT.要求を発行すると、レスポンダ側のエンドポイントで接続通知としてLM-CONNECT-指示が通知される。レスポンダはその通知に応答するためにLM-CONNECT.応答を発行する。すると、イニシエータ側のエンドポイントに接続応答であるLM-CONNECT.確認が通知される。

LM-Connect.confirm LM-Connect.request Initiating LM-MUX Service Boundary LM-Connect.response LM-Connect.indication Responding LM-MUX Service Boundary Initiating LSAP-Connection Endpoint Initiating Station Control Initiating IrLAP Connection Endpoint Responding IrLAP Connection Endpoint Responding Station Control Responding LSAP-Connection Endpoint LM-connect.request LS-Connect.request SIR-Connect.request SIR-Connect.indication SIR-Connect.response SIR-Connect.confirm LS-Connect.confirm SIR-Data.request(CR LMPDU)SIR-Data.indication(CR LM-PDU)LS-Connect.request LS-Connect.confirm LM-Connect.indication LM-Connect.response SIR-Data.request(CC LM-PDU)SIR-Data.indication(CC LM-PDU)LM-Connect.confirmこの図は、LM-MUX 層およびその下位層も含めたプロトコル動作を示している。

起動（イニシエータ）側LM-MUX クライアントが、LM-Connect.要求を発行すると、LSAP エンドポイントにあるLSAP 接続管理FSMは、局制御エンティティに対して、LS_Connect.要求を発行する。IrLAP エンティティに接続が確立していない場合は、IrLAP_Connect.要求（この図では、SIR-Connect.要求）を発行する。応答（レスポンダ）側のIrLAP 層は、IrLAP_Connect 要求を受け取ると、LM-MUX 内部の局制御エンティティにIrLAP_Connect 指示を使って接続要求を通知する。この通知は、上位層には通知されずにLM-MUX 内部で処理され、即座に接続許可通知であるIrLAP_Connect.応答を発行する。

起動（イニシエータ）側の局制御エンティティは、IrLAP_Connect.確認を受け取ることで、LAP接続が有効になったことを確認するとともに、LSAP 接続管理FSM に対して、LS_Connect.要求に対する応答 LS_Connect.応答を通知する。起動（イニシエータ）側のLSAP 接続管理FSM は、接続要求LM-PDU を生成し、IrLAP に対して、IrLAP_Data.要求を発行する。下位層にあるIrLAP は、そのデータを信頼性のあるデータとして相手側のIrLAP 層に送信する。

応答（レスポンダ）側のIrLAP層にIrLAP_Dataが到来すると、LM-MUX内部にある受信デマルチプレクサにIrLAP_Data.指示プリミティブを発行し、受信デマルチプレクサは、DLSAP-SELを確認し該当するLSAP 接続管理FSM に通知する。LSAP 接続管理FSM は、新たな接続が確立したことを内部の局制御エンティティにLS_Connect 要求で通知する。局制御エンティティは、すでにIrLAP 接続が確立しているのでIrLAP 接続要求を発行せずに、内部変数を更新した後LS_Connect.確認を該当するLSAP 接続管理FSM に通知する。

応答（レスポンダ）側LSAP 接続管理FSM は、接続要求LM-PDU をもとに、LM_Connect.指示プリミティブをLM－MUX クライアントに通知する。応答（レスポンダ）側のLM-MUXクライアントは、接続要求指示に答えて、LM_Connect.応答プリミティブを発行する。続いて、LSAP 接続管理FSM は、接続応答LM-PDU を作成して下位層にあるIrLAP 層にデータ要求を発行する。

起動（イニシエータ）側のIrLAP 層を経て、受信デ－マルチプレクサはIrLAP_Data 指示プリミティブを受け取る。受信デ－マルチプレクサはDLSAP-SEL を確認し該当するLSAP 接続管理FSM に通知する。LSAP 接続管理FSM は、上位のLM-MUX クライアントにLM_Connect.確認プリミティブとして通知する。

▶7.10.7 IrMUXのまとめ

さて、IrMUX についての議論を終わりにするにあたって、いくつかの要点を整理し復習しておこう。

▶7.10.7.1 より「アプリケーション指向」になった発見手順

発見手順で使用されるIrLAP 層の発見情報（DeviceInfo）フィールドにサービスヒントを導入することで、接続する前の発見手順において、装置の持つ属性や、赤外線機能（上位のIrDA 規格）などが装置同士で交換できるような構造を与える。

▶7.10.7.2 IrLMPにおける経路の多重化の概念

IrMUX は、LSAP-SEL という論理的なアクセスポイントを上位層に提供することによって、デバイスに存在する複数のアプリケーション（LM-MUX クライアント）がお互いに干渉せずに論理的な経路を確保することが出来るようになる。そのためには、各LSAP ごとに、LSAP-接続制御FSM を設けてLSAP 単位の接続／切断管理を行い、デバイス（局）単位では、IrLAP レベルの接続／切断管理を行う局制御エンティティの内部サービス・プリミティブによって柔軟な接続管理を行い、また受信デマルチプレクサによって、受信したIrLAP のデータや単位データを各LSAP、局制御エンティティに報告することで多重化を実現しなければならない。

▶7.10.7.3 LM-PDU

IrMUXで使用するPDU（プロトコルデータ単位）内のPCI（プロトコル制御情報）は＜DLSAP-SEL>と＜SLSAP-SEL>の２バイトが基本になっている。切断／接続などの制御情報を伝達するばあいは、Aフラグと後続のパラメータを使用する。純粋な上位層のデータ転送においては、＜DLSAP-SEL>と＜SLSAP-SEL>のたった２バイトの負荷（オーバーヘッド）だけで、経路の多重化が行えるようになっている。

さて、IrLAP とIrMUX の動作で大きく違う点について最後に述べておこう。IrLAP ではNDMからNRMに遷移して接続が確立すると、いずれかの装置が一次局になり、一方が、二次局になりそれぞれの局の動作は非常に異なっているが、IrMUXの上位層からみると、自分の装置がIrLAP層で一次局として接続しているか二次局として接続しているかどうかは原則として「隠蔽」されているということに注目しよう。IrMUX の概念としては、起動側（イニシエータ）と応答側（レスポンダ）しかなく、装置がIrLAP 接続として二次局であってもLM-MUX クライアント自体はイニシエータとして動作することができるし、プロトコルの動作の構造自体もエンドポイントの下にあるIrMUX 同士で同じふるまいをするということを覚えておこう。

▶7.11 IAS情報アクセスサービス

IrLMP におけるIrMUX が多重化の実体だとすれば、多重化アクセスを柔軟に行うための手段がIAS であるといってもよいだろう。この２つのエンティティがIrLMP によって提供されることで、IrDA プロトコルは柔軟な環境と幅広い応用が可能になる。

▶7.11.1 LM-MUXクライアントとしてのIAS「クライアント／サーバー」

情報アクセスサービス（IAS）は、IrDA 装置によって提供されるサービスについての情報を保持したり、別のIrDA装置のデータ・ベースをリモートアクセスする操作を提供する。IrLMPの情報アクセスサービスは、ひとつのLM-MUXクライアントとして提供され、基本的には、相手局のリモートデータベースをアクセスする、データ・ベース・アクセス・クライアントと相手局からリモートアクセスされるデータベースをつかさどるデータ・ベース・サーバから成り立つ「クライアント／サーバ」モデルに基づいている。

IrMUX エンティティから見れば単なるLM-MUX クライアントに過ぎない。したがってIAS に接続したり切断したりする手順は完全にIrMUX にしたがっている。この図は、LM-MUX上にあるIASのモデルを示している。上位層からは、クライアント情報アクセスプロトコル（Client IAP）FSMが提供するIASサービス・プリミティブを使用する。クライアントFSM Client IAP FSM LM-MUX Service Interface Information Base Information Access Service Interface Local Registration Information Access Protocol Server IAP FSMは、IrMUX のサービスを使用し、相手のサーバーFSM と接続を確立し、IAP FSM 同士が持つ情報アクセスプロトコルを使用して通信をおこないサーバ側のデータベースにアクセスをする。IAS サービス・ユーザが要求する所望のデータを取得するとクライアントFSM はIrMUX の切断を行う。

▶7.11.2 IASの取り扱う情報モデル（オブジェクト・モデル）

IAS で取り扱う情報は、「名付きのオブジェクト」として取り扱われる。名付きのオブジェクトとは、「“名前空間”にあるユニークな“名前”によって識別されるオブジェクト」であると定義される。簡単に言えば、情報は、特定の文字列によって検索されるということである。IAS はこの名付きのオブジェクトの集合として、クラス（Class）と、属性（アトリビュートAttribute）という階層を持つ。数学的な表現を使えば、IAS に登録されるクラスは互いに素（独立）であり、属性はクラス集合の元（要素）である言ってよい。また、クラスの要素である属性は値（Value）を持つ。値はいくつかの型（タイプ）がある。

いささか抽象的であるので、具体的な例で説明しよう。この図は、”Class-A”と”Class-B”という二つのIAS オブジェクトが登録されている。たとえば、“Class-A”には、”Atrb-X”と”Atrb-Z”という二つの要素が、”Class-B”には、”Atrb-Y”と”Atrb-Z”の二つの要素が登録されている。”Class-A”に属する”Atrb-Z”と、”Class-B” に属する“Atrb-Z”は別物であることに注意しよう。”Class-A”の要素である属性 “Atrb-X”は Int 型の値(Value) “3”を持っている。その他の属性も同様である。

▶7.11.3 IAS属性（Attribute）値の種類

IAS で最終的に必要になるのは登録されているクラスとアトリビュートにより選択されるオブジェクトの値である。値には次の型(Type)がある。Class:“Class-A”Attribute:“Atrb-X”Value:Int:3 Attribute:“Atrb-Z”Value:Str:”abc”Class:“Class-B”Attribute:“Atrb-Y”Value:Int:3 Attribute:“Atrb-Z”Value:Oct:10,11 Missing 型そのアトリビュートには値がないことを表す。

Integer(Int) 型整数値であり、32 ビットの二の補数で表現されるバイナリデータを保持する。Octet Sequence (Oct)型8 ビットバイナリの列であり長さとバイナリデータを保持する。User String (Str)型文字列を保持する。文字列には文字の長さと、使用する文字コード属性を含む。

▶7.11.4 IASのサービス・プリミティブ

さて、IAS データ・ベースをアクセスするために提供されるサービス・プリミティブについて調べてみよう。情報アクセスプロトコル(IAP)は、リモートデータベース内のオブジェクトを特定する操作、オブジェクト内にある属性にアクセスする操作、存在するオブジェクト内にあるすべての属性の名前を見つける操作などを提供する。ひとつのクラスには複数の属性を持つ場合もある。もしこのクラスの中に複数の属性が存在するならば、属性値のリストが返される。

IAS はリモートアクセスによる属性の取得のために必要な機能しか提供しない、したがって、リモートデータベース上のクラスや属性を設定、変更、登録することはできない。IrLMP 仕様書のIAS サービス・プリミティブは、ローカルなデータベースに登録されるオブジェクトをどのように構築するのか、登録するのかというようなローカルな登録操作(Local Registration)については言及していないことに注意しよう。それは、プロトコルの実装において、データベースに登録されるオブジェクトが固定したデータとして存在するかもしれないし、特定のAPI のよって操作されるかもしれないからである。

▶7.11.4.1 LM-GetInfoBaseDetails

LM-GetInfoBaseDetails.要求 (address)LM-GetInfoBaseDetails.確認 (number of objects, max.object id)パラメタ：Addressリモート装置の32bit 装置アドレスnumber of objectsリモートデータベースのオブジェクトの数max.object idリモートデータベースの現在のオブジェクトＩＤの最大値このサービスはデータベースの登録状況の概要をレポートする。この情報に基づいてLM-GetObjects 操作に必要なパラメータを取得することが出来る。このサービスはオプショナルである。

▶7.11.4.2 LM-GetObjects

LM-GetObjects.要求 (address, first id, max.list, class name)LM-GetObjects.確認 (next id, list of (id, num.attributes, class name))パラメタ：Addressリモート装置の32bit 装置アドレスfirst id返送するリスト内の先頭オブジェクトID max.list返送するリストの最大長class nameクラスの名：（長さが０）の場合はすべてのクラスが検索されるnext idリスト内の最終オブジェクトの次のオブジェクトＩＤidリストの１項目のオブジェクトＩＤnum.attributesこのオブジェクトの属性の数class nameオブジェクトクラス名このサービスによって、クラス名、オブジェクトＩＤ、オブジェクトＩＤに含まれる属性の数を取得することができる。オブジェクトＩＤと、リストの長さ、クラス名を指定することで行なわれる。次の操作で使用される次のオブジェクトＩＤも返される。クラスの名前を指定すればそのオブジェクトの属性を取得する。

もし、null クラスネーム（長さが0 のクラス名）が設定されるなら、登録されているクラスすべての情報が返送される。このサービスは、繰り返し呼び出されることによりすべてのクラスのオブジェクトを取得することを目的としている。このサービスはオプショナルである。

▶7.11.4.3 LM-GetValue

LM-GetValue.要求 (address, id, attribute name1, [attribute name2, ...]LM-GetValue.確認 (List of attribute values)パラメタ：addressリモート装置の32bit 装置アドレスidオブジェクトＩＤattribute name検索する属性名values属性値指定されたオブジェクトの１つ以上の属性にアクセスする。もしその名前の属性値が存在しなければ、"missing"型の値が、返される。このサービスはオプショナルである

▶7.11.4.4 LM-GetValueByClass

LM-GetVarueByClass.要求 (address, class name, attribute name)LM-GetVarueByClass.確認 (list of (object id, attribute value))パラメタ：addressリモート装置の32bit 装置アドレスclass name検索するクラス名attribute name検索する属性名value属性値与えられたクラス名のオブジェクト内の属性名に与えられた値を検索する。リストは、それがたった一つしか返す値を持っていなかったとしても、常に返送される。そのクラス名はnull ではない。このサービスは必須のサービスであり必ず実装しなければらない。

▶7.11.4.5 LM-GetObjectInfo

LM-GetObjectInfo.要求 (address, id)LM-GetObjectInfo.確認 (lowest slot, highest slot, num.slot)パラメタ：addressリモート装置の32bit 装置アドレスid指定するオブジェクトＩＤlowest slot指定オブジェクトの現在の先頭スロットhighest slot指定オブジェクトの現在の最終スロットnum.slot現在使用されているスロットすべての数LM-GetObjectInfo の操作は、LM-GetAttributeNames サービスを呼び出す時に必要な情報を返す。その値は、使用されているすべてのスロットの中で、現在占有しているスロットの一番大きいものと、小さいものの属性値を返す。このサービスはオプショナルである。

▶7.11.4.6 LM-GetAttributeNames

LM-GetAttributeNames.要求 (address, id, first slot, number of names)LM-GetAttributeNames.確認 (next slot, List of (attribute name, type))パラメタ：Addressリモート装置の32bit 装置アドレスIdオブジェクトＩＤfirst slot属性名として始めに要求するスロットの番号number of names返送されるの属性名の最大数next slot返送リスト内の最終スロットの次のスロット番号attribute nameオブジェクトの属性名type属性の型LM-GetAttributeNames は指定したオブジェクトID のすべての属性をク取得するために使用する。このサービスの連続した呼び出しを行うことにより実行される。LM-GetAttributeNames が以前の呼び出しで返送されてくる次のスロット番号を使用して連続して呼び出すことにより、オブジェクトのすべての属性を得ることができる。

▶7.11.5 手続きの要素

情報アクセスサービスで使用するデータ構造について説明しておこう。

▶7.11.5.1 クラス名(Class Name)

クラス名は型ないのオクテットシーケンス（8 ビット[バイト]データの並び）よって伝達される。長さ符合なしの８ビットクラス名オクテットシーケンス 最長60 オクテットIAS の純粋な“名前空間”という意味では、文字列ではなく単なるバイナリ－データの列として考えている。しかし実際の応用では、ASCII 文字列をクラス名に使用される。

▶7.11.5.2 オブジェクトＩＤ(Object ID)

オブジェクトＩＤはMSB を先頭とした、16 ビット符合なし数値によって送られる。

▶7.11.5.3 属性(Attributes)

属性は、名前と値の対である。その名前はオクテットシーケンスによって符号化され、値は、特定の型を持つ。もしその型が固定長でなければ長さを持つオクテット列である。ひとつのオブジェクトには最大256 個の属性を持つことができる。

▶7.11.5.4 属性名(Attribute Name)

属性名は型なしのオクテットシーケンスによって伝達される。長さ符合なしの８ビット属性名オクテットシーケンス 最長60 オクテットLength Class Name 1 octet“Length” octets Identifier 2 octets Length Attribute Name 1 octet“Length” octetsオブジェクトは、同じ名前の属性を複数持つことはできない。

▶7.11.5.5 属性の値(Attribute Values)

値の型を表に示す。型の種類によって固定長のデータを持つもの、可変長のデータを含むものがあり、可変長のデータは長さのフィールドを含む。Table 3. IrLMP Attribute Value Types

▶7.11.5.5.1 不明(Missing)型

Missing 型は、属性が存在しないことを示す。

▶7.11.5.5.2 整数(Integer)型

整数型は、MSB を先頭とした符合付き32 ビット（２の補数）整数である。

▶7.11.5.5.3 オクテットシーケンス(Octet Sequence)型

オクテットシーケンス型は、８ビットを単位とした単なるデータ列である。データの内容についてのType Type Identifier Length Description Missing 0 Fixed : zero要求されたオブジェクトなしInteger 1 Fixed : 4 octets 32ビット符号付整数値Octet sequence 2 Variable 16 bit length field 1024バイトまでのオクテットﾃﾞｰﾀUser String 3 Variable 8 bit length field 255バイトまでの文字コード付き文字列Type = 0 1 octet Type = 1 Integer 1 octet 4 octets Type = 2 Length Sequence 1 octet 2 octets“Length” octets規定はない。データ列の長さを示す符号なしの16 ビットの長さフィールドを持つ。最長のデータ長は、1024 オクテットである。長さフィールドは、MSB を先頭とする。オクテットは順番にしたがって転送され、先頭のオクテットが最初にに転送される。

▶7.11.5.5.4 ユーザ文字列(User String)型

ユーザ文字列型は、可読な文字列を含む。データ列の長さを示す符号なしの8 ビットの長さフィールドと、文字列のコード体系をあらわすキャラクタセットフィールドを持つ。最長のデータ長は、255オクテットである。文字列の内容については指定する文字セットによる。ユニコードを使用する場合の文字は16 ビットで表現される。

▶7.11.5.5.6 文字コード

0xFF = 255

UNICODE Table 4. IrLMP Character Code Values

▶7.11.5.5.7 リスト形式

データベースの操作のいくつかは、結果の通知のためにリスト構造を使用する。さまざまなサービスで使用されるリストは同じ種類の構成要素からできている。リストは、転送操作によって指定される複数の項目として転送される。各項目は、その構成要素の特定の形式のとして、そのまま、送られる。リスト項目は、基本項目のかたまり（tuple）である。

▶7.11.5.6 IASサービスを提供するLSAP

IASサービスクライアントとサーバーは、単なるLM-MUXクライアントに過ぎないと説明した。したがって、IASも通常のIrMUXサービス・プリミティブを使用して構成することになる。IASも特定の＜Type = 3 Char. Set Length Characters 1 octet 1 octet 1 octet“Length” octets LSAP-SEL＞をもつ。IAS サーバにアクセスするまでは、LM-MUX クライアントに関する＜LSAP-SEL＞は明示的ではない。したがって、IAS の＜LSAP-SEL>はIrLMP の定義として固定のセレクタが割り当てられる必要がある。IrLMP は、IAS サーバの＜LSAP-SEL>として0 のセレクタを使用する。どのようなIrDA 装置であっても、IrLMP を搭載していればLSAP－SEL“0”によってIAS サーバーにアクセスできなければならない。

▶7.11.6 IAP フレームフォーマット

IAP はIrLAP フレームの情報フィールドを使用する。以下のフレームフォーマットについての説明する。

▶7.11.6.1 情報フレーム（I）

この図は、IrLAPとIrMUXによって与えられる情報フレームとIAPで使用するフィールドの関係をあらわす。IAP はIrMUX におけるクライアントである。IAP は、IrMUX で与えられるPCI の次のバイトにIAP 制御フィールド（IAP Ctl）によって操作を規定する。

▶7.11.6.2 IAP制御フィールド：

Last:複数のフレームで構成する、コマンドまたは結果の最終フレームであるということを示す。Ack:他のフィールドによって特定されたタイプのフレーム型が承認されたことを示す。Ack ビットがセットされると、フレームにはデータ（結果またアーギュメント）は存在しない。Address Control IAP Ctl SLSAP DLSAP Data Field IrLAP PCI IrMUX PCI Information Access Protocol Field IrLAP SDU(Service Data Unit)IrLAP PDU(Protocol Data Unit)Ack Last Operation Code Field

▶7.11.7 フレームフォーマットの操作

すべてのIAS データベースへのアクセス操作は、情報アクセスプロトコル(Information Access Protocol IAP)を使用する。それぞれのサービス基本は、IAP による情報の交換によって行われる。フレームフォーマットは、オペコード、アーギュメント、結果によって記述される。IAS クライアントが発行するアーギュメントは要求を記述するIAP フレームパケットである。IAS サーバーが返送するそれぞれの結果の先頭は、戻りコード(ReturnCode)と、追加の結果(Return)で構成される。結果は、IAP フレームパケット形式オブジェクトパケットか素のリストとして返送される。オクテット整数値は、MSB が先頭となって転送される。

▶7.11.7.1 LM-GetInfoBaseDetails

Op Code:1 Arguments:なしReturn code:

0x00

（成功：結果あり）0ｘFF（サポートされていない操作）Results:16 ビット符合なし整数（オブジェクト番号）16 ビット符合なし整数（最大オブジェクトＩＤ）

▶7.11.7.2 LM-GetObjects

Op Code:2 Arguments:16 ビット符合なし整数 (先頭 ID)+ 16 ビット符合なし整数(結果リストの最大長）+ 8 ビット符合なし整数(クラス名の長さ）+ "Length"オクテット(クラス名）Return code:

0x00

（成功：結果あり）

0xFF

（サポートされていない操作）Results:16 ビット符合なし整数（最終リストの次のＩＤ）+ 16 ビット符合なし整数（リスト長）+ 以下のリスト16 ビット符合なし整数（オブジェクトの番号）+ 8 ビット符合なし整数（属性の数）+ 8 ビット符合なし整数（連続するｵｸﾃｯﾄの長さ）+ "Length"オクテット（クラス名）

▶7.11.7.3 LM-GetValue

Op Code:3 Arguments:16 ビット符合なし整数 （オブジェクトの番号）+ 16 ビット符合なし整数 （リスト長）+ 以下のリスト8 ビット符合なし整数（連続するオクテットの長さ）+ "Length"オクテット（クラス名）Return code:

0x00

（成功：結果あり）

0x01

（オブジェクト不在）

0x02

（属性名不在）

0x03

（属性名が長過ぎる）

0xFF

（サポートされていない操作）Results:16 ビット符合なし整数 （リスト長）+ 以下のリスト+ 値

▶7.11.7.4 LM-GetValueByClass

Op Code:4 Arguments:8 ビット符合なし整数（クラス名の長さ）+ "Length"オクテット（クラス名）+ 8 ビット符合なし整数（属性名の長さ）+ "Length"オクテット（属性名）Return code:0（成功）1（クラス不在）2（属性不在）Results:16 ビット符合なし整数 （リスト長）+ 以下のリスト16 ビット符合なし整数（オブジェクトＩＤ）+ 値

▶7.11.7.5 LM-GetObjectInfo

Op Code:5 Arguments:16 ビット符合なし整数 （オブジェクトＩＤ）Return code:0（成功）1（オブジェクト不在）

0xFF

（サポートされていない操作）Results:16 ビット符合なし整数（最小スロット）+ 16 ビット符合なし整数（最大スロット）+ 16 ビット符合なし整数（使用スロット数）

▶7.11.7.6 LM-GetAttributeNames

Op Code:6 Arguments:16 ビット符合なし整数（オブジェクトＩＤ）+ 16 ビット符合なし整数（開始スロット）+ 8 ビット符合なし整数（とりだした名前数）Return code:0（成功）

0xFF

（オブジェクト不在）Results:16 ビット符合なし整数 （最終リスト項目の次のスロット）+ 16 ビット符合なし整数（リスト長）以下のリスト+ 8 ビット符合なし整数（属性名長さ）+ "Length of name"オクテット（属性名）+ 8 ビット符合なし整数（値の型）

▶7.11.8 IrLMPで規定するIASオブジェクト

IAS に登録されるオブジェクトはIAS そのものとしては、どのようなオブジェクトを登録すべきなのか言及しない。しかし、IrLMP規格およびIrDAで規定するその他の規格は特定のIASオブジェクトについて言及する。IrLMP におけるIAS オブジェクトの規定についてここで述べておくことにしよう。

▶7.11.8.1 Deviceオブジェクト

すべてのＩｒＤＡ装置には“Device”オブジェクトクラスの実装が必須となっている。オブジェクトには装置のもっているデバイス名とIrLMP のサービス・プリミティブのサポート範囲や、装置に関係する一般情報が含まれている。以下の項では“Device”オブジェクトクラスの属性に要求されることを記述する。要求される属性の名前は大文字小文字の識別があり表記どおり正確に表現されねばならない

▶7.11.8.1.1 Device Name属性

“Device Name”の属性はユーザ文字列型である値については、通常装置の名称などがふくまれる装置固有の文字列である。

▶7.11.8.1.2 IrLMP Support属性

“IrLMP Support”属性はオクテット列型であり、装置に実装されているIAS オプション機能と、LM-MUX のバージョンを含んでいる。属性のフォーマットはつぎの形式となる。IrLMP Version No IAS Support LM-MUX Support 1 Octet n Octets m Octet IrLMP Varsion No:1 オクテットで構成されるバージョン番号。現在のIrLMP は１で

0x01 とコード化される。

IAS Surpport n オクテットで構成されるIAS のオプションサポート情報LM-MUX Surpport:m オクテットで構成されるLM-MUX のオプションサポートIAS とLM-MUX のフィールドは両方ともオクテット単位で拡張可能である。もし、これらのフィールドオクテットの最上位ビットがセットされていればそのフィールドは次のオクテットに続いている。

▶7.11.8.1.2.1 IAS Support フィールドByte 1

Bit Function 0 GetInfoBaseDetails 1 GetObjects 2 GetValue 3未使用4 GetObjectInfo 5 GetAttributeNames 6未使用7 Extension IAS Support ビット割り当て

▶7.11.8.1.2.2 LM-MUX Surpport

Byte 1 Bit Function 0 Exclusive Mode 1 Role Exchange 2 ConnectionlessData 3未使用4未使用5未使用6未使用7 Extension LM-MUX Support ビット割り当てIASサポート、LM-MUXサポートフィールドはともにIrLMP（IrLAP機能も含む）オプション項目のサポート状況を示している。該当するビットが1 の場合はその機能が実装されていることを示している。

▶7.11.8.2 サービスオブジェクト定義の一般規定

LM-MUXを使用する上位層のために、LM-MUXの経路と付随する属性を示すためにIrLMPで規定するIAS オブジェクト形式が規定されている。これらの属性の使用は必須ではない。しかし、これらの属性がIrLMP によって定義されるものと同様の目的のために属性が要求される場合において、これらの使用をIrDA では強く勧告している。勧告されるIAS オブジェクトには２つの属性がある。Attribute Name Value Type Description IrDA:IrLMP:InstanceName 16 進表記:

0x49-72-44-41-3a-49-72-4c-4d

-50-3a-49-6e-73-74-61-6e-63-6 5-4e-61-6d-65 User Stringユーザ文字列は、ひとつのオブジェクトクラスにある他のインスタンスと区別するために使用される。（上位のサービス・ユーザ層を判別するためにも使用される。）インスタンスとは現在そのサービスを使用している装置内の上位層のアプリケーションやサービス・ユーザのことをいう。IrDA 装置がこのサービスに単独のインスタンスしか持たない場合はユーザ文字列は長さ０のNULL 文字列となる。

IrDA:IrLMP:LsapSel 16 進表記:

0x49-72-44-41-3a-49-72-4c-4d

-50-3a-4c-73-61-70-53-65-6c Integerそのオブジェクトサービス経路の＜LSAP-SEL＞を与える。この整数値は。0 から0x6f までのLSAP セレクタ番号となる。この属性は、LM-MUX に関係するサービス記述として主に使用される。場合によってはさらに上位のトランスポート層の属性定義を含むこともある。たとえば、LM-MUX 層の上位にTinyTP が存在しその経路を示すには、属性の名称はIrDA:TinyTP:LsapSel となる。

説明がいささか抽象的なので具体的な例で、説明することにしよう。

▶7.11.8.3 IASサービスオブジェクトの例

IrTran-P はIrLAP、IrLMP、TinyTP、IrCOMM 規格を使用したIrDA アプリケーション規格のひとつでデジタルカメラの画像転送規格である。この規格で使用するIAS サービスオブジェクトについて説明しておこう。

▶7.11.8.3.1 IrTran-Pカメラの場合のIASサービスオブジェクト例

サービスヒント：IrCOMM に割り当てられた10 ビットめのサービスヒントが1 になる。IAS オブジェクト：IAS オブジェクトクラス名としてIrDA:IrCOMM が登録され、いくつかの属性をもつ。オブジェクトクラス名IrDA:IrCOMM属性名値タイプ内容IrDA:TinyTP:LsapSel整数型<LSAP-SEL>番号InstanceNameユーザ文字列型 “IrTran-P”インスタンス名IrDA:IrCOMMクラスには、LSAPセレクタを検索する為にIrDA:TinyTP:LsapSel属性が登録されており、InstanceName にIrTran-P が登録されていることから、上位のインスタンスがIrTran-P であることがIAS 検索の結果から判定することが出来る。

▶7.12 LM-MUX ,IAS を使用した通信の例

IrLMPの章を終わりにするにあたって、LM-MUXとIASを使用した通信の例を紹介しておこう。1）発見動作イニシエータ側：サービス・ユーザは、LM_Discovery.要求を使用して、発見手順を行い、赤外線空間に存在する装置を発見し、発見ログ取得する。レスポンダ側：

LM_Discovery.指示がIrLMP 層より通知され、発見手順を行っている装置が

赤外線空間上にあることをサービス・ユーザが認識する。2）IAS 接続イニシエータ側：

LM_Discovery.確認がIrLMP 層より通知され、発見ログを取得する。取得し

たログの装置のサービスヒント、装置ニックネームより接続する装置を決定する。IAS 検索を行うために、接続決定した装置の装置アドレス、＜DLSAP－SEL>0（IAS-LSAP）、を使用してLM_Connect 要求を行い相手のIAS サーバーへの接続を待つ。レスポンダ側：IAS サーバーFSM は、LM_Connect.指示がIrLMP 層から通知され、接続相手の装置アドレスと接続データを受け取る。IAS サーバーFSM は、

LM_Connect 応答を使用して、接続データと接続の許可を行う。

3）IAS 検索イニシエータ側：

LM_Connect.確認がIrLMP 層から通知され、要求した接続が確立したことを

認識する。IAS クライアントFSM のLM_GetValueByClass 要求プロトコルを使用して、IAS に登録されているクラスレスポンダ側：IAS サーバーFSM は、LM_Data を受け取り、そのデータが

LM_GetClassByValue 要求であることを認識する。IAS サーバーは、要求さ

れたクラスオブジェクトを検索し、要求さらた属性を調べる。指定されたクラス属性が見つかると、LM_GetValueByClass 応答プロトコルによってその属性の値を通知する。イニシエータ側：

LM_Data 指示を受け取り、IAS クライアントFSM によって
LM_GetValueByClass.確認であることを認識すると、クラス属性の値をサービ

ス・ユーザ層が受け取る。この値を使用して、接続する＜LSAP SEL＞を決め、レスポンダ側のLMMUX LSAP を決定する。LM_Disconnect.要求を使用して、IAS 接続を終了する。レスポンダ側：IAS サーバーは、LM_Disconnect.指示を受け取りIAS サーバを切断する。4）サービス・ユーザ接続イニシエータ側：IAS 検索により取得したLSAP セレクタを使用して、要求するサービス・ユーザのあるエンドポイントにLM_Connect.要求を用いて接続を行う。

レスポンダ側：

LM_Connect.指示がサービス・ユーザに通知され、LM_Connect.応答により

接続を受け入れる。イニシエータ側：

LM_Connect.確認が通知され、接続が確認されたことを認識する。

5）データ転送イニシエータレスポンダ

LM_Data.要求を使用してデータ交換を行う。データが到来すると、
LM_Data.指示を受け取る。エンドポイントにあるサービス・ユーザ層は必要な

だけ、この操作を繰り返す。6）切断イニシエータレスポンダデータ転送が終了し、通信を終了したければ、LM_Disconnect.要求を発行する。相手が切断要求を発行すると、LM_Disconnect.指示がサービス・ユーザ層に通知され、通信が終了する。

▶7.13 IrLMPのまとめ

IrLMP 層は、多重化エンティティであるLM-MUX と必須のLM-MUX クライアントであるIASサーバー／クライアントFSM の2 つの要素から成り立つことがわかったと思う。LM-MUX は、多重化に伴う接続／切断／データ転送サービスにおいて、LSAP を導入し、LSAP というエンドポイントによって多重化を可能にした。IASは、データベースオブジェクトとして名付きのクラス、クラスの要素としての属性を導入し、属性には、特定の型（Type）を持つ値という概念を提供した。

IrDA 規格において、IrLAP 層では、物理レベルでの柔軟な接続手順を提供し、IrLMP では、アプリケーション指向としての多重化とそれに付属するデータベースを提供する。これにより、IrDA 装置が必要とする基本的な要素をIrDA 規格が提供したことになる。IrDA の定義によれば、IrDA 装置（デバイス）は、IrPHY 層、IrLAP 層、IrLMP 層をかならず持たねばならないことになっている。

IrLMP で提供するこれらの機能が、赤外線通信の必要条件をみたすための必須項目であることを読者も理解できたと思う。しかし、読者の中には、データ転送を行うためにかなり複雑な事前手続きが必要であることを煩雑に思うかもしれない。けれどもこれらの手続きによって得られるメリットは、赤外線通信における環境において有効に機能すること、IrLAP、IrLMP プロトコルを採用することで多くのアプリケーションが単一のプロトコルを共有することで生産性を高めることが出来ることなどのけして少なくはない。

8 TinyTP規格書IrDA 規格の基礎編の最後として、IrDA 規格のトランスポート層にあたるTinyTP について述べることにする。IrDA では、本来はIrTP というトランスポート層を規定していたが、機能が大きいために採用にはならず、結果として必要最小限度の機能を持った小さいトランスポート層という意味合いを持つTinyTPを採用することになった。TinyTPエンティティが提供するサービスについて調べることにしよう。

▶8.1 IrLMP層に不足している機能

IrLMP による多重化によって、複数のサービス・ユーザ層がLM-MUX のサービスアクセスポイントを同時にアクセスできる機構が用意されることを学んだ。さらに進んで考えると、LM-MUX の上位層単位でのデータフロー制御が必要になることがわかるだろう。LM-MUX のLSAP にサービスを要求している、それぞれのアプリケーション（サービスユーザ）が要求する実質のデータ転送レートはおのずから異なるし、アプリケーションごとにデータフロー制御が必要になることはいうまでもない。

しかし、IrLMP はデータフロー制御に関しては一切言及していないし、該当するサービスも存在しない。IrLAP 層では、RNR（受信ビジー）を送信することでデータ転送を一次的に停止できるが、赤外線リンク全体のデータフローとして動作する。したがって、各LSAP ごとにフロー制御を行うためにはさらにプロトコルが必要となるだろう。また、IrLMP までのプロトコルデータ単位（PDU）の構成をみると、上位層が使用できるユーザ・データ単位（SDU）は、IrLAP の接続手順における折衝パラメータでサイズが決まってしまうため、IrLAP 層、IrLMP 層のプロトコル制御情報（PCI）以降のデータサイズがLM-MUX で使用できるデータサイズとなる。アプリケーションを作成する立場から考えると、下位層の使用するデータサイズではなく、アプリケーションが要求する単位のデータサイズで下位層のサービス・プロバイダとデータ転送を行うことがのぞまれる。

この二つの要求を満たすのがTinyTP の機能である。したがって、TinyTP 層が受け持つサービス・プロバイダとしての機能は次のように説明できる。1） TinyTP は、エンドポイントごとにあるサービス・ユーザに対して独立したフロー制御機能を提供する。2） TinyTP は、エンドポイントごとにあるサービス・ユーザに対してサービス・ユーザの要求するサイズのデータ単位でのデータ転送を可能にする。

▶8.3 TinyTPのエレメント

▶8.3.1 TinyTPのサービス・アクセス・ポイント

TinyTP のサービスアクセスポイント（TTPSAP）は、その下位層にあるLM-MUX で使用するサービス・アクセス・ポイント(IrLMP LM-MUX LSAP)の上にそのままかぶさるように存在するため、TTPSAP と、LSAP は同じ内容となる。したがって次の公式が成り立つ。<TTSAP Address> = <LSAP Address> = <DeviceAddress><LSAP-SEL>

▶8.3.2 TinyTPのサービス・プリミティブ

▶8.3.2.1 TTP_Connect 接続プリミティブ

TTP_Connect.要求(Called TTPSAP,Requested QoS,

Calling MaxSduSize, Calling UserData )

TTP_Connect.指示( Calling TTPSAP, Resultant QoS,

Calling MaxSduSize ,Calling UserData)

TTP_Connect.応答( Calling TTPSAP,

Called MaxSduSize,Called UserData )

TTP_Connect.確認( Called TTPSAP,Resultant QoS,

Called MaxSduSize,Called UserData)パラメタ：TTPSAP TinyTP のエンドポイントのサービス・アクセス・ポイントのセレクタである。暗黙的に、IrLMP LM-MUX LSAP.の参照も含んでいる。QoS IrLMP/IrLAP におけるサービス品質（QOS）MaxSduSize上位層が要求する最大のユーザデータサイズのバイト数。要求サイズは、エンドポイントにある相手に通知される。要求サイズは、エンドポイントにおいて独立に要求される。

UserData UserData は、TinyTP 接続パケットにのせる少量のデータであり、接続時に転送される。接続確立の間に転送されるTinyTP 接続-PDU の全サイズは、IrLAP 接続の折衝によって制限される。TinyTP 接続-PDU のパラメータ・フィールドの最大サイズは、6 バイトにである。したがって、接続時に転送できるUserData は、52 バイト以下に制限される。典型的な使用方法はTinyTP クライアントの間のその接続のためのパラメータ交換である。

このサービスは、互いのエンドポイントにある2 つのIrLMP LSAP 間のTinyTP 接続を確立するために用いられる。対応するIrLMP LM-MUX LM-接続プリミティブに類似している。

▶8.3.2.2 TTP_Disconnect 切断プリミティブ

TTP_Disconnect.要求(UserData)
TTP_Disconnect.指示(Reason, UserData)

パラメタ：Reason切断理由：IrLMP で定義している切断理由をそのまま通知する。UserData切断要求を行った側から通知されるユーザデータつぎの目的で、切断サービスが用いられる：TinyTP 接続通知を拒否する場合。TinyTP 接続を終了する場合。下位のサービス・プロバイダによる異常終了。

TTP_Disconnectサービス・プリミティブは、対応するIrLMPのLM_Disconnectサービス・プリミテ

ィブに関係付けられる。

▶8.3.2.3 TTP_Data データ転送プリミティブ

TTP_Data.要求(UserData)
TTP_Data.指示(UserData,Status)

パラメタ：UserData TTPクライアントの間で交換されるTTPクライアント・サービスデータユニット（SDU）である。SAR がアクティブであるならば、要求プリミティブの中で転送するUserData フィールドのサイズはTTP_Connect.指示またはTTP_Connect.確認プリミティブの中で通知されたMaxSduSize を上回ってはならない。SAR が非アクティブならば、UserData フィールドのサイズは一つのデータTTP-PDU の範囲内で合うことを強制される。

Status転送ステータスは以下の値をとる。OK：（成功）再構成処理がおこなわれていないか、再構成が成功したことを表す。Truncated:（切り詰め）接続時に合意されたサイズを上回るため、SDU を切り詰めたことを表す。

TTP_Data.要求の発行によって転送されたTTP SDU は、TTP_Data.指示の通知によって対応

するエンドポイントに届けられる。

TTP_LocalFlow サービスは、TTP_Data.指示サービス・プリミティブの発生を延期したり、再開する

ために用いられる。

▶8.3.2.4 TTP_Udata 単位データ転送

TTP_UData.要求(UserData)
TTP_UData.指示(UserData)

信頼性のないデータ転送を行う。TinyTP で与えれれるフロー制御は行われない。送られたデータが確実に届けられる保証はない。これらのサービス・プリミティブは、直接対応するLM-UData サービス・プリミティブにマップされる。UserData フィールドのサイズは、LM-PDU のUserData（SDU）によって制限される。

▶8.3.2.5 TTP_LocalFlow ローカルフロー制御

TTP_LocalFlow.要求(Flow=on|off)

パラメタ：Flow On: データ転送を有効にする。Off: データ転送を一次休止する。このサービスは、TinyTP クライアントのローカルなフロー制御を行うために使用する。

▶8.4 Tiny TP Protocol Data Unit（PDU）の構成

▶8.4.1 TTP-PDUのデータ表現

TTP-PDU のデータは、IrLMP LM-MUX におけるLM-PDU のUserData フィールド内に構成され、1 バイトのTinyTP 制御PCI とユーザデータで表現される。

▶8.4.1.1 データ転送TTP-PDU

フィールドの定義：Mモアビットこのビットが１の場合、分割されたデータが終了しておらず、続いて到来するデータと連結する必要があることを通知する。このビットが0の場合、これ以上連結するデータが損際しないことを表す。接続時に交換されたMaxSduSize が0 の場合は分割再構成されない。DeltaCreditローカルクレジットの増分TinyTP エンティティで受け取れる追加のPDU の増分を通知する。UserData TinyTP で分割されたサービスデータ

▶8.4.1.2 接続TTP-PDU

接続TTP-PDU は、コネクション確立時に、交換される。このPDU は、接続要求LM-PDU、接続確認LM-PDU のUserData フィールドに配置される。IrLMP LM_Connect のUserData は、そのまま、接続TTP-PDU としてTinyTP エンティティに通知される。接続TTP-PDU には二つの形式がある。DeltaCredit UserData M 0-(IrLAPmax-3) bytes 1 byte Bit:7 6-0 InitialCredit UserData P=0 0 to 59 bytes 1 byte Bit:7 6-0パラメータなし 接続 TTP-PDUパラメータ付き 接続 TTP-PDUフィールドの定義Pパラメータビット1 の場合、接続パラメータが存在することをあらわす。

0 の場合は、接続パラメータが存在しないことを表す。この場合の接続パラメータはデフォルトとなる。InitialCredit初期クレジット接続段階で、TTP-PDU をいくつ受信できるかを示す。Parametersパラメータフィールド：IrDA 標準形式（6.7.10.1 で説明した形式）であるPI,PL,PV形式のデータで表現したパラメータがあることを示している。先頭の1 バイトは、パラメータの数をあらわす。

UserData接続時に交換される上位層のためのユーザデータ

▶8.4.1.2.1 接続Connect TTP-PDU Parameters

TinyTP接続で使用するパラメータは、最大のSDUサイズを決定するMaxSduSizeパラメータだけである。パラメータ名:MaxSduSize PI 値:

0x01

PL 範囲:

0x00 から0x04

InitialCredit UserData P=1 0 to (59-(x+1)) bytes 1 byte Bit:7 6-0 Plen=x Parameters Pvalue PI PL PV PI PL 1st Parameter 2nd Parameter(if present)..........Length in Bytes:1 1 PL 1 byte x bytes PV PV Value の規則：バイト単位のUserData の最大サイズがを提供する。MaxSduSize が0 以外の場合は、受け取り側のTTP クライアントが受け取り可能な最大TTP-SDU サイズを表す。仮に、IrLAP によって折衝された最大データ・サイズより小さいとしても、このパラメータの値は厳しく適用されなければならない。

PVの構成は最大4バイトの符号なしの整数で先頭がMSBである。先行ゼロのバイトデータは、切り詰めることができる。分割／再構成を必要としないストリームデータを取り圧合う場合は、0 に設定する。このパラメータのデフォルト値は0である。この場合は、パラメータなしの接続TTP-PDUを使用する。この場合、データTTP-PDU は、M ビットは0 として送られなければならない。

▶8.5 分割／再構成のモデル

TinyTPの接続時に交換されるMaxSduSizeによって、サービスユーザデータの最大サイズは1からの範囲となる。この指定されたデータは、IrLAP 接続時に決められたIrLAP のユーザデータサイズから間接的に決まるTTP-SDU に分割されて転送されることになる。TTP の最大ユーザデータサイズをN、上位層からMaxSduSize を超えないM バイトのデータを送信すると次のようにTTP-PDU を転送されることになるだろう。

送信側：1） SDU の分割数D は、M をN で割った値に、剰余がある場合は1 を加える。2) 0 からD-1 まではM ビットを1 にして上位層のサービスデータユニットを分割して先頭から送信する。3） のこりのデータユニットをM ビットを0 にして転送する。受信側：１) バッファをクリアし、データ格納ポインタをバッファの先頭に初期化する。2) 受け取ったPDU のM ビットが1 に場合は、MaxSduSize を超えないか確認した後、格納ポインタの位置に受信したデータを転送して、ポインタを進める。もしM ビットが0 に場合は、格納ポインタの位置に受信したデータを転送して、上位層にデータ受信したことを通知する。もし受信中にMaxSduSize を超えている場合は、切り詰めたことを通知する。

()1 2 32 -

▶8.6 フロー制御モデル

TinyTP のフロー制御モデルは、TinyTP 層にリサイクルバッファを使用したフロー制御管理機構があることを想定している。TinyTP にあるリソースは次のものを想定している。内部変数リモートクレジット変数R-Creditローカルクレジット変数L-Creditローカル受信バッファ数BNローカル受信バッファBuff[BN]接続時接続時には、R Credit の値は、接続TTPPDU で送られてくる初期クレジット値とする。また、LCredit を0 に初期化する、BN 個のPDU が受けられることを通知する。すると相手のR Credit はBN となるデータ送信時R-Credit が0 でなければ、データTTP－PDU を構成し、データを送信する。R-Credit を一つ減らす。現在のL-Credit をTTP PDU のDeltaCreditにのせる。L-Credit を0 にする。

データ受信時受信データをあいているローカル受信バッファに入れる。もし、RCredit が0でないならば、ユーザデータのないTTP PDU を作成し、DeltaCredi にLCredit を設定、M ビットを0 としてクレジット増加を伝える「データレスフローデータ」を送信する。LClredit を0 にする。上位のサービス・ユーザにデータ受信を通知した場合ローカルフローがビジーの場合は何もしない。サービス・ユーザにデータを引き取らせたら、あいたバッファの数だけ、L-Credit を増やす。

ローカルビジーが解除された場合ローカル受信データがある場合は、上位のサービス・ユーザにデータ受信を通知する処理を行う。以上のアルゴリズムを使用することでTinyTP のフロー制御が可能になる。この例はフロー制御のしくみを説明するためのものでありTinyTP 仕様書に述べられている方式ではない。実装の際には、TinyTP 規格書にしたがって実装するべきであるのは言うまでもない。

▶8.7 TinyTPのまとめ

TinyTP の提供するフロー制御そして分割再構成は、きわめてシンプルであることが理解できたと思う。接続が確立し、データを交換する段階でのプロトコルのオーバーヘッドはたったの１バイトに過ぎない。ここで肝心なことは、プロトコルのサービス機能を充実しようとすると、サービス・プロバイダ内で管理するPCI（プロトコル制御情報）が増加する傾向にあるということを理解する必要がある。TinyTP の場合も、上位のサービス・ユーザが必要とする最小のトランスポート層を提供することにとどめているのはそのためである。

9 基礎編のまとめ

▶9.1 IrDA規格を振り返って

さて、IrDA 規格の基本となる、IrPHY 規格、IrLAP 規格、IrLMP 規格、TinyTP 規格について詳しく学んできた。読者もここまで読み進めてくれば、なぜこのような階層構造が必要であり、それぞれのプロトコル層のサービスがなぜその層で実現されなければならないのか、そしてプロトコルにおけるサービスインターファイス、PDU の構造、状態遷移などがどのように実現されているのか理解できたのではないかと思う。

本書の冒頭で指摘したとおり、新しい通信プロトコルは一日にして出来あがったものではなく、過去の厚い技術蓄積があってこそ存在しうるものであることを本書を通じて理解できたと思う。HDLC などの信頼性があり、すでに多くのシステムで使用されている枯れたプロトコルを基本にして、赤外線通信とモバイル通信環境にどのように適合させていくかがIrDA 規格のテーマでありその結果がこれらの規格に大いに反映している。新しいプロトコルの真の理解は、単に規格書に述べられていることを忠実に再現してえられるものではない。IrDA 規格もそうであるが、赤外線通信を可能にするいくつかの可能性の中で選ばれたひとつの方式に過ぎない。選択された方式は、その時点でもっとも有効な手段であるという確信に基づいて選ばれたのはいうまでもないが、その選択は未来永劫保証されるものではなく、プロトコルを利用しつつ、次世代に適合させていけるように改良されなくてはならないだろう。IrDA 規格も、初期の段階では115200bps までの通信速度であったものが現在では4Mbps までに拡張された。そして16Mbps の実現を目指して着々と進化していこうとしている。

おわりに、本書で学んだことは、ISDN のLAPB や、ITU-T X.25、HPS 通信規格PIAFS などの基本的な理解の助けになると筆者は考えている。

▶9.2 応用編について

基礎編では、すべてのIrDA 装置が実装すべき各プロトコル層の構造について学ぶことを目的とした。応用編ではそれに続いてより目的指向の強いIrDA 規格のアプリケーション層について学んでいくことにしたい。応用編ではまずIrDAの基本規格を振り返りWindows CEやNTなどに実装されている赤外線通信ソケットサービスであるIrSockや、IrDA規格のIrLAP、IrLMPの最小セットであるIrDA Lite規格についても触れる。さらに、IrDA 規格のアプリケーション層である次の規格を学んで行く。

1） ケーブルエミュレーション・エンティティIrCOMM RS232C、プリンタケーブルエミュレーションIrLAN赤外線LAN アクセス2）赤外線データ交換・エンティティIrOBEX赤外線オブジェクト交換3）赤外線音声通信・エンティティRTCON赤外線リアルタイム音声通信規格さらに特定の応用分野を想定したＩｒＤＡ規格であるIrTran-P デジタルカメラ向け赤外線画像通信規格IrMC携帯電話向け赤外線通信規格などの応用分野にも踏み込んで解説する予定である。IrTran-P では、画像フォーマット規格であるUPF 形式も詳しく議論する。IrMC では、データ交換の主体であるvCard や、ITU-T V.25 terなどIrMC を理解するために必要となる知識についても触れたいと考えている。

応用編のテーマは、基礎編で学んだIrDA 規格の基礎項目がいかに応用面で活用されているかを理解するとともに、それぞれのアプリケーション層の問題解決手法の違いについて理解を深めることにある。

▶10.1 IrLAP-PDU

▶10.1.1 IrLAP基本PDU

（BOF）フレームの開始を示す開始フラグ(A)二次局コネクションアドレスを識別するアドレスフィールド(C)特定のフレームの機能を規定する制御フィールド（I）情報データを含むオプションの情報フィールド（可変長でありない場合もある）（FCS）受信局がフレーム伝送の正当性を検査するためのフレームチェックシーケンス（EOF）フレームの終了を示す終了フラグ

▶10.1.2 アドレスフィールド（A）

▶10.1.3 フレーム検査シーケンスフィールド（FCS）

8 bits 8 bits 8 * M bitsアドレス部A制御部C情報部I先頭のバイト位置は、物理層によって供給されるA A A A A A A C/R!"#$部7 0 BOF A C I FCS EOF 8 bits 8 bits 8 bits 2 * 8 bits 8 bits M * 8 bits FCS

▶10.1.4 制御フィールド（C）フォーマット

▶10.1.4.1 非番号制フォーマット(U)のコマンド／レスポンス

7 6 5 4 3 2 1 0コマンド／レスポンス1 0 0 P 0 0 1 1 SNRM コマンド (正規応答モード要求)0 1 0 P 0 0 1 1 DISC コマンド（切断要求）0 0 0 P 0 0 1 1 UI コマンド（非番号制データ送信）0 0 1 P 1 1 1 1 XID コマンド（局識別相互交換要求）1 1 1 P 0 0 1 1 TEST コマンド（テスト要求）1 0 0 F 0 0 1 1 RNRM レスポンス（正規応答モード応答）0 1 1 F 0 0 1 1 UA レスポンス（非番号制受信応答）

1 0 0 F 0 1 1 1 FRMR レスポンス（回復不能誤り検出）0 0 0 F 1 1 1 1 DM レスポンス（切断状態通知）0 1 0 F 0 0 1 1 RD レスポンス（DISC コマンド要求）0 0 0 F 0 0 1 1 UI レスポンス（非番号制データ送信）1 0 1 F 1 1 1 1 XID レスポンス（局識別相互交換応答）1 1 1 F 0 0 1 1 TEST レスポンス（テスト応答）0 1 0 P 1 1 1 1 XCHG コマンド (一次局/二次局交換通知)1 1 0 P 1 1 1 1 DXCHG コマンド (一次局/二次局交換不能)1 1 0 F 1 1 1 1 RXCHG レスポンス(一次局/二次局交換要求)

▶10.1.4.1.1 XIDの情報（I）フィールドの内容

コマンド XID frameレスポンス XID frame Format at Specific 部X X X X P/F X 1 1 7 6 5 4 3 2 1 0 C/R = 1 Addr = X’FE’XID Command Format Identifier Format Specific 1 byte 1 byte 1 byte C/R = 0 Addr = X’FE’XID Response Format Identifier Format Specific 1 byte 1 byte 1 byte Discovery Flags Bit 1 Bit 0 meaning 0 0 1 slot 0 1 6 slots 1 0 8 slots 1 1 16 slots

▶10.1.4.1.2 接続要求 SNRMコマンドの情報（I）フィールド

▶10.1.4.1.3 接続応答 UAレスポンスの情報（I）フィールド

▶10.1.4.1.4 FRMR(回復不能誤り検出)

FI X’01’Source Device Address Destination Device Address Discovery Info 1 byte 4 bytes 4 bytes Discovery Flags 1 byte Slot Number Version Number 1 byte 1 byte 32 bytes Negotiation Parameters 4 bytes 4 bytes 1 byte N bytes Destination Device Address Source Device Address Connect Address 7 6 5 4 3 2 1 0 C/R=0 New connection address Source Device Address Destination Device Address Negotiation Parameters 4 bytes 4 bytes Rejected frame Control field C/R N(S)z 4 5-7 0 1 Byte N(R)1 - 3 0 y x w 0000 3 2 1 0 4-7 1 Byte 1 Byte Bits 0 - 7

▶10.1.4.2 監視フォーマット(S)

7 6 5 4 3 2 1 0 HDLC、IrLAP 共通のコマンド／レスポンスNr P/F 0 0 0 1 RR (受信可能通知)Nr P/F 0 1 0 1 RNR（受信不能通知）Nr P/F 1 0 0 1 REJ（指定フレーム以降のフレーム再送要求）

▶10.1.4.3 情報転送フォーマット(I)

▶10.1.4.4 P ビット

一次局は、Pビットによって、二次局からのレスポンスを勧誘（催促）する。一次局は、Pビットが1 であるコマンドを送信した後は、F ビットが１になっているレスポンスを受信するか、タイムアウトに達するまではなにも送信することは出来ない。

▶10.1.4.5 F ビット

P ビットが1 であるコマンドに対する応答に使用する。F ビットを1 にしたレスポンスを送信した場合、P ビットが１になっているコマンドを受信するまで、なにも送信することは出来ない。P ビットが1 のフレームは、二次局は、応答の最終フレームを伝送するときにも使用される。これは一次局に送信権を返すことを意味する。Nr X P/F X 0 1 7 6 5 4 3 2 1 0 Nr P/F 0 7 6 5 4 3 2 1 0 Ns

▶10.1.5 IrLAP折衝パラメータ

▶10.1.5.1 IrDAパラメータ表現の基本

▶10.1.5.2 ボーレートパラメタ (PI=X`01',タイプ0)

ビット0 = 2400 bpsビット1 = 9600 bpsビット2 = 19200 bpsビット3 = 38400 bpsビット4 = 57600 bpsビット5 = 115200 bpsビット6 = 576000bpsビット7 = 1152000bps 4000000bps をサポートする場合は、2 バイトで表現されるビット8 = 4000000bpsビット9 からビット15 は将来のために予約され0 にセットする。

▶10.1.5.3 最大ターンアラウンドタイム (PI=X`82',タイプ1)

ビット0 = 500msビット1 = 250msビット2 = 100msビット3 = 50msビット4 から7 は予約。0 に設定しなければならない。(1-3 ビットは115200bps 以上の場合のみ有効である)

▶10.1.5.4 データサイズ(PI=X`83',タイプ1)

ビット0 = 64 バイトビット1 = 128 バイトビット2 = 256 バイトビット3 = 512 バイトビット4 = 1024 バイトビット5 = 2048 バイトビット6、ビット7 は予約。0 に設定しなければならない。!"#$%列PI PL PV PI PL第一!"#$%(if present)第二!"#$%(if present)..........PV

▶10.1.5.5 ウインドウサイズ (PI=X`84',タイプ1)

ビット0 1 フレームウインドウビット1 2 フレームウインドウビット2 3 フレームウインドウビット3 4 フレームウインドウビット4 5 フレームウインドウビット5 6 フレームウインドウビット6 7 フレームウインドウビット7予約。0 に設定しなければならない。

▶10.1.5.6 追加BOF数(PI=X`85',タイプ1)

ビット0 115200 で48 個の追加BOFビット1 115200 で24 個の追加BOFビット2 115200 で12 個の追加BOFビット3 115200 で5 個の追加BOFビット4 115200 で3 個の追加BOFビット5 115200 で2 個の追加BOFビット6 115200 で1 個の追加BOFビット7 115200 で0 個の追加BOFこのパラメタは両局で独立に折衝される。

▶10.1.5.7 ボーレート換算BOF数

2400bps = BOF 数パラメタ値/48 9600bps = BOF 数パラメタ値/ 12 19200bps = BOF 数パラメタ値/6 38400bps = BOF 数パラメタ値/ 3 57600bps = BOF 数パラメタ値/2 115200bps = BOF 数パラメタ値/ 1

▶10.1.5.8 各種ボーレートと追加BOFの関係

Baud Rate 48 BOF 24 BOF 12 BOF 6 BOF 3 BOF 2 BOF 1 BOF 0 BOF 2400 1 0 0 0 0 0 0 0 9600 4 2 1 0 0 0 0 0 19200 8 4 2 1 0 0 0 0 38400 16 8 4 2 1 0 0 0 57600 24 12 6 3 1 1 0 0 115200 48 24 12 6 3 2 1 0

▶10.1.5.9 最小ターンアラウンドタイム (PI=X`86',タイプ1)

ビット0 = 10msビット1 = 5msビット2 = 1msビット3 = 0.5msビット4 = 0.1msビット5 = 0.05msビット6 = 0.01msビット7 = 0ms

▶10.1.5.10 リンク解放/スレシホールドタイム (PI=X`08',タイプ0)

ビット0 3 秒 (スレシホールドタイム= 0)ビット1 8 秒 (スレシホールドタイム= 3 秒)ビット2 12 秒 (スレシホールドタイム= 3 秒)ビット3 16 秒 (スレシホールドタイム= 3 秒)ビット4 20 秒 (スレシホールドタイム= 3 秒)ビット5 25 秒 (スレシホールドタイム= 3 秒)ビット6 30 秒 (スレシホールドタイム= 3 秒)ビット7 40 秒 (スレシホールドタイム= 3 秒)

▶10.1.5.11 デフォルト折衝パラメータ表

通信速度9600bpsウインドウサイズ1最大データサイズ64 バイト最大ターンアラウンドタイム500ms BOF 数10

▶10.1.5.12 タイプ0パラメタ折衝の手続き

ステップ1一次局は、サポートできるPV のすべてのビットを1 にして、SNRM フレームを送信する。ステップ2二次局は、SNRM フレームを受信すると、SRNM 折衝値と自分のサポートできる同じパラメタフィールドの論理的なAND をとって、自分の能力と一次局の能力の共通部分を作り出す。ステップ3この操作の結果は、SNRM-UAフレームに含まれ、コネクション中に使われるパラメタを決める。ステップ4折衝パラメータ値ので 1 に設定されビットのうち最上位ビットが選択される。PVフィールドが複数バイトあるならば、選択されているもののうち最上位バイト(最初に受信したもの)とする。その時点で定義されているバイトは常に最下位バイトとなる。

▶10.1.5.13 バイト数換算の最小ターンアラウンドタイム表（単位バイト）

Baud Rate 10ms 5ms 1ms

9600 10 5 1 0 0 0 0 19200 20 10 2 1 0 0 0 38400 40 20 4 2 0 0 0 57600 58 29 6 3 1 0 0 115200 115 58 12 6 1 1 0 576000 720 360 72 36 7 4 2 1152000 1440 720 144 72 14 7 1 4000000 5000 2500 500 250 50 25 5

▶10.1.5.14 バイト数換算の最大ライン能力表（単位バイト）

Baud Rate 500ms 250ms 100ms 50ms 9600 400 n/a N/a n/a 19200 800 n/a N/a n/a 38400 1600 n/a N/a n/a 57600 2360 n/a N/a n/a 115200 4800 2400 960 480 576000 28800 11520 5760 2880 1152000 57600 28800 11520 5760 4000000 200000 100000 40000 20000

▶10.2 LM-PDU

▶10.2.1 LM-PDU

7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 C DLSAP-SEL r SLSAP-SELフィールドの定義：C ビット制御ビット。制御ビットが1 にセットされると、そのフレームがIrLMP におけるコマンド・フレームであることを示す。制御ビットが0 にセットされると、LM_PDU はデータとして扱われる。DLSAP-SEL宛先LSAP。このPDU を受け取る先のサービス・アクセス・ポイントのセレクタを示している。r ビット将来の使用のために予約されており、0 にセットしなければならない。

SLSAP-SEL発信元LSAP。このPDU を発行したサービス・アクセス・ポイントのセレクタを示している。

▶10.2.2 データ転送PDU

7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 0 DLSAP-SEL 0 SLSAP-SEL Data ….

▶10.2.3 LM-MUX リンク制御PDU

7 6-0 7 6-0 7 6-0 1 DLSAP-SEL 0 SLSAP-SEL A opcode parameters A ビット0にセットされたとき、IrLMPにおける発信側でのコマンド要求（要求）を意味し、宛先側ではコマンド指示(指示)として解釈されなければならない。A ビットが1 にセットされたとき、発信側ではコマンド応答(応答)で、宛先側ではコマンド確認(確認)である。

▶10.2.3.1 リンク制御のオペコード（命令コード）

A opcode Frame Command parameters 0 1 I Connect Rsvd = 0x00 (Optional) or rsvd = 0x00, LMS-UserData(Optional)1 1 I Connect (確認)rsvd = 0x00 (Optional) or rsvd = 0x00, LMS-UserData(Optional)0 2 I Disconnect reason,LMS-UserData(Unspecified)0 3 I AccessMode rsvd=0x00, mode 1 3 I AccessMode (確認)status, mode

▶10.2.3.2 切断理由コード(Reasonコード)

Reason Code User 要求

0x01

0xff

▶10.2.3.4 アクセスモード設定パラメータ

Mode Value Multiplexed

0x00

Exclusive

0x01

▶10.2.3.5 アクセスモード要求結果通知コード

Status Value Success

0x00

Failure

0x01

Unsupported

0xFF

Access Mode 確認のみ

▶10.2.4 LM-IAS IAP フレームフォーマット

▶10.2.4.1 IAP情報フレーム（I）

▶10.2.4.2 IAP制御フィールド

Last:複数のフレームで構成する、コマンドまたは結果の最終フレームであるということを示す。Ack:他のフィールドによって特定されたタイプのフレーム型が承認されたことを示す。Ack ビットがセットされると、フレームにはデータ（結果またアーギュメント）は存在しない。Address Control IAP Ctl SLSAP DLSAP Data Field IrLAP PCI IrMUX PCI Information Access Protocol Field IrLAP SDU(Service Data Unit)IrLAP PDU(Protocol Data Unit)Ack Last Operation Code Field

▶10.2.4.3 LM-GetInfoBaseDetails

Op Code:1 Arguments:なしReturn code:

0x00

（成功：結果あり）0ｘFF（サポートされていない操作）Results:16 ビット符合なし整数（オブジェクト番号）16 ビット符合なし整数（最大オブジェクトＩＤ）

▶10.2.4.4 LM-GetObjects

Op Code:2 Arguments:16 ビット符合なし整数 (先頭 ID)+ 16 ビット符合なし整数(結果リストの最大長）+ 8 ビット符合なし整数(クラス名の長さ）+ "Length"オクテット(クラス名）Return code:

0x00

（成功：結果あり）

0xFF

（サポートされていない操作）Results:16 ビット符合なし整数（最終リストの次のＩＤ）+ 16 ビット符合なし整数（リスト長）+ 以下のリスト16 ビット符合なし整数（オブジェクトの番号）+ 8 ビット符合なし整数（属性の数）+ 8 ビット符合なし整数（連続するｵｸﾃｯﾄの長さ）+ "Length"オクテット（クラス名）

▶10.2.4.5 LM-GetValue

Op Code:3 Arguments:16 ビット符合なし整数 （オブジェクトの番号）+ 16 ビット符合なし整数 （リスト長）+ 以下のリスト8 ビット符合なし整数（連続するオクテットの長さ）+ "Length"オクテット（クラス名）Return code:

0x00

（成功：結果あり）

0x01

（オブジェクト不在）

0x02

（属性名不在）

0x03

（属性名が長過ぎる）

0xFF

（サポートされていない操作）Results:16 ビット符合なし整数 （リスト長）+ 以下のリスト+ 値

▶10.2.4.6 LM-GetValueByClass

Op Code:4 Arguments:8 ビット符合なし整数（クラス名の長さ）+ "Length"オクテット（クラス名）+ 8 ビット符合なし整数（属性名の長さ）+ "Length"オクテット（属性名）Return code:0（成功）1（クラス不在）2（属性不在）Results:16 ビット符合なし整数 （リスト長）+ 以下のリスト16 ビット符合なし整数（オブジェクトＩＤ）+ 値

▶10.2.4.7 LM-GetObjectInfo

Op Code:5 Arguments:16 ビット符合なし整数 （オブジェクトＩＤ）Return code:0（成功）1（オブジェクト不在）

0xFF

（サポートされていない操作）Results:16 ビット符合なし整数（最小スロット）+ 16 ビット符合なし整数（最大スロット）+ 16 ビット符合なし整数（使用スロット数）

▶10.2.4.8 LM-GetAttributeNames

Op Code:6 Arguments:16 ビット符合なし整数（オブジェクトＩＤ）+ 16 ビット符合なし整数（開始スロット）+ 8 ビット符合なし整数（とりだした名前数）Return code:0（成功）

0xFF

（オブジェクト不在）Results:16 ビット符合なし整数 （最終リスト項目の次のスロット）+ 16 ビット符合なし整数（リスト長）以下のリスト+ 8 ビット符合なし整数（属性名長さ）+ "Length of name"オクテット（属性名）+ 8 ビット符合なし整数（値の型）

▶10.3 TinyTP-PDU

▶10.3.1 データ転送TTP-PDU

Mモアビットこのビットが１の場合、分割されたデータが終了しておらず、続いて到来するデータと連結する必要があることを通知する。このビットが0の場合、これ以上連結するデータが損際しないことを表す。接続時に交換されたMaxSduSize が0 の場合は分割再構成されない。DeltaCreditローカルクレジットの増分TinyTP エンティティで受け取れる追加のPDU の増分を通知する。UserData TinyTP で分割されたサービスデータ

▶10.3.2 接続TTP-PDU

DeltaCredit UserData M 0-(IrLAPmax-3) bytes 1 byte Bit:7 6-0 InitialCredit UserData P=0 0 to 59 bytes 1 byte Bit:7 6-0 InitialCredit UserData P=1 0 to (59-(x+1)) bytes 1 byte Bit:7 6-0 Plen=x Parameters Pvalue PI PL PV PI PL 1st Parameter 2nd Parameter(if present)..........Length in Bytes:1 1 PL 1 byte x bytes PV

▶10.3.2.1 パラメータ付き 接続 TTP-PDU

フィールドの定義Pパラメータビット1 の場合、接続パラメータが存在することをあらわす。0 の場合は、接続パラメータが存在しないことを表す。この場合の接続パラメータはデフォルトとなる。InitialCredit初期クレジット接続段階で、TTP-PDU をいくつ受信できるかを示す。Parametersパラメータフィールド：IrDA 標準形式（6.7.10.1 で説明した形式）であるPI,PL,PV形式のデータで表現したパラメータがあることを示している。先頭の1 バイトは、パラメータの数をあらわす。

UserData接続時に交換される上位層のためのユーザデータ

▶10.3.2.2 接続Connect TTP-PDU Parameters

パラメータ名:MaxSduSize PI 値:

0x01

PL 範囲:

0x00 から0x04

11. 付録B IrDA層別サービス一覧

▶11.1 IrLAP サービス

▶11.1.1 Discovery Services

IrLAP-DISCOVERY.要求()IrLAP-DISCOVERY.指示(Discovery-Log)IrLAP-DISCOVERY.応答(List-of-Discovery-Logs)パラメタ:Discovery-Log Solicited + sniff + 装置アドレス + IrLAP Version+ discovery info List-of-Discovery-Logs｛Discovery Log ｝Solicited[true | false]発見ログの構成：Sniff[true|false]発見された装置がスニフィング装置か否かを示す。

スニフィング（省電力動作については、後述する）装置アドレス32 ビットで構成される装置アドレスである。IrLAP-version 7 ビットで構成される応答側のIrLAP 層のバージョンを示す。Discovery-Info 32 バイトまでのフィールドで、内部の情報はサービス・ユーザ層によって規定される。

▶11.1.2 Address Conflict Services

IrLAP-NEW-ADDRESS.要求(装置アドレス)IrLAP-NEW-ADDRESS.確認(List-of-Discovery-Logs)パラメタ:装置アドレスIrLAP の32 ビット装置アドレスList-of-Discovery-Logs発見サービスを参照

▶11.1.3 Unit Data Services 単位データサービス

IrLAP UNITDATA.要求(User-Data)IrLAP UNITDATA.指示(User-Data)パラメタ:User-Data 384 バイトまでのデータ

▶11.1.4 Connect Servicesコネクションサービス

IrLAP-CONNECT.要求(Target-Device-Adr, 要求-QOS, Sniff)IrLAP-CONNECT.指示(Source-Device-Adr, Connection-Handle, 通知-QOS)IrLAP-CONNECT.応答(Source-Device-Adr, Connection-Handle, 要求-QOS, accept)IrLAP-CONNECT.確認(Connection-Handle, 返送-QOS, accept)パラメタ:Target-Device-Adr接続先（Responder）の32 ビット装置アドレスSource-Device-Adr接続元（Initiator）の32 ビット装置アドレスConnection-Handle IrLAP の7 ビットコネクションハンドルSniff[true | false]要求-QOS Baud Rate + Max Turn Around Time + Disconnect Threshold+Data Size通知-QOS Baud Rate + Data Size + Disconnect Threshold Accept[true |false] (false の場合はコネクションが確立されていない。)Max-Turn-Around-Time 最大ターンアラウンド時間 （後述する）

Disconnect-Threshold最小ターンアラウンド時間 （後述する）Baud-Rate (bps)[9600 | 19200 | 38400 | 57600 | 115200 | 576000 | 1152000 |4000000 ]Data-Size (bytes)[64 | 128 | 256 | 512 | 1024 | 2048]

▶11.1.5 Sniffing Services

IrLAP-SNIFF.要求(Cancel)パラメタ:Cancel[true | false]

▶11.1.6 Data Services

IrLAP-DATA.要求(Connection-Handle, User-Data, Expedited-Unreliable-Flag)IrLAP-DATA.指示(Connection-Handle, User-Data, Expedited-Unreliable-Flag)パラメタ:Connection-Handle IrLAP の7 ビットコネクションハンドルUser-Dataユーザデータのバイト数はこのコネクションハドルに対して設定されたサービスパラメタ(QOS)のData-Size サービス品質を超えることは出来ない。

Expedited-Unreliable-Flag[true | false]true はデータ転送の信頼性が不要であることを示す

▶11.1.7 Status Services

IrLAP-STATUS.要求(Connection-Handle)IrLAP-STATUS.指示(Connection-Handle, Quality-of-Link)IrLAP-STATUS.確認(Connection-Handle, Unacked-Data-Flag)パラメタ:Connection-Handle IrLAP 7 ビットコネクションハンドルQuality-of-Link[no activity | noisy]Unacked-Data-Flag[true | false]true はIrLAP 層が送るべき未確認データを持っていることを示す。

▶11.1.8 Reset Services

IrLAP-RESET.要求(Connection-Handle)IrLAP-RESET.指示(Connection-Handle)IrLAP-RESET.応答(Connection-Handle, accept)IrLAP-RESET.確認(Connection-Handle, accept)パラメタ:Connection-Handle IrLAP 7 ビットコネクションハンドルaccept[true | false](false なら、リセットを実行しない)

▶11.1.9 Disconnect Services

IrLAP-DISCONNECT.要求(Connection-Handle)IrLAP-DISCONNECT.指示(Connection-Handle)パラメタ:Connection-Handle IrLAP 7 ビットコネクションハンドルUnacked-Data未送信データに関する実装依存情報

▶11.2 IrLMP サービス

▶11.2.1 LM_DiscoveryDevices

LM_DiscoverDevices.要求(nrSlots)
LM_DiscoverDevices.確認(Status, List of(装置アドレス, 装置情報, method ))
LM_DiscoverDevices.指示(装置アドレス, 装置情報, method)

パラメタ:NrSlots IrLAP 発見手順におけるスロット数Status発見手順によるか、過去のデータによるものかを表す。装置アドレス32 ビットのIrLAP 装置アドレスを表す。装置情報サービスヒントを含む装置情報method発見方法を示すスニフィング、能動発見、受動発見

▶11.2.2 LM_Sniff

LM_Sniff.要求(option)
LM_Sniff.確認(status, 装置アドレス)

パラメタ:Optionスニフモード設定／解除Status接続が確立されたか、スニフが以下の理由で拒絶されたa) IrLAP connection がすでに存在する。b) スニフがすでにアクティブである。装置アドレス接続される装置のIrLAP 装置アドレス

▶11.2.3 LM_Connect

LM_Connect.要求(Called LSAP, requested Qos, Client Data)
LM_Connect.指示(Calling LSAP, Resultant Qos, Client Data)
LM_Connect.応答(Calling LSAP, confirmation, Client Data)
LM_Connect.確認(Called LSAP, Resultant Qos, Client Data)

パラメタ:LSAP 1 つのLSAP を識別するID QoSサービス品質パラメータ。変更できるパラメータは、どのパラメータが実際に変更できるかは、インプリメンテーションに依存する。Client Dataサービス・ユーザが接続パケットに入れて送信する最大60 バイトのデータ。標準では署名フィールドとして使用され、接続を受け入れるかどうかを決めるための補助をする。また、トランスポート層の初期化データや、単に少量のデータを転送するために使用する場合もある。

confirmation接続を受け入れるか拒絶するかを示す。QoSサービス品質パラメータ（IrLAP 規格参照）：ボーレート最大・アラウンド・ターンタイム［入力のみ］データサイズ切断スレッショルド

▶11.2.4 LM_Disconnect

LM_Disconnect.要求(Reason, Client Data)
LM_Disconnect.指示(Reason, Client Data)

パラメタ:Reason接続をクローズする（した）理由Client Data最大60 バイトのサービス・ユーザ・データクライアント・データが引き渡されるという保証はない。Reason切断理由

▶11.2.5 LM_Status

LM_Status.要求()
LM_Status.指示(LinkStatus, LockStatus)
LM_Status.確認(UnAcked Data Flag)

パラメタ:LinkStatus Ok、No progress（進行なし）、noisy（ノイズあり）LockStatus NoChange（変化なし）、Locked（ロックされている）、UnLocked（ロックされていない）UnAcked Data Flag True/False（真／偽）肯定応答されていないデータがIrLAP 待ち行列にあるかどうかを示す。

▶11.2.6 LM_Idle

LM_Idle.要求(要求 mode)
LM_Idle.確認(status, Actual mode)

パラメタ:mode Active/Idle（アクティブ／アイドル）status Success/Failure（成功／失敗）

▶11.2.7 LM_AccessMode

LM_AccessMode.要求(要求ed Mode)
LM_AccessMode.指示(Resultant Mode)
LM_AccessMode.確認ation(status, Actual Mode)

パラメタ:Mode要求されたモード／現在のモード（Exclusive/Multiplexed（排他／多重化））Status要求の成功／失敗

▶11.2.8 LM_Data

LM_Data.要求(Data)
LM_Data.指示(Data)

パラメタ:Dataユーザ・データ

▶11.2.9 LM_Udata

LM_UData.要求(Data)
LM_UData.指示(Data)

パラメタ:Dataユーザ・データ

▶11.2.10 LM_ConnectionlessData

LM_ConnectionlessData.要求(Data)
LM_ConnectionlessData.指示(Data)
LM_ConnectionlessData.確認(status, [要求son])

パラメタ:Dataユーザ・データStatus要求の成功／失敗（success/fail）Reason失敗理由（オプション）

▶11.2.11 LM-GetInfoBaseDetails

LM-GetInfoBaseDetails.要求 (address)LM-GetInfoBaseDetails.確認 (number of objects, max.object id)パラメタ：Addressリモート装置の32bit 装置アドレスnumber of objectsリモートデータベースのオブジェクトの数max.object idリモートデータベースの現在のオブジェクトＩＤの最大値

▶11.2.12 LM-GetObjects

LM-GetObjects.要求 (address, first id, max.list, class name)LM-GetObjects.確認 (next id, list of (id, num.attributes, class name))パラメタ：Addressリモート装置の32bit 装置アドレスfirst id返送するリスト内の先頭オブジェクトID max.list返送するリストの最大長class nameクラスの名：（長さが０）の場合はすべてのクラスが検索されるnext idリスト内の最終オブジェクトの次のオブジェクトＩＤidリストの１項目のオブジェクトＩＤnum.attributesこのオブジェクトの属性の数class nameオブジェクトクラス名

▶11.2.13 LM-GetValue

LM-GetValue.要求 (address, id, attribute name1, [attribute name2, ...]LM-GetValue.確認 (List of attribute values)パラメタ：Addressリモート装置の32bit 装置アドレスIdオブジェクトＩＤAttribute name検索する属性名Values属性値

▶11.2.14 LM-GetValueByClass

LM-GetVarueByClass.要求 (address, class name, attribute name)LM-GetVarueByClass.確認 (list of (object id, attribute value))パラメタ：Addressリモート装置の32bit 装置アドレスclass name検索するクラス名Attribute name検索する属性名Value属性値

▶11.2.15 LM-GetObjectInfo

LM-GetObjectInfo.要求 (address, id)LM-GetObjectInfo.確認 (lowest slot, highest slot, num.slot)パラメタ：Addressリモート装置の32bit 装置アドレスId指定するオブジェクトＩＤLowest slot指定オブジェクトの現在の先頭スロットHighest slot指定オブジェクトの現在の最終スロットnum.slot現在使用されているスロットすべての数

▶11.2.16 LM-GetAttributeNames

LM-GetAttributeNames.要求 (address, id, first slot, number of names)LM-GetAttributeNames.確認 (next slot, List of (attribute name, type))パラメタ：Addressリモート装置の32bit 装置アドレスIdオブジェクトＩＤfirst slot属性名として始めに要求するスロットの番号Number of names返送されるの属性名の最大数next slot返送リスト内の最終スロットの次のスロット番号Attribute nameオブジェクトの属性名Type属性の型

▶11.3 TinyTP サービス

▶11.3.1 TTP_Connect

TTP_Connect.要求(Called TTPSAP,Requested QoS,

Calling MaxSduSize, Calling UserData )

TTP_Connect.指示( Calling TTPSAP, Resultant QoS,

Calling MaxSduSize ,Calling UserData)

TTP_Connect.応答( Calling TTPSAP,

Called MaxSduSize,Called UserData )

TTP_Connect.確認( Called TTPSAP,Resultant QoS,

Called MaxSduSize,Called UserData)パラメタ：TTPSAP TinyTP のエンドポイントのサービス・アクセス・ポイントのセレクタである。暗黙的に、IrLMP LM-MUX LSAP.の参照も含んでいる。QoS IrLMP/IrLAP におけるサービス品質（QOS）MaxSduSize上位層が要求する最大のユーザデータサイズのバイト数。要求サイズは、エンドポイントにある相手に通知される。要求サイズは、エンドポイントにおいて独立に要求される。

UserData UserData は、TinyTP 接続パケットにのせる少量のデータであり、接続時に転送される。接続確立の間に転送されるTinyTP 接続-PDU の全サイズは、IrLAP 接続の折衝によって制限される。TinyTP 接続-PDU のパラメータ・フィールドの最大サイズは、6 バイトにである。したがって、接続時に転送できるUserData は、52 バイト以下に制限される。典型的な使用方法はTinyTP クライアントの間のその接続のためのパラメータ交換である。

TTP_Disconnect.要求(UserData)
TTP_Disconnect.指示(Reason, UserData)

パラメタ：Reason切断理由：IrLMP で定義している切断理由をそのまま通知する。UserData切断要求を行った側から通知されるユーザデータ

▶11.3.3 TTP_Data

TTP_Data.要求(UserData)
TTP_Data.指示(UserData,Status)

パラメタ：UserData TTPクライアントの間で交換されるTTPクライアント・サービスデータユニット（SDU）である。SAR がアクティブであるならば、要求プリミティブの中で転送するUserData フィールドのサイズはTTP_Connect.指示またはTTP_Connect.確認プリミティブの中で通知されたMaxSduSize を上回ってはならない。SAR が非アクティブならば、UserData フィールドのサイズは一つのデータTTP-PDU の範囲内で合うことを強制される。

Status転送ステータスは以下の値をとる。OK：（成功）再構成処理がおこなわれていないか、再構成が成功したことを表す。Truncated:（切り詰め）接続時に合意されたサイズを上回るため、SDU を切り詰めたことを表す。

▶11.3.4 TTP_Udata

TTP_UData.要求(UserData)
TTP_UData.指示(UserData)

▶11.3.5 TTP_LocalFlow

TTP_LocalFlow.要求(Flow=on|off)

パラメタ：Flow On: データ転送を有効にする。Off: データ転送を一次休止する。