TOP

Version-Dependent Classes

Applies to: NAS/C++ LTE/EPC r16.3.0 v8.0.0

These classes are dependent on the NAS protocol version used, and can vary with the version. Classes specific to a particular version are defined in the corresponding namespace, for example, in OssNas::v1630.

NAS messages are mapped to a complex hierarchy of representation classes, however, these classes follow several simple patterns.

Octet string and character strings are mapped to the OssString class. Bit strings are mapped to the OssBitString class.

A protocol element that consists of several sub-elements of the same type is represented as an ASN.1 SEQUENCE OF. A protocol element that consists of several sub-elements of different types is represented as an ASN.1 SEQUENCE. A protocol element that can contain only one of several possible alternatives of different types is represented as an ASN.1 CHOICE.

Sometimes the API uses class names starting with two underscores: __seq<number>, __seqof<number>, __choice<number>, or __shared<number>. These names are internal, can be changed in subsequent versions of the API, and are not recommended for use in application code. The application programmer can use more descriptive designations using qualified names or typedefs, as explained in previous sections.

Determinant Fields

Certain fields present in an NAS message play a special role in an encoding. Some of these special fields (e.g., the mccMNCIndicator field in MobileIdentity) are used to indicate whether a certain optional component is present or absent in the value. Some (e.g., numberOfElements in TAIListElement) are used to indicate the number of elements in a list. Some (messageType in PlainEMMMessage) are used to indicate which alternative of a choice is present in the value. We call these special fields determinant fields.

However, the C++ classes also contain hidden auxiliary fields to handle this information, for example, the absence or presence of a particular field is controlled by the set_<field>/omit_<field> functions, the number of elements in a list is obvious, and the selected alternative of a CHOICE is controlled by the set_<alt> functions. Therefore, the existence of determinant fields is superfluous.

In all such cases, the OSS NAS/C++ API takes the following approach regarding encoding:

  • The determinant field occurs as a regular field within the C++ classes defined in the NAS<version>.h file, i.e., the classes have all the corresponding accessor and mutator functions to handle this field, and the constructors have the corresponding arguments, just as if it were a regular field.
  • The encoder uses the auxiliary fields, not the determinant fields, to know whether an optional component is present, which choice alternative is selected, and so on; the encoded value will reflect the intent of the user application as conveyed by the auxiliary fields.
  • The encoder verifies that the value of each determinant field is consistent with the value of the corresponding auxiliary field. If the values are consistent, the encoder uses the value of the determinant field as the source value for the encoding. Otherwise, the encoder ignores the original value of the determinant field and uses the lowest valid value for the determinant field that is consistent with the value of the auxiliary field.

In most cases, the user application does not need to set the determinant fields before encoding. In some cases, though, the user application may want to set a determinant field, in addition to the corresponding auxiliary field. This is when the determinant field conveys some specific information in addition to acting as a determinant for some other field of the message. In such cases, there are multiple values of the determinant field that correspond to the same value of the auxiliary field, and any of those values will be accepted by the encoder and used as the source value for the encoding.

Read-only Fields

Certain fields present in a NAS message are specified as read-only and their values are ignored by the encode operation. Those fields include most determinant fields as well as all the fields that are constrained to a fixed value by the specification. You can see whether a field is read-only by looking for the READONLY keyword inside a comment within the NAS1630.asn file.

You do not need to assign a value to any read-only fields present in the C++ representation objects prior to calling an encode operation. You do not even need to worry about initializing those fields to zeros, for example, since their values will be ignored.

As an important example, your application does not need to set (or even initialize) the messageType field within PlainEMMMessage or ESMMessage. It only needs to set the right alternative of the body field (using the correct set_<alt> function). The value of the messageType field is ignored by the encoder.

Note also that the print function always prints READONLY fields as zero or false values, regardless of their real value.


This documentation applies to the OSS NAS Tools for C++ for LTE/EPC v8.0.0 for 3GPP Release 16.3.0.

Copyright © 2024 OSS Nokalva, Inc. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means electronic, mechanical, photocopying, recording or otherwise, without the prior permission of OSS Nokalva, Inc.
Every distributed copy of the OSS NAS Tools for C++ for LTE/EPC is associated with a specific license and related unique license number. That license determines, among other things, what functions of the OSS NAS Tools for C++ for LTE/EPC are available to you.