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  |
|
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  |
|
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 #1807342 is a reply to message #1807327] |
Tue, 28 May 2019 10:55 |
 Gábor Szalai
Messages: 133
Registered: December 2015 |
Senior 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 #1807354 is a reply to message #1807342] |
Tue, 28 May 2019 12:11 |
|
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
|
|
| | |
Goto Forum:
Current Time: Fri Apr 19 20:47:32 GMT 2024
Powered by FUDForum. Page generated in 0.03417 seconds |
] 
Search
Help
Register
Login
Home
