1.    http://csn1.info/
 
2.    3GPP TS 24.007
Description of CSN.1 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

The goal of the notation described hereafter is to describe the structure of the syntactically correct messages for a given signalling protocol, or of part of such messages. The notation addresses the cases where the concrete messages are binary strings. The notation allows to describe  sets  of strings: the structure of a message defined a protocol defines a set of allowable bit strings. It also allows to put labels on parts of strings that follow a given structure.

One aspect of the specification of message set is to define the set of strings that are acceptable as when received. All the strings that cannot be recognized as syntactically correct messages are to be rejected for syntactical reasons. In many cases, only a subset of this set are allowed to be sent. The notation allows also to distinguish the set of the strings that can be sent and the set of strings that are recognized as syntactically correct.

Another aspect of the specification of messages is the splitting of an acceptable string in a number of sub-strings that will be use to derive the exact significance of the message. The notation provides this function by labelling sub-strings. These labels can then in turn be used in textual or formal semantic descriptions which are not covered in the present document.

The notation described here could be enhanced in the future, with the addition of new rules.

B.1 The Basic Rules

The following rules (B1 to B6) form the core part of the notation, more or less directly inherited from BNF. Rules B7 to B8 add what is needed in addition to encode the rest octet parts of fixed length messages as defined in 3GPP TS 24.008 [6].

Rule A1 is not needed to describe sets of strings at this stage. It is the one allowing to label parts of messages.

B.1.1 Core Rules

B.1.1.1 Rule B1: Bits

A "bit string" is an ordered sequence of symbols, each belonging to a two-value set. 

The character "0" and "1" are used to indicate one bit, respectively of one or the other value.

Formally, the notations « 0 » and « 1 » denote each a set composed of a single bit string of a single bit, of different values.

In addition the word "bit" denotes the set of the two 1-bit long strings, namely 0 and 1.

B.1.1.2 Rule B2: Null String

Where needed, the word "null" call be used to indicate the null string, i.e., the string of no symbols.

Formally, the notation « null » denote the set composed of a single bit string, the empty string.

B.1.1.3 Rule B3: Concatenation

A succession of two string descriptions describe the concatenation of the strings.

More formally: a succession of two string descriptions describes the strings obtained by concatenation of one string taken in the subset described by the first string description and then one string taken in the subset described by the second string description. The rule extends to any number of string descriptions.

For instance:

00

This denotes the set composed of the single bit string of length 2 composed of two zeros.

B.1.1.4 Rule B4: Choice

A list of choices is noted using as separator the character "|". An alternative notation uses instead the word "or" (this is not used in the present document).

NOTE: An idea is to allow not to used strange characters, by giving in each case a verbose equivalent. This is not done systematically yet in the present document.

Formally: the notation A | B, where A and B are string set descriptions, describes the set of the strings which are in the set described by A or in the set described by B, that is the union of sets described by A and B.

The concatenation has a higher precedence than the choice.

Examples:

00 | 01

This indicates that bit strings 00 and 01 are part of the set (10 and 11 are not).

  0 | 1

Denotes the same set as "bit".

The characters "{" and "}" are used for delimiting a string set description from what follows and/or precedes.

0 {0|1}

This indicates the same set of bit strings as in the previous case.

Precedence example:

10 | 11

1 0|1

Because of the priority rule, the two descriptions are not equivalent, the second noting the set (10, 1).

It is allowed that the different sets in a choice have non null intersections. To allow message decoding, a rule must then be given to choose the branch. The rule is that any matching set can be chosen (the concatenation is a true set union).

In practice, it is preferable to have non intersecting choice sets. Moreover, the ability to select the branch to take rapidly is important for obtaining simple message decoders. Except for strong reasons, a design should only include choice construction that can be rewritten using only constructions matching the pattern { a 1  s 1 | a 2  s 2} where  a 1 and  a 2 are nonintersecting sets of strings of the same non-null length. A tolerable derogation is to use intersecting  a n.

Examples:

{100 xx | 001 zz} is acceptable.

{00 xx | 010 yy | 011 zz} is acceptable, since it can be rewritten {00 xx | 01 {0 yy | 1 zz}}}.

{{00|01|10} xx | {00|11} yy} is not recommended (the start 00 is ambiguous).

In practice this covers fixed length tagging (like tagging by an IEI, or 1-bit tagging in rest octets), and also non-intersecting variable length tagging as used for instance in the frequency list IE (tag list such as 0, 100, 101, 110, 11100, 11101, 11110, 11111, where no tag is the start of another one).

B.1.1.5 Rule B5: Naming

The characters "<" and ">" are used to delimit a  reference  to the description of a string set. This can be used inside a string set description, to refer to a string set described elsewhere.

For compilability, the name must be used somewhere else to define the corresponding string set. For a simple description, the description of the reference could be done by normal text.

The name, that is the part sequence of characters between "<" and ">" must not be empty, and is constituted freely of characters, with the exception of "<" and ">". Case is not significant, nor are heading or tailing spaces. Any succession of space characters is treated as a single character. To avoid difficulties with more advanced rules, the use of the characters ":", "=", "(" and ")" should be avoided. More generally, it is not recommended to use many other characters, such as "<" for instance. The space character can (and should!) be used, to allow a good legibility for human beings.

Example:

<bit pair>

B.1.1.6 Rule B6: Definition

A reference followed by the character sequence "::=" followed by a string set description is used to associate the description with the reference, terminated when needed to separate it from a following definition and when compilability is looked for, by a semi-colon ' ;.

Recursive definition is allowed, e.g., the reference can appears on the right hand side of the "::=". To avoid too much difficulties for would-be-compilers, only tail recursivity should be used, i.e., a recursive term should appear only as the last term of a definition.

Examples:

<bit pair> ::= 00 | 01 | 10 | 11 ;

This could have been noted as well:

<bit pair> ::= {00 | 01 | 10 | 11} ;

or

<bit pair> ::= {0|1} {0|1} ;

Recursive example:

<all bit strings> ::= null | { {0 | 1} <all bit strings>} ;

Another recursive, but not tail-recursive (and then not recommended) example:

<all bit strings> ::= null |  {<all bit strings> {0 | 1}} ;

B.1.2 Spare parts

For the purpose of message description it is in many cases needed to specify differently the set of bit strings that are acceptable when received and the corresponding set of bit strings which may be sent. The second set is included in the first. A first example are the spare parts.

Notations related to spare parts are different in nature from the bit string set description seen so far. They define two sets as the same time, the sent set and the received set. A construction rule of general application will be defined in advanced rules. For the moment, only two ad-hoc constructions are described.

B.1.2.1 Rule B7: Spare bits

The following construction:

<spare bit>

describes a 0 when emitted and a bit (0 or 1) in reception.

B.1.2.2 Rule B8: Padding bits

An issue specific to the GSM radio interface protocols is that in some cases the messages cannot take arbitrary lengths. Padding is then necessary to fill up the message up to the desired length. Moreover, the padding uses a particular sequence of bits, of fixed position, i.e., the value of a padding bit depends on its position relative to the start of the message. The padding sequence is protocol-specific. In most cases it is constituted of all 0 values, in which case the following notation is of no use. In the case of GSM 04.08, the padding sequence is the repetition of octet 00101011, starting on an octet boundary.

The special notations "L" and "H" are used to denote the respectively the bit value corresponding to the padding spare bit for that position, and the other value.

The notations "0", "1", "null", "L" and "H" are the only terminals in CSN.1.

Padding spare bits are bits which are set to the indicated value in emission whereas in reception any bit string is acceptable. The following notation:

<spare L>

describes a bit which has a logical value L in emission, and is a bit (0 or 1) in reception.

The term <spare padding> denotes the required padding spare bits needed to fill up the message. The construction can be developed only partially from the rules described so far, because the length limitation does not appear in the following description:

< spare padding> ::= <spare L> {null | < spare padding>};

B.1.3 Predefined sets

The notation allows a modular description of the messages. This means in particular the possibility to build a library of bit string set definitions to be used wherever needed. The following is an example of an elementary library, which could be specified once and can be used in other specifications without being redefined.

<bit> ::= 0|1 ;

<bit (1)> ::= <bit>;

<bit (2)> ::= <bit> <bit>;

<bit (3)> ::= <bit (2)> <bit>;

<bit (4)> ::= <bit (3)> <bit>;

<bit (5)> ::= <bit (4)> <bit>;

<bit (6)> ::= <bit (5)> <bit>;

<bit (7)> ::= <bit (6)> <bit>;

<octet> ::= <bit (7)> <bit>;

<half octet> ::= <bit (4)>;

<spare half octet> ::= <spare bit><spare bit><spare bit><spare bit>;

<spare padding> ::= <spare L> {null | <spare padding>};

<octet string(i)> ::= <octet> (i)  ; -- for any positive or null integer i

<bit(i)> ::= <bit>(i);  -- for any positive or null integer I

<bit string> ::= bit**;

<octet string> ::= <octet>**;

NOTE 1: The definition of generic constructions such as <bit string(i)> is somewhat cumbersome with only the basic rules. More advanced rules would allow a much more compact notation.

NOTE 2: The use of the characters "(" and ")" within a reference is done consistently with potential advanced rules.

NOTE 3: This basic library is not exhaustive and can be extended when the needs arise.

B.1.4 Labelling Parts

B.1.4.1 Rule A1: Labels

Delimited names as defined by Rule B6 identify sets of sub strings. In many cases this can be used within the context of a message to refer to the specific part of the message. However, this is not of general application, since it may happen that two parts of a message follow the same structure, and economy of notation requires that the structure is described but once.

The general syntax that follows allows to refer to a part inside a description:

< name1  :  string description>

For the definition of string sets, this is equivalent to the string description being used alone.

The name used as a label can be built according to the rules applicable to parenthesed references.

Examples:

  <Tag : 000 >

  <Field : <Field type>>

  <Field : octet>

The third example shows the use of a non parentheses reference to obtain a more elegant expression than, for instance, the second example. At this stage, labels has no use for describing message syntax, but can be used to refer to the corresponding part of the string, e.g., in the description of the message specifying the relationship between the syntactical content and the semantical contents of the message, or to associate properties with effective sub-strings in effective messages (rather than with sets of sub strings). Syntactical use of the semantical identifier are presented in more advanced rules.

The same name may appear in several places. Designers have to be careful to use non ambiguous names if nonambiguous reference is desired.

B.1.5 Goodies

B.1.5.1 Rule G1: Comments

Comments can be added, starting with the term "--" and ended by the end of line. Comments can be used in particular to indicate the section where a particular description can be found.

B.2 Advanced rules

B.2.1 Rule A2: Exponent notation

An arithmetic expression used as exponent after a delimited string description is used to indicate repetitions.

A numerical expression between parentheses indicates a fixed number of repetitions.

<octet> ::= {0 | 1} (8 ) ;

is equivalent to 

<octet> ::= {0 | 1} {0 | 1} {0 | 1} {0 | 1} {0 | 1} {0 | 1} {0 | 1} {0 | 1} ;

This could also be written: 

<octet> ::= bit(8) ;

When the exponent is negative or equal to 0, the exponentiated construction is equivalent to the null string.
An example of a common construction is the following:

<name : bit(5)>

Simple arithmetic, using numbers, terms "+", "-", "*" and "/", and parentheses are allowed in expressions.

Example:

<octet string(40)> ::= <octet> (8*(4+1))  ;

A star used alone between parentheses, or a double star, indicates a finite, possibly null, but indeterminate, number of repetitions. (The star used as an exponent can be understood also as meaning the union of all the sets obtained by replacing the star by zero or some positive integer).

<all bit strings> ::= {0 |1}(*) ;

<all bit strings> ::= {0 |1}** ;

This allows a shorter notation of recursive constructions such as:

<all bit strings> ::= {0|1} <all bit strings> | null;

A shorter notation is allowed when the expression has a single term, consisting of a star followed by the term:

<octet> ::= {0 | 1}*8 ;

<octet string(40)> ::= <octet>*(8*(4+1)) ;

<all bit strings> ::= bit**;

Application note:

The indefinite exponent is usually combined with some mean to indicate to the decoder the end of the repetition. Different techniques exist, such as indicating in a previous field the number of repetitions. Another technique is one-bit tagging, an example of which follows: {1 <item>}** 0.