Transport Protocol Requirements¶
This section defines Software Low-Level Requirements (SW-LLR) for the SOME/IP Transport Protocol (SOME/IP-TP) module. SOME/IP-TP enables transport of large messages over UDP by segmentation and reassembly.
Overview¶
The Transport Protocol module handles:
Segmentation of large messages for transmission
TP header generation and parsing
Reassembly of segmented messages
Timeout and error handling
Segmentation Requirements¶
Segment Calculation¶
The software shall calculate the number of segments required as the ceiling of (payload size / maximum segment size). Rationale: Determines how many segments are needed for the message. Code Location: |
The software shall use a maximum segment payload size of 1392 bytes (87 x 16 bytes) to fit within UDP/IP limits and maintain alignment. Rationale: Maximum aligned size within UDP payload limit. Code Location: |
The software shall ensure all segments except the last have a payload size that is a multiple of 16 bytes. Rationale: Offset field alignment requirement. Code Location: |
The software shall allow the last segment to have any size from 1 byte to the maximum segment size. Rationale: Last segment contains remaining data. Code Location: |
The software shall preserve the original message’s Message ID and Request ID in all segment headers. Rationale: Enables reassembly of related segments. Code Location: |
The software shall use the same Session ID for all segments of an original message. Rationale: Session ID identifies the original message. Code Location: |
The software shall set the TP flag (bit 5, value 0x20) in the Message Type field for all segments. Rationale: TP flag identifies segmented messages. Code Location: |
The software shall preserve the original Message Type and add the TP flag (e.g., REQUEST 0x00 becomes TP_REQUEST 0x20). Rationale: Maintains message semantics during reassembly. Code Location: |
Segmentation Error Handling¶
The software shall return an error when the original message size exceeds the configured maximum TP message size. Rationale: Prevents excessive memory allocation. Error Handling: Return MESSAGE_TOO_LARGE error code. Code Location: |
The software shall return an error when memory allocation for a segment fails. Rationale: Graceful handling of memory exhaustion. Error Handling: Return RESOURCE_EXHAUSTED error code. Code Location: |
The software shall handle segmentation requests for empty payloads by returning a single segment with zero payload. Rationale: Edge case handling for empty messages. Error Handling: Return single zero-length segment. Code Location: |
TP Header Requirements¶
Header Structure¶
The software shall place the 4-byte TP header immediately after the SOME/IP header (starting at byte 16 of the message). Rationale: TP header precedes segment payload. Code Location: |
The software shall use a TP header size of exactly 4 bytes. Rationale: Fixed header size per specification. Code Location: |
Offset Field¶
The software shall place the Offset value in the upper 28 bits (bits 31-4) of the 4-byte TP header. Rationale: Offset field structure per specification. Code Location: |
The software shall calculate the Offset field value as the segment’s byte offset in the original payload divided by 16. Rationale: Offset field represents 16-byte blocks. Code Location: |
The software shall set the Offset field to 0 for the first segment. Rationale: First segment starts at offset 0. Code Location: |
The software shall ensure Offset field values always represent offsets that are multiples of 16 bytes. Rationale: Lower 4 bits are implicitly zero. Code Location: |
Reserved Flags¶
The software shall place the Reserved flags in bits 3-1 of the TP header (3 bits). Rationale: Reserved for future use. Code Location: |
The software shall set the Reserved flags to 0 when generating TP segments. Rationale: Reserved bits must be zero per specification. Code Location: |
The software shall ignore the Reserved flag values when parsing received TP segments. Rationale: Forward compatibility with future use. Code Location: |
More Segments Flag¶
The software shall place the More Segments flag in bit 0 (least significant bit) of the TP header. Rationale: More Segments flag position per specification. Code Location: |
The software shall set the More Segments flag to 1 for all segments except the last segment. Rationale: Indicates more segments will follow. Code Location: |
The software shall set the More Segments flag to 0 for the last segment of a message. Rationale: Indicates this is the final segment. Code Location: |
Length Field in Segments¶
The software shall set the SOME/IP Length field in each segment to cover the Request ID (8 bytes), TP header (4 bytes), and segment payload. Rationale: Length field calculation per specification. Code Location: |
TP Header Error Handling¶
The software shall return an error when the calculated Offset would exceed the maximum value representable in 28 bits. Rationale: Prevents offset field overflow. Error Handling: Return MESSAGE_TOO_LARGE error code. Code Location: |
The software shall reject and discard TP segments whose offset is not aligned to the required 16-byte boundary. Rationale: Misaligned offsets indicate protocol violations and must be treated as errors per REQ_TP_082_E03 and REQ_TP_082. Error Handling: Discard segment, log offset value and expected alignment. Code Location: |
Reassembly Requirements¶
Buffer Management¶
The software shall allocate a reassembly buffer when the first segment of a new message is received. Rationale: Buffer needed to store incoming segments. Code Location: |
The software shall identify each reassembly buffer by the combination of source endpoint, Message ID, and Session ID. Rationale: Enables concurrent reassembly of multiple messages. Code Location: |
The software shall estimate the initial buffer size based on the first segment’s offset and whether it’s the last segment. Rationale: Efficient memory allocation. Code Location: |
The software shall resize the reassembly buffer when the last segment is received and the total message size is determined. Rationale: Accurate final buffer size. Code Location: |
Segment Storage¶
The software shall store each segment’s payload at the buffer position indicated by the segment’s Offset field. Rationale: Correct placement for reassembly. Code Location: |
The software shall track which byte ranges have been received to detect missing segments. Rationale: Enables gap detection for complete reassembly. Code Location: |
The software shall detect segments with the same offset as previously received segments and handle appropriately (ignore or compare). Rationale: Network may deliver duplicates. Code Location: |
The software shall detect segments that partially overlap with previously received segments. Rationale: Overlapping segments indicate protocol error. Error Handling: Log warning; discard new segment. Code Location: |
The software shall handle segments received out of order by placing each segment at its correct offset position. Rationale: UDP may deliver segments out of order. Code Location: |
Completion Detection¶
The software shall complete reassembly when the last segment (More Segments = 0) is received and all preceding data is present. Rationale: All data must be received for complete message. Code Location: |
The software shall not complete reassembly if the last segment arrives before all preceding segments, waiting until all gaps are filled. Rationale: Must have all data before completion. Code Location: |
The software shall deliver the reassembled message to the application layer when reassembly is complete. Rationale: Provides complete message to application. Code Location: |
The software shall release the reassembly buffer after the complete message has been delivered to the application. Rationale: Frees memory for other operations. Code Location: |
Reassembly Error Handling¶
The software shall report an error if all segments are not received within the timeout period after the last segment is received. Rationale: Incomplete message cannot be processed. Error Handling: Return SEQUENCE_ERROR error code. Code Location: |
The software shall return an error when the estimated or actual message size exceeds the configured maximum. Rationale: Prevents excessive memory allocation. Error Handling: Return MESSAGE_TOO_LARGE error code. Code Location: |
The software shall discard the reassembly buffer if the implied total message length changes between segments. Rationale: Inconsistent segments indicate error or attack. Error Handling: Discard buffer; return MALFORMED_MESSAGE error. Code Location: |
The software shall return an error when the maximum number of concurrent reassembly operations is exceeded. Rationale: Resource management for memory-constrained systems. Error Handling: Return RESOURCE_EXHAUSTED error code. Code Location: |
Timeout Handling¶
Timer Management¶
The software shall start a reassembly timer when the first segment of a new message is received. Rationale: Limits time for reassembly completion. Code Location: |
The software shall use a configurable reassembly timeout value, with a default of 5000 milliseconds. Rationale: Allows tuning for different network conditions. Code Location: |
The software shall optionally reset the reassembly timer when each segment is received, if configured. Rationale: Allows for slow but steady segment arrival. Code Location: |
The software shall detect when the reassembly timer expires for any active reassembly operation. Rationale: Triggers timeout handling. Code Location: |
Timeout Actions¶
The software shall discard all received segments for a reassembly operation when the timeout expires. Rationale: Incomplete message is not useful. Error Handling: Discard buffer and free memory. Code Location: |
The software shall release all memory associated with the reassembly buffer when the timeout expires. Rationale: Prevents memory leaks. Error Handling: Free buffer and tracking structures. Code Location: |
The software shall report a timeout error to the application layer when reassembly fails due to timeout. Rationale: Application may need to take corrective action. Error Handling: Invoke error callback with REASSEMBLY_TIMEOUT. Code Location: |
The software shall log timeout details including Message ID, Session ID, and number of segments received. Rationale: Diagnostics for troubleshooting. Error Handling: Log at WARNING level. Code Location: |
Timer Error Handling¶
The software shall handle timer creation failures by using a fallback polling mechanism or rejecting the segment. Rationale: Graceful degradation on resource exhaustion. Error Handling: Log error; use fallback or reject. Code Location: |
The software shall prevent creation of duplicate timers for the same reassembly operation. Rationale: Prevents timer leak. Error Handling: Reuse existing timer. Code Location: |
Statistics and Monitoring¶
The software shall track statistics for segmentation operations, including messages segmented and segments sent. Rationale: Monitoring and diagnostics. Code Location: |
The software shall track statistics for reassembly operations, including messages reassembled and segments received. Rationale: Monitoring and diagnostics. Code Location: |
The software shall track error statistics including timeouts, retransmissions, and malformed segments. Rationale: Error rate monitoring. Code Location: |
The software shall provide a method to query the number of active reassembly operations. Rationale: Resource monitoring. Code Location: |
Sender Behavior¶
The software shall segment only messages that are configured for SOME/IP-TP segmentation. Rationale: Restricting segmentation to configured messages prevents unexpected bandwidth usage. Code Location: |
The software shall send segments in ascending offset order. Rationale: Ascending offset order simplifies receiver buffer management. Code Location: |
All segments with More Segments Flag = 1 shall have the same size. The sender shall maximize segment size within specification limits. Rationale: Uniform segment size maximizes throughput and simplifies flow control. Code Location: |
The sender shall not send overlapping or duplicated segments. Rationale: No overlapping segments prevents ambiguous data and simplifies reassembly. Code Location: |
The sender shall use only configured Client IDs for SOME/IP-TP messages. Rationale: Client ID restrictions enable per-client traffic accounting and access control. Code Location: |
ECUs using SOME/IP-TP shall implement traffic shaping to limit the rate of segments on the network. Rationale: Traffic shaping prevents TP segments from overwhelming the network. Code Location: |
Receiver Behavior Extensions¶
The receiver shall use the Session ID to detect new original messages. A segment with a different Session ID shall start a new reassembly. Rationale: Session-based detection enables the receiver to handle concurrent messages from the same sender. Code Location: |
The Return Code of the reassembled message shall be taken from the last segment received. Rationale: Using the last segment’s return code ensures the overall result reflects the final processing state. Code Location: |
The Message Type passed to the application after reassembly shall have the TP Flag set to 0. Rationale: Clearing the TP flag presents a clean non-segmented message to the application layer. Code Location: |
The receiver shall cancel desegmentation when resources are exhausted, consistent with REQ_TP_076_E01 (cancel the oldest incomplete reassembly). Rationale: Cancellation on resource exhaustion prevents memory exhaustion from incomplete reassemblies. Code Location: |
Reordering of segments from different original messages using the same buffer shall not be allowed. Rationale: Isolating buffers by session prevents data corruption from interleaved segments. Code Location: |
The receiver may cancel reassembly when overlapping or duplicated segments change previously received bytes, if configurable. Rationale: Detecting overlapping changes prevents silent data corruption. Code Location: |
TP Informational References¶
The software shall detect and handle obvious errors in received TP segments gracefully. Rationale: Graceful error handling prevents crashes from malformed TP headers. Code Location: |
The software shall reject segments that exceed the configured maximum segment size. Rationale: Oversized segments violate the TP protocol and may cause receiver buffer overflows. Error Handling: Return SEGMENT_TOO_LARGE error code. Code Location: |
The software shall cancel the oldest incomplete reassembly when the reassembly buffer pool is full. Rationale: Prevents memory exhaustion from many concurrent incomplete reassemblies. Error Handling: Cancel oldest reassembly, log Message ID of cancelled reassembly. Code Location: |
The software shall reject TP segments whose Message Type differs from the first segment in the reassembly. Rationale: Type mismatches indicate crossed message streams. Error Handling: Discard segment, log type mismatch details. Code Location: |
The software shall discard TP segments with unsupported Protocol Version. Rationale: Protocol Version mismatch indicates incompatible TP implementation. Error Handling: Discard segment, log version mismatch. Code Location: |
The software shall reject TP segments whose offset is not aligned to the required boundary. Rationale: Misaligned offsets indicate protocol violations. Error Handling: Discard segment, log offset value and expected alignment. Code Location: |
The software shall discard TP segments with zero-length payload in multi-segment messages. A single-segment message with zero-length payload (as produced by the sender contract in REQ_TP_001_E03) shall be accepted. Rationale: Zero-length segments in multi-segment messages carry no data and waste resources, but a single-segment zero-payload message is a valid edge case defined by the sender contract. Error Handling: Discard zero-length segment in multi-segment context, log warning. Code Location: |
The software shall cancel reassembly when the projected reassembled message would exceed the configured maximum message size. Rationale: Prevents excessive memory allocation from crafted segment offsets. Error Handling: Cancel reassembly, free buffer, log projected size. Code Location: |
Traceability¶
Implementation Files¶
include/tp/tp_types.h- TP type definitionsinclude/tp/tp_manager.h- TP manager interfaceinclude/tp/tp_segmenter.h- Segmenter interfaceinclude/tp/tp_reassembler.h- Reassembler interfacesrc/tp/tp_manager.cpp- TP manager implementationsrc/tp/tp_segmenter.cpp- Segmenter implementationsrc/tp/tp_reassembler.cpp- Reassembler implementation
Test Files¶
tests/test_tp.cpp- TP unit tests