前言

iAP2協(xié)議，是蘋果MFi技術(shù)中的一種，是一個(gè)非常完整、經(jīng)典的通訊協(xié)議。兩個(gè)設(shè)備互相使用數(shù)據(jù)包來通信，考慮到了通訊的完整性、正確性和效率。

作為數(shù)據(jù)包通信學(xué)習(xí)，是一個(gè)非常好的案例。

正文

配件可以使用iAP2協(xié)議來訪問高級設(shè)備功能。其中一項(xiàng)功能是通過iOS外部附件框架與第三方iOS應(yīng)用程序進(jìn)行安全通信的能力。

iOS External Accessory Framework:

About External Accessories

在Accessory Interface Specification R39.pdf中，第57章，是關(guān)于iAP2的協(xié)議描述。

iAP2

iAP2是iAP1的完全替代者，不向后兼容(backward compatible)。

iAP縮寫表示的是Interface Accessory Protocol.

57.1 iAP2 Connection

一個(gè)iAP2連接是由一個(gè)iAP2傳輸通道(iAP2 Link)和一個(gè)或多個(gè)iAP2會話組成。

57.2 iAP Link

每一個(gè)iAP2連接都是從附件和設(shè)備之間通過支持的傳輸建立一個(gè)通道開始的。鏈接協(xié)議提供了一個(gè)與傳輸無關(guān)的機(jī)制，用于可靠和有序地發(fā)布屬于一個(gè)或多個(gè)iAP2會話的數(shù)據(jù)包。該協(xié)議也可基于每個(gè)連接進(jìn)行配置，并可在任何特定的傳輸方式或附件使用情況下進(jìn)行優(yōu)化以獲得最佳性能。這些協(xié)議的功能是為了實(shí)現(xiàn)以下這些目標(biāo)：

• 對收到的數(shù)據(jù)包進(jìn)行ACK確認(rèn)。

• 重傳只需要重新發(fā)送序列中未被確認(rèn)的數(shù)據(jù)包。

• 對iAP2會話的明確和有效支持。

支持iAP2的傳輸方式：

• Bluetooth

• UART

• USB Device Mode

• USB Host Mode

• Apple Lightning Audio

支持上面這些傳輸方式的設(shè)備，都可以和配件建立iAP2的連接。一些傳輸方式對不同的功能會更加合適，所以在配件設(shè)計(jì)過程中，選擇合適的傳輸方式是最優(yōu)先的事。

57.2.1 Packet Structure

每個(gè)通信數(shù)據(jù)包應(yīng)以一個(gè)固定大小的9字節(jié)的頭開始，包括校驗(yàn)和。頭后面數(shù)據(jù)是一個(gè)可選的可變長度的數(shù)據(jù)有效載荷。頭部和有效載荷都有各自的校驗(yàn)和。如果沒有有效載荷數(shù)據(jù)，就沒有有效載荷校驗(yàn)和。

Table 57-1 iAP2 Link Packet Structure

Start of Packet MSB (0xFF)

Start of Packet LSB (0x5A)

Packet Length MSB

Packet Length LSB

Control Byte

Packet Sequence Number

Packet Acknowledgement Number

Session Identifier

Header Checksum

…

Payload Data

…

Payload Checksum

57.2.1.1 Start of Packet

每個(gè)iAP2鏈接數(shù)據(jù)包的前兩個(gè)字節(jié)總是FF 5A。如果在傳輸流中檢測到這些字節(jié)，那么配件和設(shè)備都應(yīng)嘗試將后面的字節(jié)解析為有效的數(shù)據(jù)包。

57.2.1.2 Packet Length

接下來的兩個(gè)字節(jié)表示以字節(jié)為單位的數(shù)據(jù)包長度，并且總是以無符號的16位大端整數(shù)表示。一個(gè)沒有有效載荷數(shù)據(jù)的鏈接數(shù)據(jù)包的長度固定是9字節(jié)（從數(shù)據(jù)包的開始到頭校驗(yàn)和）。否則，數(shù)據(jù)包長度是從數(shù)據(jù)包開始到最后一個(gè)字節(jié)的有效載荷數(shù)據(jù)，包括有效載荷校驗(yàn)和。例如，一個(gè)有1個(gè)字節(jié)的有效載荷數(shù)據(jù)的鏈接數(shù)據(jù)包，其數(shù)據(jù)包長度為11字節(jié)。數(shù)據(jù)包的最大有效載荷數(shù)據(jù)大小為65525字節(jié)；具有這種有效載荷的數(shù)據(jù)包的包長為65535字節(jié)。

57.2.1.3 Control Byte

控制字節(jié)中的位表明數(shù)據(jù)包中存在的內(nèi)容。

• SYN, EAK, 和 RST 位是相互排斥的。

• ACK位可與SYN位結(jié)合。

• EAK位總是與ACK位一起設(shè)置。

• RST位從不與任何其他位一起設(shè)置。

• SLP位從不與任何其他位一起設(shè)置。

• 所有未分配的位應(yīng)被設(shè)置為0。

當(dāng)SYN、EAK或RST的任何位被設(shè)置時(shí)，iAP2會話有效載荷不能出現(xiàn)。反之，帶有iAP2會話有效載荷的鏈接數(shù)據(jù)包總是設(shè)置ACK位。

Table 57-2 iAP2 Link Control Byte Bits

Bit

Name

Meaning

7

SYN

Link Synchronization Payload is present

6

ACK

Packet Acknowledgement Number is valid, and iAP2 Session Payload may be present

5

EAK

Extended Acknowledgement Payload is present

4

RST

Link Reset

3

SLP

Device Sleep

下面的內(nèi)容將會使用這些描述表示帶有某種control byte的link packet。

57.2.1.4 Packet Sequence Number

每個(gè)鏈接數(shù)據(jù)包都包含一個(gè)數(shù)據(jù)包序列號，用來唯一識別傳輸中的該數(shù)據(jù)包。當(dāng)首次創(chuàng)建鏈路時(shí)，設(shè)備和附件都應(yīng)在發(fā)送其第一個(gè)SYN/SYN+ACK包之前隨機(jī)選擇一個(gè)初始序列號。每次發(fā)送帶有iAP2會話或鏈路同步有效載荷數(shù)據(jù)的數(shù)據(jù)包時(shí)，序列號都會增加1，否則，在發(fā)送數(shù)據(jù)包時(shí)序列號不會增加。以前發(fā)送的數(shù)據(jù)包的重新傳輸應(yīng)保留相同的數(shù)據(jù)包序列號。序列號在達(dá)到255時(shí)包回0。The sequence number wraps back to 0 upon reaching 255.

注：設(shè)備和配件應(yīng)該各自使用自己的包序列號。

57.2.1.5 Packet Acknowledgement Number

只有當(dāng)控制字節(jié)中的ACK位被設(shè)置時(shí)，數(shù)據(jù)包確認(rèn)號碼才有意義。如果沒有設(shè)置ACK，則發(fā)送方應(yīng)將數(shù)據(jù)包確認(rèn)號設(shè)置為0，而接收方應(yīng)將其忽略。

如果設(shè)置了ACK，此數(shù)據(jù)包是接收方向發(fā)送方回復(fù)一個(gè)數(shù)據(jù)包用來確認(rèn)，里面包含的數(shù)據(jù)包確認(rèn)號表示的是收到的上一個(gè)按順序接受的數(shù)據(jù)包號碼。例如，如果配件收到的數(shù)據(jù)包序列號是1、2、3和5，那么配件發(fā)送的下一個(gè)數(shù)據(jù)包里的數(shù)據(jù)包確認(rèn)號將是3，因?yàn)?是不按順序收到的。

57.2.1.6 Session Identifier

會話標(biāo)識符只有在控制字節(jié)中的ACK位被設(shè)置且存在iAP2會話有效載荷時(shí)才有意義。如果滿足這兩個(gè)條件，會話標(biāo)識符將是一個(gè)非零數(shù)字，指定iAP2連接中的一個(gè)特定會話。否則，會話標(biāo)識符應(yīng)被設(shè)置為0。

57.2.1.7 Header Checksum

頭部校驗(yàn)和的計(jì)算方法是將以下所有數(shù)據(jù)包的字節(jié)相加。如果報(bào)頭校驗(yàn)和的值與根據(jù)校驗(yàn)和計(jì)算的值不一致，接收方應(yīng)從下一個(gè)檢測到的數(shù)據(jù)包開始序列重新開始數(shù)據(jù)包解析工作。

· Start of Packet MSB

· Start of Packet LSB

· Packet Length MSB

· Packet Length LSB

· Control Byte

· Packet Sequence Number

· Packet Acknowledgement Number

· Session Identifier

57.2.1.8 Payload Data

這一部分是可選的，它的存在應(yīng)與控制字節(jié)中的位的狀態(tài)相匹配。可能的最大有效載荷大小為65,525字節(jié)。

57.2.1.9 Payload Checksum

當(dāng)且僅當(dāng)有效載荷數(shù)據(jù)存在時(shí)，有效載荷校驗(yàn)字節(jié)才會出現(xiàn)。如果存在有效載荷數(shù)據(jù)，則對有效載荷數(shù)據(jù)的所有字節(jié)進(jìn)行校驗(yàn)。如果有效載荷校驗(yàn)和中的值與根據(jù)校驗(yàn)和計(jì)算的值不一致，接收方應(yīng)從下一個(gè)檢測到的數(shù)據(jù)包開始序列重新開始數(shù)據(jù)包解析。

57.2.1.10 Checksum Calculation

iAP2使用的校驗(yàn)和字節(jié)是為每個(gè)發(fā)送的數(shù)據(jù)包計(jì)算的。其目的是讓所有被校驗(yàn)的（無符號8位）字節(jié)和校驗(yàn)（無符號8位）字節(jié)的總和，忽略任何無符號8位溢出，等于0x00。這允許一個(gè)快速的方法來驗(yàn)證數(shù)據(jù)包的正確傳輸。校驗(yàn)字節(jié)的計(jì)算方法是：取被校驗(yàn)的（無符號8位）字節(jié)之和的最小有效字節(jié)，然后取補(bǔ)碼。

下面是代碼示例：

uint8_t

checksum_calculation(uint8_t *buffer, uint16_t start, uint16_t length)

{
uint16_t i;

uint8_t sum = 0;for (i = start; i < (start + length); i++) {sum += buffer[i];}return (uint8_t)(0x100 - sum); /* 2's complement */

}

57.2.2 Link Synchronization Payload

關(guān)于包頭后面的負(fù)載數(shù)據(jù)：鏈路同步有效載荷（Link Synchronization Payload / LSP）用于建立鏈路，并在設(shè)備和接入點(diǎn)之間同步包序號。它還包含可協(xié)商的鏈接參數(shù)。

Table 57-3 Link Synchronization Payload (Version 1)

Link Version (0x01)

Maximum Number of Outstanding Packets

Maximum Received Packet Length MSB

Maximum Received Packet Length LSB

Retransmission Timeout MSB

Retransmission Timeout LSB

Cumulative Acknowledgement Timeout MSB

Cumulative Acknowledgement Timeout LSB

Maximum Number of Retransmissions

Maximum Cumulative Acknowledgements

iAP2 Session 1: Session Identifier

iAP2 Session 1: Session Type

iAP2 Session 1: Session Version

…

iAP2 Session N: Session Identifier

iAP2 Session N: Session Type

iAP2 Session N: Session Version

57.2.2.1 Link Version

• 正在建立的鏈接的版本。所有數(shù)據(jù)包的有效載荷都可能根據(jù)鏈路版本的不同而不同。

• 目前鏈路版本的唯一有效值是1。

• 這是一個(gè)可協(xié)商的參數(shù)。

• 附件和設(shè)備都應(yīng)同意相同的值。

57.2.2.2 Maximum Number of Outstanding Packets

• 在沒有收到對方ACK的情況下，可以發(fā)送的未決數(shù)據(jù)包的最大數(shù)目

• 有效值為1到127。

• 這不是一個(gè)可協(xié)商的參數(shù)。

• 配件和設(shè)備可以提出并使用不同的值。

• 在不等待設(shè)備確認(rèn)的情況下，配件發(fā)送的數(shù)據(jù)包數(shù)量不得超過設(shè)備建議的最大未決數(shù)據(jù)包數(shù)量，反之亦然。

57.2.2.3 Maximum Received Packet Length

• 以字節(jié)為單位的可以接手的最大可能的包長。

• 有效值為24至65535。

• 這不是一個(gè)可協(xié)商的參數(shù)。

• 配件和設(shè)備可以提出并使用不同的值。

57.2.2.4 Retransmission Timeout

• 沒有收到ACK時(shí)重發(fā)一個(gè)包的超時(shí)時(shí)間，單位為毫秒。這應(yīng)該被設(shè)置為一個(gè)與數(shù)據(jù)包在鏈路傳輸上的傳輸時(shí)間相近的值。

• 有效值為20毫秒至65535毫秒。

• 這是一個(gè)可協(xié)商的參數(shù)。

• 配件和設(shè)備都應(yīng)同意相同的值。

57.2.2.5 Cumulative Acknowledgement Timeout

• 以毫秒為單位的超時(shí)值，當(dāng)不在接受到新的數(shù)據(jù)包時(shí)，要發(fā)送ACK數(shù)據(jù)確認(rèn)包。

• 有效值為10毫秒至等待重傳超時(shí)時(shí)間的一半。

• 這是一個(gè)可協(xié)商的參數(shù)。

• 配件和設(shè)備都應(yīng)同意相同的值。

57.2.2.6 Maximum Number of Retransmissions

• 在鏈路被認(rèn)為是斷開之前嘗試的最大數(shù)據(jù)包重傳數(shù)量。

• 有效值為1到30。

• 這是一個(gè)可協(xié)商的參數(shù)。

• 配件和設(shè)備都應(yīng)同意相同的值。

57.2.2.7 Maximum Cumulative Acknowledgements

• 當(dāng)按序列接收到的最大數(shù)量的數(shù)據(jù)包時(shí)，就要發(fā)送ACK確認(rèn)數(shù)據(jù)包。

• 有效值為0-127或最大未處理數(shù)據(jù)包數(shù)量，以較小者為準(zhǔn)。

• 這是一個(gè)可協(xié)商的參數(shù)。

• 配件和設(shè)備都應(yīng)同意相同的值。

57.2.2.8 ZeroACK/ZeroRetransmit Link Configurations

從iOS 8.3開始，配件可以選擇協(xié)商一個(gè)ZeroACK/ZeroRetransmit鏈路配置，而不期待重傳的數(shù)據(jù)包或數(shù)據(jù)包確認(rèn)。建議使用的條件是，底層傳輸有自己的可靠傳輸機(jī)制，并且配件可以完全利用這些機(jī)制。這種類型的iAP2連接方式，可用的傳輸層是USB主機(jī)模式、USB設(shè)備模式和藍(lán)牙RFCOMM傳輸。

設(shè)備仍將使用數(shù)據(jù)包序列號檢測掉落的鏈接數(shù)據(jù)包并重置iAP2鏈接。

如果在典型的使用過程中經(jīng)常發(fā)生丟包，附件不應(yīng)使用這種鏈路配置，并應(yīng)準(zhǔn)備在復(fù)位發(fā)生時(shí)重新建立鏈路，而不丟失狀態(tài)或影響用戶功能。

• 當(dāng)設(shè)備檢測到丟包時(shí)，將向附件發(fā)送RST，鏈路層協(xié)商將以附件的SYN包重新開始。

• 當(dāng)附件使用數(shù)據(jù)包序列號檢測到一個(gè)丟棄的數(shù)據(jù)包時(shí)，附件應(yīng)發(fā)送一個(gè)SYN數(shù)據(jù)包以重新啟動鏈路協(xié)商

為了協(xié)商零應(yīng)答/零重傳的鏈路配置，以下可協(xié)商的鏈路參數(shù)應(yīng)設(shè)置為0：

• 重傳超時(shí)

• 累計(jì)確認(rèn)超時(shí)

• 最大重傳次數(shù)

• 最大累計(jì)確認(rèn)次數(shù)

一些設(shè)備和/或iOS版本可能會拒絕協(xié)商零ACK/零重傳鏈接配置的嘗試。如果配件聲稱與這些設(shè)備/iOS版本兼容，則應(yīng)保留協(xié)商帶有確認(rèn)和重傳的鏈接的能力。配件應(yīng)發(fā)送一個(gè)SYN數(shù)據(jù)包，而不是SYN+ACK，來更新參數(shù)以繼續(xù)協(xié)商。

配件應(yīng)通過管理其iAP2會話的通訊，來解決在鏈路層缺乏流量控制(flow control)的情況。例如，在開始文件傳輸前，應(yīng)通過發(fā)送StopMediaLibraryUpdate來暫停MediaLibraryUpdate消息，并在適當(dāng)時(shí)恢復(fù)其他活動。同樣的注意事項(xiàng)也適用于外部配件協(xié)議消息。

Accessories shall account for the lack of flow control at the link layer by managing their iAP2 session traffic.

57.2.2.9 iAP2 Sessions

• 配件將使用iAP2會話與設(shè)備進(jìn)行通信。

• 會話標(biāo)識符對每個(gè)定義的會話都是唯一的。0不是一個(gè)有效的會話標(biāo)識符。

• 會話類型和版本應(yīng)是有效的。

• 這是一個(gè)可協(xié)商的參數(shù)。

• 配件和設(shè)備都應(yīng)同意相同的值。

57.2.3 iAP2 Session Payload

iAP2會話有效載荷在后面有專門說明。只要存在iAP2會話有效載荷，控制字節(jié)中的ACK位應(yīng)被設(shè)置。

57.2.4 Extended Acknowledgement Payload

Extended Acknowledgement Payload用于確認(rèn)不按順序收到的數(shù)據(jù)包。

該有效載荷具有以下屬性：

• 控制字節(jié)中的EAK和ACK位都應(yīng)被設(shè)置。

• 數(shù)據(jù)包確認(rèn)號包含依次收到的最后一個(gè)數(shù)據(jù)包的序列號。

• 有效載荷數(shù)據(jù)部分包含一個(gè)或多個(gè)不按順序收到的數(shù)據(jù)包的序列號。它們不是這些數(shù)據(jù)包的確認(rèn)。確認(rèn)將在以后的數(shù)據(jù)包中單獨(dú)發(fā)送，并在ACK字段中標(biāo)明適當(dāng)?shù)奶柎a。

Table 57-4 EAK Packet Payload (Link v1)

1st Out of Sequence Acknowledgement Number

…

Nth Out of Sequence Acknowledgement Number

57.2.5 Reset

控制字節(jié)中的RST位被設(shè)備用來重置一個(gè)連接。這種鏈接數(shù)據(jù)包沒有有效載荷，只能由設(shè)備發(fā)送。

57.2.6 Sleep

本節(jié)僅適用于集成以下Lightning連接器的配件：

· Lightning (C78-USBH)

· Lightning (C79-USBH)

· Lightning (C79-UART)

· Lightning (C79-LA)

· Lightning (C78-STROBE-USBH)

· Lightning (C78-STROBE-UART)

· Lightning (C78-STROBE-LA)

控制字節(jié)中的SLP位被設(shè)備用來表示它即將進(jìn)入睡眠狀態(tài)。這種鏈接數(shù)據(jù)包沒有有效載荷，只能由設(shè)備發(fā)送。

一旦進(jìn)入睡眠狀態(tài)，設(shè)備將停止供應(yīng)附屬電源。如果設(shè)備退出睡眠狀態(tài)，它將再次開始供應(yīng)配件電源。

如果配件能夠暫停和恢復(fù)鏈路層，配件應(yīng)在附件電源恢復(fù)后等待500毫秒，然后重新初始化鏈路。在這段時(shí)間內(nèi)，配件可能會收到來自設(shè)備的ACK信號，該信號是鏈路層恢復(fù)的信號，并用于同步序列號（設(shè)備發(fā)出的最后一個(gè)包的序列號）和ACK號（設(shè)備收到的最后一個(gè)包的序號）。

如果配件不能暫停和恢復(fù)鏈路層，在重新初始化鏈路前，配件應(yīng)在電源恢復(fù)后等待80毫秒。

57.2.7 Operation

57.2.7.1 Record

所有鏈接的實(shí)施都應(yīng)在鏈接的特定記錄中存儲以下變量。這些變量將在描述iAP2鏈接操作的后續(xù)章節(jié)中被提及。

Table 57-5 iAP2 Link Operation Record Variables

Variable

Description

SentACKTimer

A timer keeping track of the elapsed time (ms) since the last ACK packet was sent

NextSentPSN

The Packet Sequence Number of the next packet to be sent

OldestSentUnacknowledgedPSN

The Packet Sequence Number of the oldest unacknowledged packet

InitialSentPSN

The Packet Sequence Number used for the very first packet sent

LastReceivedInSequencePSN

The Packet Sequence Number of the last packet received correctly and in sequence

InitialReceivedPSN

The Packet Sequence Number of the very first packet received

ReceivedOutOfSequencePSNs[n]

An array of Packet Sequence Numbers received and acknowledged out of sequence

57.2.7.2 Initialization

一旦傳輸連接已經(jīng)建立，配件應(yīng)確認(rèn)設(shè)備是否支持iAP2，以1赫茲（每秒一次）發(fā)送以下字節(jié)序列，直到收到設(shè)備的響應(yīng)：

FF 55 02 00 EE 10.

如果設(shè)備支持iAP2, 配件會受到同樣的字節(jié)序列。

如果設(shè)備只支持iAP1，配件會收到下面的某個(gè)數(shù)據(jù)序列：

55 04 00 02 04 EE 08

55 02 00 00 FE

FF 55 04 00 02 04 EE 08

FF 55 02 00 00 FE

如果配件收到上面的數(shù)據(jù)序列之一，需要發(fā)送下面的字節(jié)序列給設(shè)備，來表示不兼容：

FF 55 0E 00 13 FF FF FF FF FF FF FF FF FF FF FF FF EB

配件應(yīng)將設(shè)備返回的應(yīng)答作為最終應(yīng)答，不允許重傳或重試。

57.2.7.3 Synchronization

該鏈接的一個(gè)顯著特點(diǎn)是支持在任何類型的傳輸上自動協(xié)商傳輸參數(shù)。這允許鏈接根據(jù)設(shè)備和配件的能力進(jìn)行擴(kuò)展。鏈接初始化有3個(gè)主要目的：

• 確定設(shè)備和配件雙方都能接受的鏈路配置參數(shù)。

• 搜索配置參數(shù)中的錯(cuò)誤。

• 如果不能達(dá)成協(xié)議，就終止鏈接。

當(dāng)?shù)讓觽鬏斶B接已建立，iAP協(xié)議也兼容時(shí)，就會啟動一個(gè)鏈接。這時(shí)，配件先發(fā)送一個(gè)SYN數(shù)據(jù)包，里面的鏈接同步數(shù)據(jù)負(fù)載包含了鏈接所需的參數(shù)，以及隨機(jī)生成的數(shù)據(jù)包序列號。設(shè)備將以SYN+ACK數(shù)據(jù)包回應(yīng)，確認(rèn)收到附件的SYN數(shù)據(jù)包、它自己想要的連接參數(shù)和它隨機(jī)產(chǎn)生的數(shù)據(jù)包序列號。

如果設(shè)備和配件對所有可協(xié)商的連接參數(shù)提出了相同的值，附件應(yīng)發(fā)送一個(gè)來自設(shè)備的最新SYN+ACK的最終ACK包，并且連接被認(rèn)為已經(jīng)建立。否則，SYN+ACK包將繼續(xù)交換，最多10次，直到所有可協(xié)商的連接參數(shù)都達(dá)成一致。如果發(fā)生10次交換而沒有就可協(xié)商的連接參數(shù)達(dá)成協(xié)議，設(shè)備將停止響應(yīng)配件發(fā)送的任何進(jìn)一步的數(shù)據(jù)包。

有時(shí)，設(shè)備將無法立即響應(yīng)從配件收到的SYN數(shù)據(jù)包。配件可以用相同的有效負(fù)載數(shù)據(jù)和相同的數(shù)據(jù)包序列號重新發(fā)送SYN數(shù)據(jù)包。附件可以每秒繼續(xù)這樣做，直到設(shè)備發(fā)送SYN+ACK響應(yīng)，確認(rèn)先前發(fā)送的數(shù)據(jù)包序列號。一旦收到設(shè)備的響應(yīng)，附件應(yīng)忽略任何隨后進(jìn)入的具有相同數(shù)據(jù)包序列號的SYN+ACK數(shù)據(jù)包。

如果配件的最終鏈路同步有效負(fù)載數(shù)據(jù)中含有無效的非協(xié)商數(shù)據(jù)，設(shè)備將發(fā)送一個(gè)RST數(shù)據(jù)包以重置鏈路。

在同步過程中，假定以下默認(rèn)鏈路配置參數(shù)，直到同步完成之前，以下默認(rèn)鏈路配置參數(shù)。

在同步過程中，在同步完成之前，假定使用以下的默認(rèn)鏈路配置參數(shù)：

Table 57-6 Default link parameters during synchronization

Parameter

Default Value

Maximum Number of Outstanding Packets

1

Maximum Received Packet Length

128 bytes

Retransmission Timeout

1000 ms

Cumulative Ack Timeout

10 ms

Maximum Number of Retransmissions

30

Maximum Cumulative Acknowledgements

0

下表包含了一些使用iAP2協(xié)議的傳輸方式所推薦的鏈接配置參數(shù)。

這些值只是作為開發(fā)的初始值，針對某個(gè)特定配件使用的話，需要經(jīng)過相應(yīng)的核實(shí)才行。

Table 57-7 Recommended link parameters for USB Host Mode transport (Full Speed)

Parameter

Recommended Value

Maximum Number of Outstanding Packets

5

Maximum Received Packet Length

4096 bytes

Retransmission Timeout

2000 ms

Cumulative Ack Timeout

22 ms

Maximum Number of Retransmissions

30

Maximum Cumulative Acknowledgements

3

Table 57-8 Recommended link parameters for USB Device Mode transport (Full Speed)

這個(gè)和上面一樣。

Table 57-9 Recommended link parameters for Bluetooth transport

Parameter

Recommended Value

Maximum Number of Outstanding Packets

5

Maximum Received Packet Length

2048 bytes

Retransmission Timeout

1500 ms

Cumulative Ack Timeout

73 ms

Maximum Number of Retransmissions

30

Maximum Cumulative Acknowledgements

3

Table 57-10 Recommended link parameters for 115.2 kbps UART transport

Parameter

Recommended Value

Maximum Number of Outstanding Packets

4

Maximum Received Packet Length

256 bytes

Retransmission Timeout

1000 ms

Cumulative Ack Timeout

133 ms

Maximum Number of Retransmissions

30

Maximum Cumulative Acknowledgements

2

57.2.7.4 Acknowledgements

為了保證數(shù)據(jù)包派發(fā)成功，鏈路協(xié)議同時(shí)使用了數(shù)據(jù)包的接收確認(rèn)和重傳。每個(gè)帶有有效負(fù)載數(shù)據(jù)的數(shù)據(jù)包和SYN數(shù)據(jù)包在被接收方收到并認(rèn)可后，需要接收方回復(fù)ACK。回復(fù)的ACK數(shù)據(jù)包不需要另一方再回復(fù)ACK。損壞的數(shù)據(jù)包被丟棄，不需要回復(fù)ACK。當(dāng)數(shù)據(jù)包在重傳超時(shí)規(guī)定的時(shí)間內(nèi)未被接收方確認(rèn)時(shí)，發(fā)送方將重傳數(shù)據(jù)包。

有兩種類型的數(shù)據(jù)包確認(rèn)方式(ACK)。累積確認(rèn)用于確認(rèn)收到的所有按順序接收到的數(shù)據(jù)包，指定的是某個(gè)最新發(fā)送的符合順序的數(shù)據(jù)包。擴(kuò)展確認(rèn)允許接收方確認(rèn)不按順序的數(shù)據(jù)包。使用的確認(rèn)類型只是根據(jù)數(shù)據(jù)包到達(dá)順序而定。在可能的情況下，鏈路實(shí)現(xiàn)應(yīng)使用累積確認(rèn)，并僅在數(shù)據(jù)包被非按順序接收時(shí)使用擴(kuò)展確認(rèn)。

一旦收到一個(gè)或多個(gè)不按順序的數(shù)據(jù)包，接收方應(yīng)立即生成并發(fā)送擴(kuò)展確認(rèn)。

如果相應(yīng)的ACK在傳輸中丟失，同一個(gè)有效載荷數(shù)據(jù)可能被多次接收。發(fā)生這種情況時(shí)，接收方應(yīng)重新發(fā)送有效負(fù)載數(shù)據(jù)的ACK。

57.2.7.5 Retransmissions

數(shù)據(jù)包在底層傳輸時(shí)，可能會丟失或損壞。這樣就可能被數(shù)據(jù)包丟棄。如前所提的數(shù)據(jù)包的回復(fù)ACK機(jī)制，要求接收方正確收到一個(gè)有效數(shù)據(jù)包時(shí)，要回復(fù)一個(gè)ACK的數(shù)據(jù)包。

為了檢測丟失的數(shù)據(jù)包，發(fā)送方應(yīng)為每個(gè)發(fā)出的數(shù)據(jù)包啟用一個(gè)重傳超時(shí)時(shí)間。這個(gè)定時(shí)器的時(shí)間是根據(jù)協(xié)商確定的。當(dāng)收到一個(gè)數(shù)據(jù)包的確認(rèn)時(shí)，該數(shù)據(jù)包的定時(shí)器被取消。如果定時(shí)器在收到確認(rèn)之前過期，則數(shù)據(jù)包被重傳，定時(shí)器被重新啟動。可以重傳的最大次數(shù)，是根據(jù)鏈接同步期間協(xié)商而定的。

57.2.7.6 Flow Control

iAP2鏈路使用了流控機(jī)制，根據(jù)未收到確認(rèn)的數(shù)據(jù)包個(gè)數(shù)，和鏈路配置參數(shù)里的最大未決數(shù)據(jù)包個(gè)數(shù)。該參數(shù)由雙方在創(chuàng)建鏈路時(shí)指定，并應(yīng)根據(jù)各自分配給鏈路的緩沖區(qū)的數(shù)量和大小來設(shè)置。一旦設(shè)定，該參數(shù)在連接時(shí)保持不變。

該鏈路采用了序列號窗口的概念，用于可接受的數(shù)據(jù)包序列號。窗口的左邊緣是最后一個(gè)確認(rèn)的數(shù)據(jù)包序列號加1。窗口的右邊緣等于最后一個(gè)序列內(nèi)確認(rèn)的數(shù)據(jù)包序列號加最大未決數(shù)據(jù)包數(shù)量。鏈路發(fā)送者發(fā)送數(shù)據(jù)包，直到達(dá)到接收者的最大未處理數(shù)據(jù)包數(shù)量。一旦達(dá)到限制，發(fā)送方只能收到一個(gè)確認(rèn)包，再發(fā)送一個(gè)新數(shù)據(jù)包。

當(dāng)一個(gè)收到的數(shù)據(jù)包的數(shù)據(jù)包序列號落在窗口內(nèi)，它就被確認(rèn)。分兩種情況。如果數(shù)據(jù)包序列號等于左邊緣（即它是下一個(gè)預(yù)期的數(shù)據(jù)包序列號），則以累積確認(rèn)（ACK）確認(rèn)該數(shù)據(jù)包，并且接受窗口的左邊緣和右邊緣遞增一個(gè)。如果收到的數(shù)據(jù)包的序列號在窗口內(nèi)，但不在序列內(nèi)，則用擴(kuò)展確認(rèn)（EAK）來確認(rèn)。窗口不作調(diào)整，并記錄收到的不符合順序的數(shù)據(jù)包。收到的鏈路數(shù)據(jù)包序列號在窗口之外的數(shù)據(jù)包應(yīng)被丟棄；并表明鏈路不穩(wěn)定，可能需要重置。

當(dāng)發(fā)送方收到擴(kuò)展確認(rèn)（EAK）時(shí)，發(fā)送方不應(yīng)在發(fā)送接收窗口之外的數(shù)據(jù)包。如果一個(gè)數(shù)據(jù)包沒有被確認(rèn)，但所有后續(xù)的數(shù)據(jù)包都被收到并確認(rèn)，就可能發(fā)生這種情況。這一要求將把窗口的左邊緣固定在未被確認(rèn)的數(shù)據(jù)包的序列號上。隨著其他數(shù)據(jù)包的發(fā)送，下一個(gè)數(shù)據(jù)包序列號將接近并最終超過右邊緣。這時(shí)，沒有更多的數(shù)據(jù)包可以被發(fā)送，直到未被確認(rèn)的數(shù)據(jù)包被確認(rèn)。

57.2.7.7 Reset

設(shè)備可以在任何時(shí)候向配件發(fā)送一個(gè)RST數(shù)據(jù)包。收到RST數(shù)據(jù)包后，附件應(yīng)在收到RST數(shù)據(jù)包后1秒內(nèi)向設(shè)備發(fā)送SYN數(shù)據(jù)包，然后進(jìn)行同步處理。

配件應(yīng)終止底層傳輸連接，然后再重新連接。如果UART傳輸處于活動狀態(tài)，只有手動的斷開再接入配合和設(shè)備的Lightning連接器才可以。當(dāng)必須重連時(shí)，表明協(xié)商的鏈接參數(shù)設(shè)置不合理，一般情況下不應(yīng)該發(fā)生這種情況。

總結(jié)

以上是生活随笔為你收集整理的IAP2 通过蓝牙的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。