CAN 單幀的數(shù)據(jù)場最多 8 字節(jié)。而 ISOBUS 上需要傳輸?shù)膬?nèi)容經(jīng)常遠超這個量：虛擬終端的對象池、文件服務器里的作業(yè)文件、包含故障碼的診斷報文、車輛識別號這類長字符串。傳輸協(xié)議負責把這些內(nèi)容切成片，并在接收端還原。1. 兩種機制J1939 給出兩套傳輸協(xié)議，ISOBUS 沿用：點對點（RTS/CTS）：發(fā)送方先請求，接收方按自己的緩沖能力允許發(fā)送，全程有確認。廣播（BAM）：發(fā)送方直接宣布「要發(fā)多少、多少包」，然后連續(xù)發(fā)送，接收方不參與控制。兩者共用同一對 PGN：連接管理（60416，0xEC00）與數(shù)據(jù)傳輸（60160，0xEB00）。2. RTS/CTS：接收方掌握節(jié)奏發(fā)送方發(fā)出連接管理報文，控制字節(jié)為「請求發(fā)送」，聲明總字節(jié)數(shù)、總包數(shù)與被傳報文的 PGN。接收方回復「允許發(fā)送」，指定本次可以連續(xù)接收的包數(shù)與起始包號。發(fā)送方按允許的范圍發(fā)送數(shù)據(jù)幀。全部發(fā)完后，接收方回復「消息結(jié)束確認」。這條路徑適合對象池、文件傳輸這類完整性要求高的數(shù)據(jù)。有兩點實現(xiàn)細節(jié)值得注意：接收方可以掛起發(fā)送方。當「允許發(fā)送」的包數(shù)為零時，表示接收方緩沖已滿，發(fā)送方需要等待下一個允許發(fā)送的報文；等待時間超過上限就要中止會話。確認是分段的。接收方可以每幾包確認一次，不需要逐包確認。這使得傳輸效率與接收緩沖大小可以折中調(diào)節(jié)。