Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » Minimalistic assistance for CSN.1 L/H in the RAW codec?
Minimalistic assistance for CSN.1 L/H in the RAW codec? [message #1807304] Mon, 27 May 2019 19:34 Go to next message
Harald Welte is currently offline Harald WelteFriend
Messages: 128
Registered: July 2017
Location: Berlin, Germany
Senior Member

Hi!

In Osmocom, we deal a lot with "legacy" GSM, GPRS and EGPRS - on all interfaces and all protocoll levels. The air interface has quite a lot that's specified in CSN.1 (concrete syntax notation). CSN.1 is a bit obscure in that the specification can only be bought as a paper book from the author of the spec, but I digress ;)

In an ideal world, one would of course have a parser + code generator for consuming the CSN.1 syntax from the specs (which is full of syntax errors, btw) and generating encoder/decoder code from it. But that's a lot of work, so I'm not even aiming for that.

However, it would be really useful to have one small feature in the TITAN RAW codec: The notion of the "L" and "H" value of a bit. If that feature existed, one could use the RAW codec syntax to describe the most important CSN.1 data types we need in our tests.

So what is this L/H about? In CSN.1, each bit can not only have two values (the usual 0 and 1), but it can also have L and H value. How can that be, it's just a single bit, after all?

The magic is that 0/1 are *absolute* values like you know, while L/H are *relative* or *differential* values, which are encoded in terms of the default padding pattern 0x2B. So the actual encoding of the bit depends on the current position in the stream.

0x2B in binary is 0b00101011. Assuming we are encoding from the MSB first, a "L" value on the first bit would be '0', and a "H" value would be '1'. But if we're at the third bit position, then "L" would be '1' and "H" would be '0'.

Let's take the following example, a simplified part of the SI3 Rest Octets from 3GPP TS 48.018:
<SI3 Rest Octet> ::=
     <Optional selection parameters>
     <Optional Power offset>
    <System Information 2ter Indicator>
    <Early Classmark Sending Control>
    <Scheduling if and where>
    { L | H <GPRS Indicator> }
    <spare padding> ;
<Optional Selection Parameters> ::=
    L | H <Selection Parameters>;
<Selection Parameters> ::=
    <CBQ: bit (1)>
    <CELL_RESELECT_OFFSET: bit (6)>
    <TEMPORARY_OFFSET: bit (3)>
    <PENALTY_TIME: bit (5)>;
<Optional Power Offset> ::= L | H <Power Offset: bit (2)>;
<System Information 2ter Indicator> ::= L | H;
<Early Classmark Sending Control> ::= L | H;
<Scheduling if and where>::= L | H <WHERE: bit (3)>;
<GPRS Indicator> ::=
    < RA COLOUR : bit (3) >
    < SI13 POSITION : bit >;


where I would want to end up with an abstract TTCN3 type definition like this:

        type record Si3RestOctets {     
                BIT1                    sel_params_present,
                SelectionParams         sel_params optional,
                BIT1                    power_offset_present,
                uint2_t                 power_offset optional,
                BIT1                    si2ter_indicator,
                BIT1                    ealy_cm_sending_control,
                BIT1                    where_present,
                uint3_t                 where optional,
                BIT1                    gprs_ind_present,
                GprsIndicator           gprs_ind optional
        } with {
                variant (sel_params) "PRESENCE(sel_params_present = H)"
                variant (power_offset) "PRESENCE(power_offset_present = H)"
                variant (where_present) "PRESENCE(where_present = H)"
                variant (gprs_ind) "PRESENCE(gprs_ind_present = H)"
        }
        type record SelectionParams {
                boolean                 cbq,
                uint6_t                 cell_reselect_offset,
                uint3_t                 temporary_offset,
                uint5_t                 penalty_time
        }
        type record GprsIndicator {
                uint3_t                 ra_colour,
                BIT1                    si13_position
        }


The RAW decoder would then have to understand the meaning of L and H in context of the current bit-offset into the buffer/bitstring it is currently parsing. After tanslating L/H into absolute 0/1 values, decoding of the optional parts continues as usual.

The RAW encoder would equally have to select L/H based on "ispresent()" of the repsective members, and translate L/H into absolute values based on the bit position of the current output buffer/bitstring.

I'm happy to spend some time on helping to bring this feature into reality, but given my exposure to the TITAN compiler internals is still rather limited, I'd appreciate some help. I guess for somebody familiar with the code it's rather easy to do the 0/1 <-> L/H translations at the right points in the code..

Thanks in advance for any help.

Regards,
Harald
Re: Minimalistic assistance for CSN.1 L/H in the RAW codec? [message #1807305 is a reply to message #1807304] Mon, 27 May 2019 19:47 Go to previous messageGo to next message
Harald Welte is currently offline Harald WelteFriend
Messages: 128
Registered: July 2017
Location: Berlin, Germany
Senior Member

btw: while the above takes care of the optional parts of a message, we also have 'boolean' fields whose value is directly expressed as L/H rather than 0/1. See for example
<Early Classmark Sending Control> ::= L | H;

which then means we'd have to have something like
...
        boolean early_cm_sending_control,
...
        variant (early_cm_sending_control) "CSN1LH"

to indicate that this boolean isn't encoded as 0/1 but as L (false) / H (true)
Re: Minimalistic assistance for CSN.1 L/H in the RAW codec? [message #1807327 is a reply to message #1807305] Tue, 28 May 2019 08:10 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1120
Registered: January 2015
Senior Member
Hi Harald,

let us look into it and come back to you.

Best regards
Elemer
Re: Minimalistic assistance for CSN.1 L/H in the RAW codec? [message #1807342 is a reply to message #1807327] Tue, 28 May 2019 10:55 Go to previous messageGo to next message
Gábor Szalai is currently offline Gábor SzalaiFriend
Messages: 86
Registered: December 2015
Member
Rule B8: Padding bits
CSN.1 definitions can use the L and H terminals instead of the 0/1 ones.
A L/H match is done comparing the current bit with the corresponding one of an hypotetical string made of infinite repetitions of the octet aligned 8-bit string 00101011 (0x2B).

The L bit is matched when the bit under test is the same of the one of the reference string in the same position; H is matched when it is not the same.
[A] 00101011 00101011 00101011

[B]     1111 11110000 0000

[C]     LHLL HHLHHLHH LLHL

In the example above, the reference string [A] si aligned to the octet.
Our test string [B] starts with a 4 bit offset.
The CSN.1 string [C] would match against [B]

Please, note that the decoder/encoder, in order to use the L/R terminals, must be aware of the octet alignment of the bit string it is processing. Therefore, its input information is not only the string it has to decode (1111111100000000 in this example), but also the offset of the first bit of the string from the octet boundary.
Therefore, a L bit could be a 0 or a 1, according to the absolute position where it happens to be.

So the following modificcation is needed to support the CSN.1 L/H
1. new RAW attribute, applicable to any basic types
2. compiler update the handle the new attribute
3. new flag in RAW descriptor
4. update of the TTCN_Buffer to handle the new L/H flag in get/put functions
5. update the RAW encoder/decoder functions of the basic types to pass the new L/H flags to buffer handling functions.

Re: Minimalistic assistance for CSN.1 L/H in the RAW codec? [message #1807345 is a reply to message #1807342] Tue, 28 May 2019 11:02 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1120
Registered: January 2015
Senior Member
Hi Harald,

we'll open a request in Bugzilla, and we'll implement it as resources permit.

Best regards
Elemer
Re: Minimalistic assistance for CSN.1 L/H in the RAW codec? [message #1807354 is a reply to message #1807342] Tue, 28 May 2019 12:11 Go to previous messageGo to next message
Harald Welte is currently offline Harald WelteFriend
Messages: 128
Registered: July 2017
Location: Berlin, Germany
Senior Member

Quote:

Please, note that the decoder/encoder, in order to use the L/R terminals, must be aware of the octet alignment of the bit string it is processing.


in theory, as per CSN.1 spec, yes. However, in the context of GSM/GPRS, I don't think it ever starts on something that's not an octet boundary.

The reason is simple: Either it's so-called "rest octets" which are after the end of a L3 message inside a 23-byte MAC block. As the L3 messages are always integer-number-of-octets long, the rest octets always start at an octet boundary.

Or, it's an entire CSN.1-specified message, such as the RLC/MAC control messages of Section 11.2 of TS 44.060 - whose start is also octet-aligned , see Section 10.3.1 (downlink) + 10.3.2 (uplink) of that same spec.

So what I'm trying to say: If it works under the assumption that the start of the bitstring of the "outer type" is always octet aligned, it works for the by far most significant use case of CSN.1: 2.5G/2.75G telephony :)

Regards,
Harald
Re: Minimalistic assistance for CSN.1 L/H in the RAW codec? [message #1808905 is a reply to message #1807354] Thu, 04 July 2019 09:46 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1120
Registered: January 2015
Senior Member
Hi Harald,

keep an eye on https://bugs.eclipse.org/bugs/show_bug.cgi?id=548969

Best regards
Elemer
Re: Minimalistic assistance for CSN.1 L/H in the RAW codec? [message #1809111 is a reply to message #1808905] Tue, 09 July 2019 09:34 Go to previous message
Harald Welte is currently offline Harald WelteFriend
Messages: 128
Registered: July 2017
Location: Berlin, Germany
Senior Member

thanks a lot, Elemer + team. I've added me as Cc to that bugzilla issue.
Previous Topic:'ifpresent' or ternary operator in parametric send templates
Next Topic:Q: TTCN3 and templates / lists of templates
Goto Forum:
  


Current Time: Sun Jun 20 16:29:03 GMT 2021

Powered by FUDForum. Page generated in 0.02246 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top