Feature #3979
closedTTCN3 SABP support
100%
Description
We need SABP type definitions and libfftranscode support for SABP in order to write TTCN-3 test cases for SABP implementation in OsmoCBC.
As SABP is spoken over TCP, we also need a TTCN-3 implementation of what's needed to determine the length of an APER-encoded message to find the PDU boundaries in the TCP stream.
Files
Related issues
Updated by laforge almost 5 years ago
- Related to Feature #3977: SABP stream delineation routines added
Updated by laforge almost 5 years ago
- Related to Feature #2394: Implement SABP (Service Area Broadcast Protocol) added
Updated by laforge over 4 years ago
- Status changed from New to Stalled
- % Done changed from 0 to 30
SABP encoding/decoding support has been added to libfftranscode and to osmo-ttcn3-hacks (laforge/cbsp
branch). However, SABP TCP stream segmentation code for TITAN doesn't exist yet.
Updated by laforge over 4 years ago
- File sabp_write.pcap sabp_write.pcap added
it looks like the start of a SABP message looks like this:
00 initiatingMessage 00 procedureCode 00 criticality 80 constructed? 93 length (of data following)
the '93' length value likely is encoded as variable-length length field, in case the length exceeds what can be encoded in a single octet. but anyway, it seems we read the first 5/6 bytes and then we know the following number of bytes.
Updated by laforge over 4 years ago
laforge wrote:
it looks like the start of a SABP message looks like this:
[...]
the '93' length value likely is encoded as variable-length length field, in case the length exceeds what can be encoded in a single octet. but anyway, it seems we read the first 5/6 bytes and then we know the following number of bytes.
Actually, the 8093 is the encoded length, as it is more than 127 (fitting in one octet), it is encoded as 8093 with 80 indicating a two-byte encoding.
The longest SABP Content is 1246 bytes, but there can actually be up to 65535 SAIs in a Service Area List, so we are probably not sufficiently safe to assume the overall length is only 1-2 bytes long. In fact, we likely need to implement the full variable-length-length as per the ASN.1 PER spec.
Updated by laforge over 4 years ago
According to X.961 Section 9.1 NOTE 2, the encoding for message sizes < 16384 bytes is easy. For > 16384, the payload is actually fragmented into fragments of up to 64kBytes per fragment, followed by more fragments.
Updated by laforge over 4 years ago
- Status changed from Stalled to In Progress
- % Done changed from 30 to 80
Updated by laforge about 4 years ago
- Tracker changed from Bug to Feature
- Status changed from In Progress to Stalled
Updated by laforge almost 4 years ago
- Status changed from Stalled to Resolved
- % Done changed from 80 to 100
patches have long been merged