Project

General

Profile

Actions

Feature #3994

closed

ttcn3: would be nice to be able to template GSUP messages as struct templates, in the same way we do with BSSAP, RSL, DTAP and all other messages

Added by neels almost 5 years ago. Updated over 4 years ago.

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

70%

Spec Reference:

Description

In ttcn3, a GSUP message contains a sequence of IEs.
That makes it hard to wildcard individual IEs, particularly to allow an IE to be both present or not present.

  • A wildcard is not specific to the IE kind.
  • the position of other IEs is affected.
  • it is virtually impossible to build templates by extending other templates for GSUP.

Instead, if GSUP messages were placed in a struct with members (like it happens with e.g. BSSAP messages), it would be far easier to wildcard individual members.

Currently, something like this is needed:

private function f_gen_tr_ss_ies(
        template hexstring imsi,
        template OCT4 sid := ?,
        template GSUP_SessionState state := ?,
        template octetstring ss := ?
) return template GSUP_IEs {
        /* Mandatory IEs */
        var template GSUP_IEs ies := {
                tr_GSUP_IE_IMSI(imsi),
                tr_GSUP_IE_SessionId(sid),
                tr_GSUP_IE_SessionState(state)
        };
        var integer last_idx := 3;

        /* Optional SS payload */
        if (istemplatekind(ss, "*")) {
                ies[3] := *;
                last_idx := last_idx + 1;
        } else if (not istemplatekind(ss, "omit")) {
                ies[3] := tr_GSUP_IE_SSInfo(ss);
                last_idx := last_idx + 1;
        }

        ies[last_idx] := tr_GSUP_IE_Message_Class(OSMO_GSUP_MESSAGE_CLASS_USSD);
        last_idx := last_idx + 1;

        return ies;
}

Note that IE indexes in the sequence is involved, also conditionals, and combining several IE types blows up the complexity.
Also, for each individual application, a separate function needs to be written.
Instead, if GSUP were a struct with named members, writing the expectations is trivial, and templates can be easily built upon others, e.g.:

template PDU_GSUP tr_GSUP_SS := tr_GSUP {
   .ss_payload = *,
   .message_class = *
};

What would be needed is a layer that iterates IEs and places the extracted values in a struct with named members,
instead of a sequence of IE templates.

Actions #1

Updated by laforge almost 5 years ago

First option that comes to my mind: One can change "type record of GSUP_IE GSUP_IEs" to "type set of GSUP_IE GSUP_IEs" and then use the subset() operator [see page 175 of TTCN3_P.pdf] to ensure that all IEs in the message are part of the specified set. Howver, the 'set of' would then accept IEs in arbitrary order

Also, in any receive template, you can always say something like this:

template GSUP_IEs a := ...;
template GSUP_IEs b := ...;
template GSUP_IEs a_or_b := (a, b);

So if 'a' is your template without the additional Message Class IE at the end, and 'b' is your template with that additional IE, then 'a_or_b' would do the trick, right?

You should even be able to derive b from a with something like:

template GSUP_IEs b := a & tr_GSUP_IE_SSInfo(ss);

Howver, admittedly, I've had my fair share of scratching my head about list concatenation with templates (list of templates vs. list of types vs. mixtures of it) so that final part may not be possible.

Actions #2

Updated by laforge almost 5 years ago

Actually, you should even be able to construct a template like this:

        var template GSUP_IEs ies := {
                tr_GSUP_IE_IMSI(imsi),
                tr_GSUP_IE_SessionId(sid),
                tr_GSUP_IE_SessionState(state),
                (omit, tr_GSUP_IE_SSInfo(ss))
        };

having said that, I haven't tried so far. But at least it's my expectation that this would work.

Actions #3

Updated by laforge almost 5 years ago

  • Status changed from Feedback to In Progress
  • % Done changed from 0 to 20

laforge wrote:

having said that, I haven't tried so far. But at least it's my expectation that this would work.

It of course doesn't. Still thinking about it, and also have created a thread at https://www.eclipse.org/forums/index.php/t/1098847/

Actions #4

Updated by laforge almost 5 years ago

Minor nitpick: The RSL implementation (and possibly more) works exactly like the GSUP dissector as they are written in the same style. It's only the Ericsson-provided implementations like BSSMAP, DTAP/MobileL3 which work differently.

I always thought and still think that the Ericsson style dissectors lack structure and elegance. They basically don't think of a message as a sequence of information elements, but just some blob where the concept of a TLV or an IE doesn't really exist. Just mandatory and optional parts. I understand that this makes the specific part of matching optional parts more difficult. But then, at the other hand, you don't have to wrige "spaghetti templates" listing hundreds of members that all are only "omit".

Actions #5

Updated by laforge over 4 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 20 to 70

There are some examples in the linked thread at https://www.eclipse.org/forums/index.php/t/1098847/ on how to improve the situation. Without template concatenation or other TITAN or even TTCN3 changes it doesn't seem like we're going to see any fundamental improvmeent here, though.

Rewriting our *_Types.ttcn to follow a non-list based approach is an option, but I guess it's a bit too late to invest that much time into converting code that already exists. However, for future types/codecs, we should think twice if using the list based approach really is worth it, given the pitfalls it creates further down the road.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)