UniPro プロトコルスタック
携帯電話技術において、UniProプロトコルスタック[1]は、古典的なOSI参照モデルのアーキテクチャに準拠しています。UniProでは、OSI物理層は2つのサブレイヤー、すなわちレイヤー1（実際の物理層）とレイヤー1.5（PHYアダプタ層）に分割されており、レイヤー1.5は代替レイヤー1技術間の差異を抽象化します。実際の物理層は、様々なPHYオプションが他のMIPIアライアンス仕様[2]で再利用されるため、独立した仕様となっています。
| レイヤー番号 | レイヤー名 | 機能性 | データユニット名 | |
|---|---|---|---|---|
| ロサンゼルス | 応用 | ペイロードとトランザクションのセマンティクス | メッセージ | |
| DME | ||||
| レイヤー4 | 輸送 | ポート、多重化、フロー制御 | セグメント | |
| レイヤー3 | ネットワーク | アドレス指定、ルーティング | パケット | |
| レイヤー2 | データリンク | シングルホップの信頼性と優先度ベースの調停 | フレーム | |
| レイヤー1.5 | PHYアダプタ | 物理層の抽象化とマルチレーンのサポート | ユニプロのシンボル | |
| レイヤー1 | 物理層（PHY） | シグナリング、クロッキング、ラインエンコーディング、電力モード | PHYシンボル | |
UniPro仕様自体は、レイヤー1.5、2、3、4、およびDME（デバイス管理エンティティ）をカバーしています。アプリケーション層（LA）は、UniProの用途によって異なるLAプロトコルが必要となるため、この仕様の対象外です。物理層（L1）は、必要に応じて他の（より汎用性の低い）プロトコルでPHYを再利用できるように、別のMIPI仕様で規定されています。
OSI レイヤー 5 (セッション) と 6 (プレゼンテーション) は、該当する場合、アプリケーション レイヤーの一部としてカウントされます。
物理層（L1）
D-PHY
UniProバージョン1.0および1.1は、オフチップ物理層にMIPIのD-PHYテクノロジーを採用しています。このPHYはチップ間通信を可能にします。D-PHYのデータレートは可変ですが、500～1000Mbpsの範囲です（より低速なデータレートもサポートされていますが、電力効率は低下します）。D-PHYは、ローマ数字の500（D）にちなんで命名されました。
D-PHY [3]は、差動信号を用いてマイクロストリップライン配線上でPHYシンボルを伝送します。2つ目の差動信号ペアは、関連するクロック信号を送信元から送信先へ伝送するために使用されます。したがって、D-PHY技術は、1方向あたり合計2本のクロック線と、1レーンあたり1方向あたり2本の信号線を使用します。例えば、D-PHYは順方向にはクロックに2本の線、データに4本の線（2レーン）を使用しますが、逆方向にはクロックに2本の線、データに6本の線（3レーン）を使用します。プロトコルスタックのこのレベルでは、順方向と逆方向のデータトラフィックは完全に独立しています。
UniProでは、D-PHYは8ビットバイトを9ビットシンボルとして伝送するモード（「8b9b」エンコーディングと呼ばれる）で使用されます。UniProプロトコルは、これを特別な制御シンボル（通常の0～255の値以外）を表すために使用します。PHY自体も、これをPHY自体にとって意味を持つ特定の特殊シンボル（IDLEシンボルなど）を表すために使用します。D-PHYのデータレートを指定する際に、8:9という比率が混乱を招く可能性があることに注意してください。450MHzのクロック 周波数で動作するPHY実装は、多くの場合900MbpsのPHYとして評価されますが、UniProスタックで使用できるのは800Mbpsのみです。
D-PHY は、データを送信する必要がない場合に使用するための低電力データ転送 (LPDT) モードやその他のさまざまな低電力モードもサポートしています。
M-PHY
UniProのバージョン1.4以降は、D-PHYとM-PHY [4]の両方の技術をサポートしています。M-PHY技術はまだドラフト段階ですが、約1000 Mbit/sからの高速データレートをサポートしています（M-PHYはローマ数字の1000にちなんで名付けられました）。M-PHYは高速であることに加え、業界標準の8b10bエンコーディングを使用してクロック信号がデータに埋め込まれるため、信号線が少なくなります。繰り返しになりますが、1000 Mbit/sでユーザーデータを送信できるPHYは、8b10bエンコーディングのため、通常は1250 Mbit/sモードとして指定されます。
| PHYテクノロジー | バージョン / リリース | シンボルエンコーディング | Gbit/s（ペイロード） | 車線 | サポートされている |
|---|---|---|---|---|---|
| D-PHY | 1.2/2014年9月 | 8b/9b | 4.5 ギガビット/秒/レーン | 4レーンポート | |
| M-PHY | 3.1/2014年6月 | 8b/10b | 11.6 ギガビット/秒/レーン | 4+1レーンポート | |
| C-PHY | 1.00.00 / 2014年10月 | ? 2.5Gbit/s/レーン ? | 3レーンポート |
D-PHYとM-PHYは今後数年間共存すると予想されています。D-PHYはよりシンプルな技術であり、M-PHYはより少ない信号線でより広い帯域幅を提供し、C-PHYは低消費電力を実現します。
低速モードと省電力
UniProは、D-PHY（10Mbps）とM-PHY（3Mbps～500Mbps）の両方が提供する、電力効率の高い低速通信モードをサポートしていることは特筆に値します。これらのモードでは、消費電力は送信データ量にほぼ比例します。さらに、どちらのPHY技術もバッテリー駆動デバイスでの使用に最適化されているため、追加の省電力モードも提供しています。
PHYアダプタ層（L1.5）
アーキテクチャ的には、PHYアダプタ層は、異なるPHYオプション（D-PHYとM-PHY）間の差異を隠蔽する役割を果たします。この抽象化により、主にアーキテクチャの柔軟性が向上します。抽象化されたPHYの詳細には、様々な電源状態や採用されているシンボル符号化方式が含まれます。
L1.5シンボル
| 制御 | b15 | b14 | b13 | b12 | b11 | b10 | b09 | b08 | b07 | b06 | b05 | b04 | b03 | b02 | b01 | b00 |
| 1 | L1.5制御シンボルの1バイト目 | L1.5制御シンボルの2番目のバイト | ||||||||||||||
| 0 | L1.5データシンボルの1バイト目 | L1.5データシンボルの2番目のバイト | ||||||||||||||
| 0 | L1.5データシンボルの1バイト目 | L1.5データシンボルの2番目のバイト | ||||||||||||||
| 0 | L1.5データシンボルの1バイト目 | L1.5データシンボルの2番目のバイト | ||||||||||||||
| 0 | L1.5データシンボルの1バイト目 | L1.5データシンボルの2番目のバイト | ||||||||||||||
| 1 | L1.5制御シンボルの1バイト目 | L1.5制御シンボルの2番目のバイト | ||||||||||||||
| 0 | L1.5データシンボルの1バイト目 | L1.5データシンボルの2番目のバイト | ||||||||||||||
したがって、L1.5は17ビットのシンボルで構成される独自の（概念的な）シンボルエンコーディングを持ちます。これらの17ビットのシンボルは、L1.5によってPHYシンボルのペアに変換されるため、回線上に現れることはありません。追加の17番目の制御ビットは、プロトコル（L1.5およびL2）自体で使用される特別な制御シンボルを示します。図では、制御ビットはプロトコルレイヤー1.5で定義され、使用されることを思い出させるために「L1.5 red」で示されています。
L1.5マルチレーンサポート
L1.5がユーザーに提供する主な機能は、単一レーンでは帯域幅が不足する場合に、2、3、または4レーンを使用することでUniProリンクの帯域幅を拡張できることです。ユーザーにとって、このようなマルチレーンリンクは、シンボルが2、3、または4レーンを介して送信されるため、単に物理層が高速化されたように見えます。ある方向に高い帯域幅を必要とし、反対方向にはより低い帯域幅を必要とするアプリケーションでは、方向ごとに異なるレーン数を使用できます。
L1.5 レーン検出
UniPro v1.4以降、L1.5はリンクの各方向で使用可能なM-PHYレーンの数を自動的に検出します。これは、L1.5内部で初期化時に実行されるシンプルな検出プロトコルによって実現されます。このプロトコルは、利用可能な各送信レーンにテストデータを送信し、どのレーンのどのデータが実際にリンクの反対側に到達したかに関する情報をピアエンティティから受信します。このメカニズムはレーンの透過的な再マッピングもサポートしており、回路基板設計者はレーンの物理的な配線方法を柔軟に選択できます。
L1.5リンク電力管理
UniPro v1.4以降、L1.5にはPACP（PA Control Protocol）と呼ばれるプロトコルが組み込まれており、これによりL1.5はM-PHYベースリンクの反対側にあるピアL1.5エンティティと通信できるようになります。PACPの主な用途は、リンクの片側にあるコントローラが、リンクの順方向と逆方向の両方向の電力モードをシンプルかつ確実に変更できるようにすることです。つまり、リンクの片側にあるコントローラは、単一のアトミック操作でリンクの両方向の電力モードを変更できます。これを完全に信頼性の高い方法で実行するために必要な複雑な手順は、L1.5内で透過的に処理されます。
L1.5ピアパラメータ制御
L1.5 リンク電源管理に加えて、PACP はピア UniPro デバイスの制御およびステータス パラメータにアクセスするためにも使用されます。
L1.5保証
L1.5 のメカニズムは、上位層プロトコルに対して次のことを保証します。
- リセット後、各 L1.5 トランスミッタは、接続された L1.5 レシーバがアクティブであると認識されるまで待機します (ハンドシェイクによって処理されます)。
- 複数のレーンを使用する場合、元のシンボル ストリームの順序は保持されます (複数のレーンの使用とこれらのレーンを相互接続する方法の自由にもかかわらず)
- 電力モードの変更は確実に実行されます（ビットエラーがあっても）
データリンク層（L2）
UniPro のデータ リンク層 (L2) の主なタスクは、物理層で時々ビット エラーが発生したり、受信側がデータを十分速く吸収できない場合にリンクが輻輳する可能性があるにもかかわらず、ネットワーク内の 2 つの隣接ノード間で信頼性の高い通信を可能にすることです。
L2データフレーム
L2は、17ビットのUniPro L1.5シンボルをパケットのようなデータフレームにクラスタ化します（パケットという用語はL3用に予約されています）。これらのデータフレームは、17ビットのフレーム開始制御シンボルで始まり、最大288バイトのデータ（144データシンボル）が続き、さらにフレーム終了制御シンボルとチェックサムが続きます。
288バイトのうち2バイト以上は、UniProプロトコルの上位層で使用されることに注意してください。フレームあたりの最大フレームサイズが288ペイロードバイトに設定されたのは、プロトコルスタック全体が単一のチャンクで256バイトのアプリケーションデータを容易に送信できるようにするためです。奇数バイトのペイロードは、フレームを偶数バイトにパディングし、対応するフラグをトレーラーに挿入することでサポートされます。
| 制御 | b15 | b14 | b13 | b12 | b11 | b10 | b09 | b08 | b07 | b06 | b05 | b04 | b03 | b02 | b01 | b00 |
| 1 | データフレームの開始制御シンボル（ヘッダー） | |||||||||||||||
| 0 | フレームペイロード | |||||||||||||||
| 0 | : | |||||||||||||||
| 0 | : | |||||||||||||||
| 0 | フレームペイロード | |||||||||||||||
| 1 | データフレーム終了制御シンボル（トレーラー） | |||||||||||||||
| 0 | 16ビットチェックサム | |||||||||||||||
L2制御フレーム
L2は、ユーザーデータを含むデータフレームに加えて、制御フレームも送受信します。制御フレームは、最初のシンボルの3ビットによってデータフレームと区別できます。制御フレームには2種類あります。
- 1 つのタイプ (「AFC - 確認応答および L2 フロー制御」、3 つのシンボル) は、正常に受信されたデータ フレームを確認するために使用されます。
- もう一方のタイプ (「NAC」、2 つのシンボル) は、不正なフレームが受信されたことを対応する送信機に通知します。
これらの L2 タイプの制御フレームは、L2 によって自律的に送信されることに注意してください。
| 制御 | b15 | b14 | b13 | b12 | b11 | b10 | b09 | b08 | b07 | b06 | b05 | b04 | b03 | b02 | b01 | b00 |
| 1 | 制御フレームの開始制御シンボル（ヘッダー） | |||||||||||||||
| 0 | 制御フレームペイロード（AFCのみ） | |||||||||||||||
| 0 | 16ビットチェックサム | |||||||||||||||
L2再送信
低電力レベルでの高速通信では、受信データに時折エラーが発生する可能性があります。データリンク層には、正しく受信されたデータフレームを自動的に確認応答するプロトコル（AFC制御フレームを使用）と、L2で検出可能なエラーをアクティブに通知するプロトコル（NAC制御フレームを使用）が含まれています。L2エラーの最も可能性の高い原因は、データフレームが電気レベル（ノイズ、EMI）で破損していることです。その結果、受信側でデータまたは制御フレームのチェックサムが不正確になり、自動的に再送信されます。データフレームは確認応答（AFC）または否定応答（NAC）されます。破損した制御フレームは、期待される応答または必要な応答を監視するタイマーによって検出されます。
1 Gbit/sの帯域幅と1 Gbpsの速度におけるビットエラー率が10 -12の場合、1000秒ごとにエラーが発生する、つまり1000 Gbitの送信ごとに1回エラーが発生することを意味します。したがって、レイヤー2はこれらのエラーを自動的に修正しますが、その代償として、帯域幅がわずかに低下し、再送信または「リプレイ」に備えて送信データフレームのコピーを保存するためにレイヤー2に必要なバッファスペースも必要になります。
L2フロー制御
L2のもう一つの特徴は、L2送信側が受信側にデータフレーム用のバッファスペースがあるかどうかを認識できることです。これもまた、L2制御フレーム（AFC）に依存しており、受信側はピアの送信側に利用可能なバッファスペースの量を伝えることができます。これにより、受信側は必要に応じて送信を一時停止し、受信バッファオーバーフローを回避できます。制御フレームはL2フロー制御の影響を受けません。つまり、いつでも送信でき、L2受信側は到着した速度で処理することが期待されます。
L2トラフィッククラスと仲裁
UniProは現在、トラフィッククラス0（TC0）とトラフィッククラス1（TC1）と呼ばれる2つのデータフレーム優先度をサポートしています。TC1はTC0よりも優先度が高いです。つまり、L2トランスミッタがTC0とTC1のデータフレームを混在させて送信する場合、TC1データフレームが最初に送信されます。ほとんどのデータトラフィックがTC0を使用し、ネットワークが混雑していると仮定すると、これによりTC1データフレームがTC0データフレームよりも早く宛先に到着することが保証されます（緊急車両と通常の道路交通に類似）。さらに、L2は送信中のTC0データフレームを中断（プリエンプト）してTC1データフレームを送信することもできます。制御フレームには追加の調停ルールが適用されます。制御フレームはサイズが小さく、トラフィックの流れを維持するために不可欠であるため、基本的にデータフレームよりも高い優先度が与えられます。
マルチホップネットワークでは、各ホップのL2トランスミッタ内で調停が行われます。データに割り当てられたトラフィッククラスは、通常、データがネットワークを通過しても変化しません。優先度システムの使用方法は、アプリケーションが決定します。
L2 単一トラフィッククラスオプション
UniPro バージョン 1.1 では、シンプルなエンドポイントデバイスが、必要に応じて 2 つのトラフィッククラスのうち 1 つだけを実装できるようにするオプションが導入されました。これは、デバイス設計者がフレームアービトレーションの制御よりも実装コストを重視する場合に役立ちます。接続された L2 ピアデバイスは、リンク初期化フェーズでこのようなデバイスを検出し、不足しているトラフィッククラスの使用を回避できます。
L2保証
さまざまな L2 メカニズムは、上位層プロトコルに対してさまざまな保証を提供します。
- 受信したデータフレームには正しいペイロード（チェックサムを使用してチェック）が含まれます
- 送信されたデータフレームはピアの受信者に届く（再送信の可能性あり）
- 受信したデータフレームを収容する余地がある（L2フロー制御）
- データフレームの内容は上位プロトコル層に一度だけ渡されます（重複したデータフレームは破棄されます）
- 同じトラフィッククラスのデータフレームは受信され、上位プロトコル層に渡されます。
このように、個々のリンクは自律的に信頼性の高いデータ転送を提供します。これは、例えば、エンドポイントでエラーを検出し、データが破損または欠落した場合にエンドツーエンドの再送信に依存する、 広く使用されているTCPプロトコルとは異なります。
ネットワーク層（L3）
ネットワーク層は、パケットをネットワーク経由で宛先までルーティングすることを目的としています。マルチホップネットワーク内のスイッチは、このアドレスを使用して、個々のパケットをどの方向にルーティングするかを決定します。これを実現するために、L3は7ビットの宛先アドレスを含むヘッダーをすべてのL2データフレームに追加します。図の例では、これによりデバイス3はデバイス1、2、5だけでなく、デバイス4、6とも通信できるようになります。
UniPro 仕様のバージョン 1.4 では、スイッチの詳細は指定されていませんが、デバイスが将来のネットワーク環境で動作できるようにするために十分な指定がされています。
L3アドレス指定
L3アドレスの役割はインターネット上のパケットにおけるIPアドレスと同じですが、UniProのデバイスIDアドレスはわずか7ビットです。そのため、ネットワークには最大128個のUniProデバイスを接続できます。UniProに関しては、すべてのUniProデバイスが同等に設計されていることに注意してください。PCI ExpressやUSBとは異なり、どのデバイスも他のデバイスと通信を開始できます。そのため、UniProは単一のマスターを持つバスではなく、真のネットワークとなっています。
L3パケット
この図は、L2フレームの最初のL2ペイロードバイトから始まり、L2フレームの最後のL2ペイロードバイトで終わるL3パケットの例を示しています。簡潔性と効率性のため、1つのL2フレームで伝送できるL3パケットは1つだけです。これは、UniProではL2フレーム、L3パケット、L4セグメント（下記参照）の概念が非常に密接に連携しており、ほぼ同義語であることを意味します。ただし、仕様を厳密に階層化して記述できるようにするために、これらの区別（および「色分け」）は依然として行われています。
L3ショートヘッダーパケット構造
UniProショートヘッダーパケットは、L3情報に1つのヘッダーバイトを使用します。このバイトには、7ビットのL3宛先アドレスが含まれます。残りのビットは、ショートヘッダーパケットのフォーマットを示します。ショートヘッダーパケットの場合、L3送信元アドレスはヘッダーに含まれません。これは、通信する2つのデバイスが事前にL3送信元アドレスを交換していることが前提となっているためです（コネクション指向通信）。
| 制御 | b15 | b14 | b13 | b12 | b11 | b10 | b09 | b08 | b07 | b06 | b05 | b04 | b03 | b02 | b01 | b00 |
| 1 | データフレームの開始制御シンボル（ヘッダー） | |||||||||||||||
| 0 | L3ショートヘッダー | パケットペイロード | ||||||||||||||
| 0 | パケットペイロード | |||||||||||||||
| 0 | : | |||||||||||||||
| 0 | パケットペイロード | |||||||||||||||
| 1 | データフレーム終了制御シンボル（トレーラー） | |||||||||||||||
| 0 | 16ビットチェックサム | |||||||||||||||
L3ロングヘッダーパケット
ロングヘッダーパケットはUniPro仕様の将来のバージョンで導入される予定であるため、現在のUniPro v1.4仕様では、そのフォーマットは未定義です（1ビットを除く）。しかし、UniPro v1.4では、UniPro v1.4準拠デバイスがソフトウェアによるアップグレードに対応している場合、ロングヘッダーパケットを受信または送信するためのフックが定義されています。UniPro v1.4の「ロングヘッダートラップ」メカニズムは、受信したL2データフレームのペイロード（ヘッダーとペイロードを含むL3パケット）をL3拡張（例えばソフトウェア）に渡すだけで、処理されます。このメカニズムは、L3拡張からL2フレームのペイロードを受け取って送信することもできます。このメカニズムは、UniPro v1.4デバイスをアップグレードすることで、まだ定義されていないロングヘッダーパケットを必要とするプロトコルをサポートできるようにすることを目的としています。
L3保証
スイッチの詳細はUniPro v1.4仕様の範囲外ですが、L3によりUniPro v1.0/v1.1/v1.4デバイスがネットワーク上のエンドポイントとして機能することが可能になります。そのため、上位層プロトコルに対していくつかの特性が保証されます。
- パケットは指定された宛先デバイスに配信されます（存在しないデバイス宛のパケットは破棄されます）
- L3ソースから単一のL3宛先に、単一のトラフィッククラス内の一連の1つ以上のショートヘッダーパケットとして送信されたペイロードが、正しいペイロードとともに順番に到着すること（信頼性）
トランスポート層（L4）
UniProのトランスポート層の機能は、基本的な通信サービスが既に下位プロトコル層で処理されているため、特に複雑ではありません。L4は本質的に、ネットワーク上の複数のデバイス、あるいはこれらのデバイス内の複数のクライアントが、制御された方法でネットワークを共有できるようにすることを目的としています。L4の機能は、コンピュータネットワーク（TCPやUDPなど）に見られる機能とほぼ同等ですが、PCI Express、USB、オンチップバスなどのローカルバスではあまり見られません。
UniProのL4は、UniPro仕様の最上位プロトコル層であるため、特別な意味を持ちます。アプリケーションは、UniProとやり取りするためにL4の最上位インターフェースを使用する必要があり、L4をバイパスして下位層に直接アクセスすることは想定されていません。データの送受信用に提供されるL4の最上位インターフェースは、動作レベルまたは機能レベルで定義されていることに注意してください。この高い抽象化レベルにより、実装オプションの制限を回避できます。そのため、仕様には非規範的な例として信号レベルのインターフェースを含む付録が含まれていますが、UniPro実装では、最上位インターフェースに特定のハードウェア信号セットやソフトウェア関数呼び出しを含める必要はありません。
L4機能
UniProのトランスポート層は、UniProデバイス内で追加のアドレス指定レベルを提供するものと考えられます。これは
- UniPro デバイスが複数の論理データ ストリームを使用して別の UniPro デバイスと通信できるようにします (例: オーディオ、ビデオ、制御情報を個別に送信する)。
- 複数の論理データ ストリームを使用して、UniPro デバイスが複数の他のデバイスに同時に接続できるようになります (これには、UniPro の将来のバージョンでサポートされるスイッチが必要です)。
- ネットワークの輻輳のリスクを軽減するメカニズムを提供します。
- バイト ストリームをメッセージ ストリームとして構造化するメカニズムを提供します。
これらの点については以下でさらに詳しく説明します。
L4セグメント
L4セグメントは、本質的にはL3パケットのペイロードです。L4ヘッダーは、短縮形では1バイトのみで構成されます。短縮L4ヘッダーのメインフィールドは、5ビットの「CPort」識別子です。これはUniProデバイス内のサブアドレスとみなされ、TCPまたはUDPで使用されるポート番号に類似しています。したがって、すべてのセグメント（短縮ヘッダー付き）は、特定のUniProデバイスの特定のCPortにアドレス指定されます。
| 制御 | b15 | b14 | b13 | b12 | b11 | b10 | b09 | b08 | b07 | b06 | b05 | b04 | b03 | b02 | b01 | b00 |
| 1 | データフレームの開始制御シンボル（ヘッダー） | |||||||||||||||
| 0 | L3ショートヘッダー | L4ショートヘッダー | ||||||||||||||
| 0 | セグメントペイロード | |||||||||||||||
| 0 | : | |||||||||||||||
| 0 | セグメントペイロード | |||||||||||||||
| 1 | データフレーム終了制御シンボル（トレーラー） | |||||||||||||||
| 0 | 16ビットチェックサム | |||||||||||||||
セグメントヘッダー内の1ビットにより、長いセグメントヘッダーを持つセグメントを定義することもできます。UniPro v1.4では、このようなセグメント形式の構造は定義されていません（この1ビットを除く）。長いヘッダーセグメントは、L3セクションで説明されているロングヘッダートラップによって生成されます。
L4接続
UniProでは、相互に通信する2つのCPortを「接続」（CPortの「C」はここから来ています）と呼びます。接続の設定とは、1つのCPortが初期化され、特定のL2トラフィッククラスを使用して、特定のL3デバイスIDの特定のL4 CPortを宛先とするセグメントを作成することを意味します。UniProの接続は双方向であるため、宛先CPortも送信元CPortにデータを送信できるように設定されます。
UniPro 1.0/1.1 では、接続設定は実装によって異なります。
UniPro v1.4では、接続設定は比較的静的であると想定されています。ペアリングされたCPortのパラメータは、DMEを使用してローカルデバイスとピアデバイスの対応する接続属性を設定することで設定されます。これは、UniProの将来のバージョンで動的な接続管理プロトコルによって補完される予定です。
L4フロー制御
CPortsには、ピアまたは接続されたCPortのバッファ容量を追跡するために使用できる状態変数も含まれています。これは、CPortがデータを保持するのに十分なバッファ容量を持たないCPortにセグメントを送信し、データトラフィックが停滞する状況を防ぐために使用されます。このトラフィック渋滞は、迅速に解決されなければ、送信先で急速に拡大し、ネットワーク全体の渋滞を引き起こします。これは、すべてのユーザーのネットワークパフォーマンスに大きな影響を与える可能性があり、最悪の場合、デッドロック状態につながる可能性があるため、非常に望ましくありません。ここで説明するL4メカニズムは、接続のエンドポイントに関係するため、エンドツーエンドフロー制御（E2E FC）と呼ばれています。
L4フロー制御とL2フロー制御
L4フロー制御はL2フロー制御を補完するものです。どちらも、受信側に十分なバッファスペースがあることを確認するまで送信側を一時停止させることで動作します。しかし、L4フロー制御は2つのCPort（複数ホップ離れている場合もある）間で動作し、接続を相互に分離することを目的としています（「仮想ワイヤ」のアナロジー）。一方、L2フロー制御はホップごとに動作し、受信側のバッファスペース不足によるデータ損失を基本的に回避します。
L4フロー制御の適用性
E2E FCはコネクション指向通信でのみ利用可能ですが、現時点ではUniProのL4は代替オプションをサポートしていません。E2E FCはデフォルトで有効になっていますが、無効にすることも可能です。ただし、通常は無効にすることは推奨されません。
L4セーフティネット
UniProは、CPortがストールすることなく、送信されたすべてのデータを吸収することを保証する「セーフティネット」メカニズムを提供します。ストールが検出された場合、エンドポイントはネットワーク上のデータフローを維持するために、そのCPortに到着した受信データを破棄します。これは、システムレベルでのグレースフルデグラデーションの一種と見なすことができます。つまり、ネットワーク上の1つの接続が受信データの速度に追いつけない場合でも、他のデバイスや他の接続は影響を受けません。
L4とメッセージ
UniPro L4は、2つのCPort間の接続において、単一のバイトストリームではなく、いわゆるメッセージ（それぞれが一連のバイトで構成される）のストリームを伝送することを可能にします。メッセージの境界は、UniProを使用するアプリケーションレベルプロトコルによってトリガーされ、セグメントヘッダー内のビットによって通知されます。このメッセージ終了ビットは、L4セグメントの最後のバイトがアプリケーションレベルメッセージの最後のバイトであることを示します。
UniProは、バイトストリームのどこに、いつメッセージ境界を挿入するかをアプリケーションから指示する必要があります。これらの境界はUniPro自体には特別な意味はなく、UniPro上に上位層プロトコルを構築するためのサービスとして提供されます。メッセージは、データ単位が完了し、処理可能であることをアプリケーションに通知するために使用できます（割り込みなどを介して）。また、メッセージは、一部のアプリケーションにおいて再同期ポイントを実装するための堅牢かつ効率的なメカニズムとしても役立ちます。
UniPro v1.4では、メッセージフラグメントの概念が導入されました。フラグメントとは、アプリケーションとCPort間でやり取りされるメッセージの一部です。このオプションは、UniProスタックからの情報（受信メッセージやバックプレッシャーなど）に基づいてメッセージ生成を中断する必要がある、UniPro上のアプリケーションを指定する際に役立ちます。
L4保証
L4 のメカニズムは、上位層プロトコルに対していくつかの保証を提供します。
- CPort は、リンクまたはネットワークがデータを配信できる速度で常にデータを受け入れ続けるという意味で、停止することはできません。
- 接続の CPort にバインドされたアプリケーションが停止し、データの吸収に（短時間または長時間）失敗しても、同じデバイスまたは異なるデバイスへの他の接続は影響を受けません。
- ある CPort から別の CPort に送信されたデータ ストリームは、CPort が着信データ ストリームに対応できる場合、常にそのままの状態で、順序どおりに、正しいメッセージ境界情報とともに到着します。
- CPort が受信データ ストリームに対応できない場合、1 つ以上のメッセージが破損する可能性があり (データの欠落により)、このエラー状態が受信側に通知されます。
- アプリケーションレベルプロトコルが、送信したL4メッセージ（例えば、質問やコマンド）に対するピアからの応答（例えば、回答や確認応答）を待つことは安全です。しかし、アプリケーションレベルプロトコルが、送信した部分的なメッセージに対するピアからの応答を待つことは安全ではありません。
- 受信したショートヘッダーパケット／セグメントの内容は常に正確です。ロングヘッダートラップインターフェースでの配信は保証されませんが、将来のプロトコル拡張により、このようなパケットの配信の信頼性が向上する予定です。このプロトコル拡張は、ロングヘッダートラップ上にソフトウェアで実装できます。
デバイス管理エンティティ (DME)
DME（デバイス管理エンティティ）は、UniProスタックの各レイヤーを制御します。すべてのレイヤーの制御パラメータとステータスパラメータへのアクセスを提供し、リンクの電源モード遷移を管理し、スタックの起動、休止状態、リセットを制御します。さらに、リンク上のピアUniProスタックを制御する手段も提供します。
参考文献
- ^ MIPI Alliance 統一プロトコル仕様 (UniProSM) v1.10.01 Archived 2011-10-07 at the Wayback Machine、MIPIウェブサイトのアカウントが必要
- ^ MIPI仕様の概要、D-PHYはDSI、CSI、UniPro仕様で使用され、M-PHYはUniPro、DigRFv4、LLI仕様で使用されます
- ^ MIPI Alliance D-PHY仕様 v1.00.00 2011年7月27日アーカイブWayback Machine、MIPIウェブサイトのアカウントが必要
- ^ MIPI M-PHY仕様バージョン1.00.00、2011年10月7日にWayback Machineにアーカイブ、MIPIウェブサイトのアカウントが必要
