Introduction to CAN Transport Protocol (CAN-TP)
Protocol Control Information or PCI, sits at the start of every CAN-TP frame. Think of it as a small header that guides how the rest of the data should be handled.
PCI tells the receiver what kind of frame has arrived. This matters because CAN-TP supports different frame types such as single frame, first frame, consecutive frame and flow control frame. Each type follows its own rules.
PCI also carries key details needed to process the message:
- It shows the total message length when data spans multiple frames
- It gives the sequence number for consecutive frames so the receiver keeps data in order
- It provides flow control information to manage how fast data is sent
The size and structure of PCI change based on the frame type. A simple single frame uses a small PCI, while multi-frame communication uses more detailed PCI fields.
The PCI for different frame types is listed in the table below:
| Frame Type | PCI Size | PCI Content Description | Additional Considerations |
|---|---|---|---|
| Single Frame (SF) standard | 1 byte | Byte 1 upper nibble = 0x0 (SF), Byte 1 lower nibble = data length | Used over CAN and CAN FD when message length ≤ 7 bytes |
| Single Frame (SF) extended | 2 bytes | Byte 1 = 0x00 (indicates extended SF) Byte 2 = data length | Used over CAN FD for 8 to 62 bytes |
| First Frame (FF) standard | 2 bytes | Byte 1 upper nibble = 0x1 (FF) Byte 1 lower nibble + Byte 2 (12 bits total) = message length | Used when message > 7 bytes. Max 4095 bytes |
| First Frame (FF) extended | 6 bytes | Byte 1 upper nibble = 0x1 (FF) Byte 1 lower nibble = 0x0 Byte 2 = 0x00 Byte 3 – byte 6 = Message length | Used when message > 4095 bytes. Max 4 GB |
| Consecutive Frame (CF) | 1 byte | Byte 1 upper nibble = 0x2 (CF), Byte 2 lower nibble = sequence number (SN: 0-15) | Carries remaining data. SN cycles 0 to 15 |
| Flow Control (FC) | 3 bytes | Byte 1 upper nibble = 0x3, lower nibble = Flow status (FS), Byte 2: Block Size, Byte 3: STmin | No message data. Controls flow |
CAN-TP Data Transfer
Unsegmented Data Transfer
If your data is small, it fits into a single CAN-TP frame.
For Classical CAN, you can send up to 7 bytes of data in one frame.
For CAN FD, you can send up to 62 bytes in one frame.
In this case, the protocol uses:
- Single Frame for Classical CAN
- Extended Single Frame for CAN FD
Since the entire message fits in one frame, there is no need to split it or manage multiple frames. No sequence numbers or flow control steps are required.
The receiver reads the frame once and gets the complete message immediately. This makes communication faster and simpler when the data size is small.

Segmented Data Transfer
When your message is larger than what a single frame holds, CAN-TP splits it into multiple frames and sends them step by step.
For Classical CAN, this happens when data exceeds 7 bytes.
For CAN FD, this happens when data exceeds 62 bytes.
Below is the process works:
- First Frame starts the transmission
The sender sends a First Frame.
This frame tells the receiver that a longer message is coming and includes the total message length. - Receiver sends Flow Control
After receiving the First Frame, the receiver replies with a Flow Control frame.
This frame tells the sender how to continue sending the remaining data. - Flow Control defines transmission rules
The Flow Control frame includes:- Block Size (BS): Number of frames the sender is allowed to send before stopping
- STmin (Separation Time): Minimum delay between consecutive frames
These values help the receiver avoid overload and process data smoothly.
- Sender sends Consecutive Frames
The sender then sends a series of Consecutive Frames, following the rules from the Flow Control:- Sends up to the allowed block size
- Waits at least STmin time between frames
- Repeat until complete
After one block is sent, the sender waits.
The receiver sends another Flow Control frame.
This cycle continues until all data is transmitted.

CAN-TP Frame Types
Single Frame (SF)
- If your data is 7 bytes or less, the whole message fits into one Single Frame for both Classical CAN and CAN FD.
- PCI (Protocol Control Information) in the first byte explains how to read the frame:
- The upper 4 bits (0000) show that this is a Single Frame
- The lower 4 bits show the data length from 0 to 7 bytes
- The remaining bytes in the frame carry your actual data.
- Since everything fits in one frame:
- No splitting of data
- No sequence handling
- No Flow Control frame needed
We can send once and the receiver gets the complete message in one step.

Example:
06 11 22 33 44 55 66 is a Single Frame with 6 bytes of message data.
Extended Single Frame (for CAN FD)
CAN FD supports frames up to 64 bytes. But a normal Single Frame uses only 1 byte for PCI, which leaves space for just 7 bytes of data.
To send more data in one frame, CAN-TP uses an Extended Single Frame.
Workflow:
- The PCI is 2 bytes instead of 1
- Byte 1 = 0x00. This tells the receiver that this is an Extended Single Frame
- Byte 2 = data length. This shows how many bytes of data are in the frame
- The remaining bytes carry the actual message data
Since 2 bytes are used for PCI, the available space for data becomes:
- 64 total bytes − 2 PCI bytes = 62 bytes of data
So, with an Extended Single Frame in CAN FD:
- You send up to 62 bytes in a single frame
- No segmentation is needed
- No Flow Control or multiple frames are involved
This method keeps communication simple while allowing larger data compared to the normal Single Frame.

Example:
00 14 11 22 33 44 … (20 bytes)is an extended Single Frame with 20 bytes (0x14) of message data.
First Frame (FF)
- A First Frame starts a transmission when your message is too large for a single frame.
- You use a First Frame when:
- Data is more than 7 bytes in Classical CAN
- Data is more than 62 bytes in CAN FD
- The first 2 bytes form the PCI:
- The upper 4 bits of byte 1 = 1. This shows it is a First Frame
- The next 12 bits carry the total message length. Range is up to 4095 bytes
- The remaining space in the frame carries the first part of your data:
- In Classical CAN: 6 bytes of data fit after the PCI
- In CAN FD: up to 62 bytes of data fit after the PCI
- After receiving the First Frame:
- The receiver sends a Flow Control frame
- This tells the sender how to continue
- The sender then sends the rest of the data using Consecutive Frames
First Frame announces a long message and shares its total size. The actual data transfer continues in multiple steps after that.

Examples:
- 12 00 22 33 44 55 66 77 is a First Frame, starting the transmission of a 512 bytes long message.
- 1F FF 22 33 44 55 66 77 is a First Frame, starting the transmission of a 4095 bytes long message (maximum data length for a First Frame).
Extended First Frame
- Use an Extended First Frame when your message is larger than 4095 bytes in both Classical CAN and CAN FD.
- This frame handles very large data by expanding the length field.
- The first 6 bytes are PCI:
- Byte 1 = 0x10 and Byte 2 = 0x00. This combination shows an Extended First Frame
- Bytes 3 to 6 store the total message length. This supports sizes up to about 4 GB
- After the PCI, the remaining bytes in the frame carry the first part of your data.
- Once the receiver gets this frame:
- It sends a Flow Control frame to guide the transmission
- The sender continues sending the rest using Consecutive Frames
The Extended First Frame is used for very large messages. It tells the receiver the full size using a larger length field, then the data continues in multiple frames under flow control.

Example:
- 10 00 00 00 15 E0 11 22 33 44… is an extended First Frame starting the transmission of a 5600 bytes long message.
Consecutive Frame (CF)
- After the First Frame sends the initial part of the data
- 6 bytes in Classical CAN
- 62 bytes in CAN FD
the remaining data is sent using Consecutive Frames
- Each Consecutive Frame starts with 1 byte of PCI:
- The upper 4 bits = 2. This shows it is a Consecutive Frame
- The lower 4 bits = sequence number. Range is 0 to F
- Sequence numbering works like this:
- First Consecutive Frame starts with 1
- The number increases by 1 for each frame
- After F, it rolls over back to 0
- This sequence number helps the receiver:
- Check if any frame is missing
- Detect if frames arrive out of order
Consecutive Frames carry the rest of the data in order, while the sequence number keeps the transmission reliable.

Example using classical CAN:
2F 11 22 33 44 55 66 77 is the Consecutive Frame with sequence number 15.

Flow Control frame (FC)
- A Flow Control Frame is sent by the receiver to control how the sender continues sending data.
- It is used during multi-frame transmission, after a First Frame.
- A Flow Control Frame has 3 PCI bytes:
1. Byte 1: Frame type and status
- Upper 4 bits = 3. This shows it is a Flow Control Frame
- Lower 4 bits = Flow Status:
- 0 (CTS): Continue to send
- 1 (WAIT): Pause, wait before sending more
- 2 (OVFLW): Receiver buffer is full, stop transmission
2. Byte 2: Block Size (BS)
- Controls how many Consecutive Frames the sender can send before stopping:
- 0: Send all remaining frames without waiting
- N (1, 2, 3, …): Send only N frames, then wait for next Flow Control
3. Byte 3: STmin (Separation Time)
- Defines the minimum delay between Consecutive Frames
- Two formats are used:
Milliseconds range (0x00 to 0x7F):
- 0x00 = 0 ms
- 0x01 = 1 ms
- …
- 0x7F = 127 ms
Microseconds range (0xF1 to 0xF9):
- 0xF1 = 100 µs
- 0xF2 = 200 µs
- …
- 0xF9 = 900 µs
- Other values are reserved and not used.
- Flow Control Frames do not carry actual message data:
- Only the 3 PCI bytes are meaningful
- Remaining bytes are padding, often:
- 0x00, or
- 0xAA (based on system or OEM rules)
The Flow Control Frame tells the sender when to send, how many frames to send, and how fast to send them.

Timing Parameters
| Timing Parameter | Who Uses It | Starts/Stops When… |
| N_As | Sender | Timeout that starts after a CAN-TP frame is sent and stops when the sent CAN-TP frame has been acknowledged on the CAN layer. |
| N_Ar | Receiver | Timeout that starts after a CAN-TP frame is sent and stops when the sent CAN-TP frame has been acknowledged on the CAN layer. |
| N_Bs | Sender | Timeout within which the sender expects an FC from the receiver. Timeout starts after sending FF/CF (block size) or after the sender has received a FC with flow status = WAIT. |
| N_Br | Receiver | Timeout within which the receiver must send a FC. Timeout starts after reception of FF/CF (block size) or after the receiver has sent an FC with flow status = WAIT. |
| N_Cs | Sender | Timeout that starts after FC has been received or a sent CF has been acknowledged (N_As). The next CF must be sent within this timeout. |
| N_Cr | Receiver | Timeout that starts after FC has been sent or a CF has been received. The receiver expects to receive the next CF within this timeout. |
Error Handling in CAN-TP
Timeout handling
- Both sender and receiver use timers to track delays.
- Receiver timeouts (N_Ar, N_Br, N_Cr)
- If any of these expire, the receiver stops the transmission
- Sender timeouts (N_As, N_Bs, N_Cs)
- If any of these expire, the sender stops the transmission
Sequence number check
- Each Consecutive Frame carries a sequence number
- If the receiver gets a wrong or unexpected sequence number:
- It aborts message reception
Flow Control errors
- The sender checks Flow Control frames from the receiver
- If the Flow Status value is invalid:
- The sender stops transmission
- If the sender sends frames faster than allowed (violates STmin):
- Transmission continues
- But the receiver may fail to process all frames correctly
Unexpected frame types
- If a node receives a frame that does not match the expected type:
- The frame is ignored
Error recovery behavior
- CAN-TP does not restart transmission after an error
- Instead:
- It reports the error to the upper layer, such as Unified Diagnostic Services
- The upper layer decides what to do next, such as retrying the request
CAN-TP focuses on detecting issues and stopping safely. It leaves recovery and retry decisions to higher-level protocols.
Summary
- CAN-TP (ISO 15765-2) is used to send large data messages over a CAN bus.
This is needed for diagnostics such as Unified Diagnostic Services, where messages often exceed the size of a single CAN frame.
Overall structure of CAN-TP
- CAN-TP sits on top of the CAN layer
- It splits large data into smaller frames and reassembles them at the receiver
- It adds control information using PCI (Protocol Control Information) at the start of each frame
Operation over Classical CAN and CAN FD
- Classical CAN:
- Max frame size: 8 bytes
- Data per Single Frame: up to 7 bytes
- CAN FD:
- Max frame size: 64 bytes
- Data per Single Frame: up to 62 bytes
- CAN-TP adjusts its behavior based on available frame size:
- Uses Extended Single Frame for larger payloads in CAN FD
- Sends fewer frames in CAN FD compared to Classical CAN for the same data
Frame types in CAN-TP
CAN-TP uses four main frame types:
- Single Frame (SF)
- Used when data fits in one frame
- First Frame (FF)
- Starts a multi-frame transmission
- Includes total message length
- Consecutive Frame (CF)
- Carries remaining data after the First Frame
- Uses sequence numbers
- Flow Control (FC)
- Sent by receiver
- Controls speed and amount of data sent
Use of PCI in frames
- Each frame starts with PCI bytes
- PCI tells the receiver:
- Frame type
- Message length
- Sequence number
- Flow control settings
- The number of PCI bytes depends on the frame type:
- 1 byte for simple frames
- 2 or more bytes for extended or multi-frame communication
Data structure of frame types
- Single Frame:
- PCI + data
- First Frame:
- PCI (length info) + initial data
- Consecutive Frame:
- PCI (sequence number) + next data chunk
- Flow Control Frame:
- PCI only (no actual data, rest is padding)
Flow control mechanism
- The receiver manages data flow using Flow Control frames:
- Block Size (BS): number of frames allowed before pause
- STmin: minimum delay between frames
- This ensures:
- Receiver is not overloaded
- Data is processed correctly
- Segmented data is reconstructed as one complete message
Timing and error handling
- CAN-TP defines timing parameters:
- Sender timers: N_As, N_Bs, N_Cs
- Receiver timers: N_Ar, N_Br, N_Cr
- If any timer expires:
- Transmission is stopped
- Other checks:
- Wrong sequence number → reception stops
- Invalid Flow Control → transmission stops
- CAN-TP does not retry automatically:
- It reports errors to upper layers like Unified Diagnostic Services