B.1 Syntax definitions

33.1083G Security3GPPHandover interface for Lawful Interception (LI)Release 17TS

The transferred information and messages are encoded to be binary compatible with [5] (Abstract Syntax Notation One (ASN.1)) and [6] (Basic Encoding Rules (BER)).

These recommendations use precise definitions of the words type, class, value, and parameter. Those definitions are paraphrased below for clarity.

A type, in the context of the abstract syntax or transfer syntax, is a set of all possible values. For example, an INTEGER is a type for all negative and positive integers.

A class, in the context of the abstract syntax or transfer syntax, is a one of four possible domains for uniquely defining a type. The classes defined by ASN.1 and BER are: UNIVERSAL, APPLICATION, CONTEXT, and PRIVATE.

The UNIVERSAL class is reserved for international standards such as [5] and [6]. Users of the protocol may extend the syntax with PRIVATE class parameters without conflict with the present document, but risk conflict with other users’ extensions. APPLICATION class parameters are reserved for future extensions.

A value is a particular instance of a type. For example, five (5) is a possible value of the type INTEGER.

A parameter in the present document is a particular instance of the transfer syntax to transport a value consisting of a tag to identify the parameter type, a length to specify the number of octets in the value, and the value.

In the BER a tag (a particular type and class identifier) may either be a primitive or a constructor. A primitive is a pre-defined type (of class UNIVERSAL) and a constructor consists of other types (primitives or other constructors). A constructor type may either be IMPLICIT or EXPLICIT. An IMPLICIT type is encoded with the constructor identifier alone. Both ends of a communication have to understand the underlying structure of the IMPLICIT types. EXPLICIT types are encoded with the identifiers of all the contained types. For example, an IMPLICIT Number of type INTEGER would be tagged only with the Number tag, where an EXPLICIT number of type INTEGER would have the INTEGER tag within the Number tag. The present document uses IMPLICIT tagging for more compact message encoding.

For the coding of the value part of each parameter the general rule is to use a widely use a standardized format when it exists (ISUP, DSS1, MAP, etc.).

As a large part of the information exchanged between the user’s may be transmitted within ISUP/DSS1 signalling, the using of the coding defined for this signalling guarantee the integrity of the information provided to the LEMF and the evolution of the interface. For example if new values are used within existing ISUP parameters, this new values shall be transmitted transparently toward the LEMF.

For the ASN.1 parameters of the type ‘OCTET STRING’, the ordering of the individual halfoctets of each octet shall be such that the most significant nibble is put into bitposition 5 ‑ 8 and the least significant nibble into bitposition 1 ‑ 4. This general rule shall not apply when parameter formats are imported from other standards, e.g. an E.164 number coded according to ISUP, ITU‑T Recommendation Q.763 [29]. In this case the ordering of the nibbles shall be according to that standard and not be changed.