Project

General

Profile

Bug #3979

TTCN3 SABP support

Added by laforge 6 months ago. Updated 28 days ago.

Status:
In Progress
Priority:
High
Assignee:
Target version:
-
Start date:
05/06/2019
Due date:
% Done:

80%

Tags:

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.

sabp_write.pcap sabp_write.pcap 260 Bytes laforge, 09/17/2019 07:08 PM

Related issues

Related to OsmoCBC - Feature #3977: SABP stream delineation routinesNew05/06/2019

Related to OsmoHNBGW - Feature #2394: Implement SABP (Service Area Broadcast Protocol)New07/24/2017

History

#1 Updated by laforge 6 months ago

  • Related to Feature #3977: SABP stream delineation routines added

#2 Updated by laforge 6 months ago

  • Tags set to SMSCB

#3 Updated by laforge 6 months ago

  • Related to Feature #2394: Implement SABP (Service Area Broadcast Protocol) added

#4 Updated by laforge 3 months ago

  • Priority changed from Normal to High

#5 Updated by laforge about 1 month 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.

#6 Updated by laforge about 1 month ago

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.

#7 Updated by laforge about 1 month 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.

#8 Updated by laforge about 1 month 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.

#9 Updated by laforge 28 days ago

  • Status changed from Stalled to In Progress
  • % Done changed from 30 to 80

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)