Project

General

Profile

Actions

Feature #3979

closed

TTCN3 SABP support

Added by laforge almost 5 years ago. Updated almost 4 years ago.

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

100%

Spec Reference:
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.


Files

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 routinesNewlaforge05/06/2019

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

Actions
Actions #1

Updated by laforge almost 5 years ago

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

Updated by laforge almost 5 years ago

  • Tags set to SMSCB
Actions #3

Updated by laforge almost 5 years ago

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

Updated by laforge over 4 years ago

  • Priority changed from Normal to High
Actions #5

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.

Actions #6

Updated by laforge over 4 years 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.

Actions #7

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.

Actions #8

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.

Actions #9

Updated by laforge over 4 years ago

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

Updated by laforge about 4 years ago

  • Tracker changed from Bug to Feature
  • Status changed from In Progress to Stalled
Actions #11

Updated by laforge almost 4 years ago

  • Status changed from Stalled to Resolved
  • % Done changed from 80 to 100

patches have long been merged

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)