ホスト・コントローラの準備状態と、バス上に複数のデバイスが存在するという事実に基づき、IBI の生成と調停は、以下に示すようにいくつかのルールに従う必要があります。これらの条件はすべて、バスが t_AVAL 期間にわたって非アクティブであることを前提としています。

1. ホスト・コントローラが IBI ヘッダ付きで書き込みまたは読み取りを開始したとき、TMP139 はバス上で自分自身のアドレスの駆動を開始します。 IBI ヘッダ以外の値を検出したホストは、SDA を駆動しなくなり、TMP139 は R/W ビットを 1 に設定してデバイス・ヘッダを送信できます。
2. ホスト・コントローラがデバイスから IBI を受け入れることができる場合、ホスト・コントローラはデバイス・アドレスに対して ACK 応答し、SCL の立ち下がりエッジでバスを解放し、TMP139 から送信されたバイトを受け入れます。
3. ホスト・コントローラがデバイスから IBI を受け入れることができない場合、ホスト・コントローラはデバイス・アドレスに対して NACK 応答し、バス上でストップ・コンディションを発行します。 TMP139 は、 t_AVAL 期間が経過した後でなければ、別の IBI を再試行できません。
4. TMP139 よりも低いデバイス・アドレスを持つバス上のデバイスに対して、ホスト・コントローラが IBI ヘッダなしで書き込みまたは読み取りを開始した場合、デバイスはミスマッチを検出した時点でバスに参加せず、t_AVAL 期間が経過した後に別の IBI を再試行します。
5. TMP139 よりも高いデバイス・アドレスを持つバス上のデバイスに対して、ホスト・コントローラが IBI ヘッダなしで書き込みまたは読み取りを開始した場合、このデバイスがバスの調停に成功し、ホストはバスに参加しなくなります。 ホストは、ACK を送信して IBI を受け入れるか、または、NACK を送信して IBI を無視します。後者の場合、TMP139 は、t_AVAL 期間が経過した後でなければ、別の IBI を再試行できません。
6. ホスト・コントローラが TMP139 に対して IBI ヘッダなしで書き込みまたは読み取りトランザクションを開始し、TMP139 も IBI を要求している場合、ホストまたは TMP139 のどちらかが調停に成功します。
7. ホスト・コントローラが書き込みトランザクションを開始した場合、ホスト・コントローラがバスの調停に成功し、TMP139 はバスを解放します。 TMP139 は、t_AVAL 期間が経過した後でなければ、別の IBI を再試行できません。
8. ホスト・コントローラが読み取りトランザクションを開始する場合、すべてのビットが一致しています。ただし、この時点で、ホストは読み取り要求に対する TMP139 からの ACK を期待しており、TMP139 は IBIに対するホストからの ACK を待機しています。その結果、バス上で NACK が発生します。 このよう な場合、TMP139 は、t_AVAL 期間が経過した後でなければ、別の IBI を再試行できません。ただし、ホストがスタート (またはリピート・スタート) を発行し、t_AVAL 期間前に読み出しトランザクションを試行した場合、ホストは TMP139 から ACK を受け取り、ホストの読み出しはバス上の調停に成功します。
9. 上記のように、同時に IBI を開始する複数のデバイスが存在する場合、デバイス・アドレスの最も低いデバイスがバスの調停に成功します。 TMP139 がバス調停の失敗を検出した場合、t_AVAL 期間が経過した後でなければ、別の IBI を再試行できません。